幾天前，我在論壇上發了一篇關於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 是不錯的!
本文分享自微信公衆號 - 小技術君（gh_2fd927ba125d）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。