幾天前，我在論壇上發了一篇關於Optional 的文章。其中一條評論是一個非常好的問題:
Optional 的使用會導致效能下降嗎？
答案是: 是的，它會的。但是你應該擔心嗎？
使用Optional的好處
Optional 類使我們這些開發人員的生活更輕鬆
- 增加程式碼的可讀性
- 減少程式碼中的條件數
- 更不容易出錯
讓我們來看看 Optional 類的一些主要方法是如何實現的。
Optional 如何實現的？
這裡有一些 Optional 類的主要方法:
基本上，它將值包裝到一個新的 Optional物件中，並檢查包裝的值是否為null。
即使沒有使用 Optional，也必須檢查值是否為 null。它可能比您做的檢查多一些，但我認為您不必擔心這一點。
但是您必須知道，將值包裝到新物件中將增加 GC 要收集的物件數量。這意味著堆使用量將增加得更快，CPU 使用量將更高(更多 GC 事件)。
好吧，但是有多高呢？同樣，這取決於您正在建立的可選物件的數量、堆的大小以及您的應用程式在不使用可選物件的情況下使用的 CPU 數量。
例如，假設您對應用程式進行了基準測試，並得出結論，使用 Optional 將提高 CPU 使用率1個百分點。如果您的應用程式平均使用50% 的 CPU，那麼使用51% 的可選 CPU 並不是一個很大的開銷，對吧？
但是，如果您的應用程式平均消耗5% 的 CPU，使用6% 意味著20% 的開銷，這是相當重要的。
過早優化是萬惡之源
Joshua Bloch 在Effective Java 一書中有整整一章(第67項: Optimize judiciously)談到了優化。
他在這一章的開頭寫道:
關於最優化，有三個關注點是每個人都應該知道的:
與其他任何單一原因(包括盲目的愚蠢)相比，更多的計算原罪是以效率的名義犯下的(不一定能實現)。
William A. Wulf
我們應該忘記小的副作用，比如說97% 的時間: 過早的優化是一切罪惡的根源。
Donald E. Knuth
在優化問題上，我們遵循兩個規則:
- 規則1. 不要這樣做
- 規則 2（僅適用於專家）。 暫時不要這樣做——也就是說，除非你有一個非常清晰且未經優化的解決方案。
M. A. Jackson
因此，除非您需要一個快速的應用程式並且資源有限，否則不要過早擔心效能問題。專注於編寫好的程式碼，這樣當你需要它的時候，它就很容易優化。此外，使用分析器查詢對效能影響更大的位置。
誰會使用你的 API？
這也是一個你需要問自己的好問題。如果您正在編寫一個內部 API，您可以更自由地決定是否使用它。
但是如果你正在編寫一個公共 API，比如一個框架或者庫，而你不知道什麼樣的應用程式在呼叫它，你可能需要更加靈活，給客戶端選擇是否使用可選的選項。
您可以提供兩個方法，一個返回 Optional ，另一個返回 null。但是，當建立一個可以返回 null 的方法時，儘量讓它顯式。使用註釋 javax.annotation.Nullable。方法的可空性。 (JSR 305)
最終，這取決於你
你可以決定是否使用 Optional。沒有一個簡單的答案適用於所有情況。軟體工程中的大多數事情都是這樣的。這一切都是權衡取捨。
所以，要意識到它是如何工作的，並評估替代方案。任何事情都有代價，你是那個可以決定是否承擔的人。
您認為為了提高效能而付出不可讀且更容易出錯的程式碼的代價是值得的嗎？你知道這種進步有多重要嗎？
在大多數情況下，使用 Optional 並保持開心！Optional 是不錯的!