基於證據的 Java 效能調優方法

唐納德克努特經常被引用說：

“程式設計師浪費了大量的時間來考慮或擔心程式中非關鍵部分的速度，而這些效率嘗試實際上在考慮除錯和維護時會產生很大的負面影響。我們應該忘記效率低下，比如說 97％的時間 ：過早的優化是所有邪惡的根源。然而，我們不應該在那個關鍵的 3％中放棄我們的機會。“

資源

考慮到 sage 建議，這是優化程式的推薦程式：

1. 首先，設計和編碼你的程式或庫，重點是簡單性和正確性。首先，不要在效能上花費太多精力。

2. 使其處於工作狀態，並（理想情況下）為程式碼庫的關鍵部分開發單元測試。

3. 開發應用程式級效能基準。基準測試應該涵蓋應用程式的效能關鍵方面，並且應該執行一系列典型的應用程式將在生產中使用的任務。

4. 衡量表現。

5. 將測量的效能與應用程式需要的速度標準進行比較。 （避免不切實際，難以實現或無法量化的標準，例如儘快。）

6. 如果你符合標準，請停止。你的工作已經完成。 （任何進一步的努力可能都是浪費時間。）

7. 在執行效能基準測試時對應用程式進行概要分析。

8. 檢查分析結果並選擇最大（未經優化）的效能熱點; 即應用程式似乎花費最多時間的程式碼部分。

9. 分析熱點程式碼部分以試圖理解它為什麼是瓶頸，並想辦法讓它更快。

10. 將其實現為建議的程式碼更改，測試和除錯。

11. 重新執行基準測試以檢視程式碼更改是否提高了效能：

    • 如果是，則返回步驟 4。
    • 如果否，則放棄更改並返回步驟 9.如果你沒有取得進展，請選擇一個不同的熱點供你注意。

最終，你將達到應用程式速度足夠快的程度，或者你已經考慮了所有重要的熱點。此時你需要停止這種方法。如果一段程式碼消耗（比如說）總時間的 1％，那麼即使 50％的改進也只會使應用程式總體上提高 0.5％。

顯然，有一點超出熱點優化是浪費精力。如果你達到這一點，你需要採取更激進的方法。例如：

• 檢視核心演算法的演算法複雜性。
• 如果應用程式花費大量時間進行垃圾回收，請尋找降低物件建立速率的方法。
• 如果應用程式的關鍵部分是 CPU 密集型和單執行緒，請尋找並行機會。
• 如果應用程式已經是多執行緒的，請查詢併發瓶頸。

但只要有可能，依靠工具和測量而不是直覺來指導你的優化工作。