我了解回傳選項會帶來性能后果。我知道回傳空集合也可能會損害性能，但可以通過回傳不可變的空集合（例如 Collections.emptyList()）來避免這種情況。在決定選擇哪個時還應考慮哪些其他因素。
uj5u.com熱心網友回復：
Optional 和 Empty-List 之間的任何性能問題對于絕大多數使用來說都是完全可以忽略不計的。停止關注此類問題，因為在此級別上過早地嘗試優化總是會導致比任何實際收益更多的問題（難以維護代碼等）。
一個更深層次的問題是為什么你認為這兩個選項真的是等價的。
Optional 最適合捕獲單個物件是否已回傳。
串列顯然會回傳許多物件。
我個人的觀點是，由于“數字”顯然包含零，所以我回傳一個空串列沒有問題，相反，我很難證明回傳 Optional<List> 的過度設計想法是正確的。通過測驗“list.isEmpty()”和/或沿該串列進行迭代（或流）的有效無操作，沒有什么比這更丑陋的構造提供的更干凈了。
uj5u.com熱心網友回復：
很難想象一個 JVM 應用程式在該級別上的性能開銷很重要。也許如果你構建超級基礎的基本組件，比如 List 本身的實作，它只建立在原始的 java 型別或一些序列化框架上，這些框架在不安全的領域制造了瘋狂的特技。
據我所知， optional.empty() 和 Collections.emptyList() 都是常量，因此沒有性能開銷。是的，強大的訊息來源也證實了這一點：
public static final <T> List<T> emptyList() {
return (List<T>) EMPTY_LIST;
}
public static<T> Optional<T> empty() {
@SuppressWarnings("unchecked")
Optional<T> t = (Optional<T>) EMPTY;
return t;
}
在決定選擇哪個時還應考慮哪些其他因素。
我通常不太喜歡編碼哲學，但 Optional 說更多“可能有什么或什么都沒有”，但一個空串列說“好的，它無論如何都是一個串列，大小為零”。請注意，常量 EMPTY_LIST 是不可變的，您不能將任何內容放入其中。
我認為，碰巧我確實將串列放入可選項中以指示一些“那里什么都沒有”或“根本不適用”，這會導致創建可選物件的開銷很小。但我懷疑，您是否會找到一個合理的應用程式，從而產生有意義的差異。而且我確實同意@racraman 的觀點，它Optional<List>看起來很奇怪，并表明一些最初不應該存在的退化案例。不過，不知道關于這個細節的普遍共識是什么。
例如，這里有一個主題的討論，聲稱使用 Optional 不是可選的，而回避的替代方案是回傳 null。它還詳細介紹了 Optional 的界面及其用例。例如，出現了樣式問題，其中 Optional 允許“更實用”的流暢編碼樣式，這種樣式目前似乎很流行。
如果您確實關心該級別的性能，您可能不應該關心，這本身就是一個完整的主題，請參見例如這篇相關文章。由于在這種情況下可能出現分支錯誤預測，可能存在這樣一種情況，即 Optional 使用其流暢的介面可能會在現代 cpus 上優于條件（“if”）。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/419214.html
標籤：
上一篇：pythonlist-如果上一個專案以\\結尾，則將上一個專案與下一個專案合并
下一篇：解決這個陣列問題的最佳演算法？