內容提要
- 性能的重要性
- 新的垃圾收集器G1
- VisualVM：內存可視化工具
- 即時編譯
糟糕的性能會「殺死」你的應用程序，使你名聲掃地，在客戶中的信譽大受影響。除非你具有絕對壟斷地位，否則你的客戶將奪門而出，直奔你的競爭對手而去。要讓糟糕的性能不再糟蹋你的項目，你需要理解性能分析，還要知道如何利用它。
性能分析與調優是個非常龐大的課題，但是現在有太多處理方式都在誤人子弟。所以我們準備把性能調優的秘訣透漏給你。
秘訣來了——性能調優唯一的驚天秘訣就是：你必須量體裁衣。沒有評測，就沒有合適的調優。
原因：人們總是猜不對系統變慢的是哪裡。所有人都猜不對。你，我，甚至是James Gosling大神——我們總會心生偏見，並傾向於那些可能根本不存在的模式。
實際上，「我的哪些Java代碼需要優化？」這個問題的答案經常是「哪個也不用，都挺好的」 。
假設有一個經典（相當保守）的電子商務Web應用為註冊客戶提供服務。它有一個SQL數據庫，一個面向Java應用服務器的Apache Web服務器，以及連接這一切的標準網絡配置。系統真正的瓶頸經常是非Java部分（數據庫、文件系統、網絡），但不經過評測，Java開發人員永遠都不會知道問題出在哪裡。開發人員不去解決真正的問題，而是把時間浪費在對於改進系統性能毫無意義的代碼微調上。
你希望能夠回答如下幾類基本問題。
- 如果你們搞了次促銷，客戶突然暴增十倍，系統有足夠的內存來應付這種局面嗎？
- 客戶從應用程序中看到的平均響應時間是多長？
- 跟競爭對手比起來怎麼樣？
要做性能調優，你就不能猜測導致系統變慢的原因。你必須知道並且確保你真正實現性能調優的唯一辦法就是性能評測。
你還需要明白性能調優不是：
- 一堆技巧和竅門；
- 秘密武器；
- 你在項目結束時撒一把的仙粉。
對「技巧和竅門」要特別小心。JVM是一個非常複雜，並經過高度優化的環境，如果脫離了上下文，這些技巧基本都沒什麼用，而且可能還會帶來麻煩。隨著JVM在代碼優化方面越來越智能，它們也很快就會過時。
性能分析實際上是種試驗性的科學。你可以把代碼看成是某種科學試驗，有輸入，會產生「輸出」——性能指標表明系統執行任務的效率。性能工程師的工作是研究這些輸出，並找出其中的模式。所以性能調優是統計應用的一個分支，而不是一群老太婆的閒言碎語。
本章將是你的新起點，我們會向你介紹Java性能調優實戰。但這是個大課題，由於篇幅有限，我們只能把你領進門，幫助你分析其中的重要原理和標誌性內容。我們也會盡量解答大部分基本問題。
- 性能為什麼這麼重要？
- 性能分析為什麼這麼難？
- JVM的哪些方面會讓調優變得複雜？
- 應該如何考慮和完成性能調優？
- 哪些是導致系統遲緩的最常見原因？
我們還會介紹JVM中與性能相關的兩個最重要子系統：
- 垃圾收集子系統
- JIT編譯器
有了這些，你就可以開始著手解決編碼時遇到的實際問題了。
我們先來快速瀏覽一些基本詞彙，以便你可以表達並框定自己的性能問題和目標。