Java 7 Update 1的性能和穩定性
Oracle 于 10 月 18 日發布了 Java 7 Update 1，給 Java 7 帶來了迫切需要增強的穩定性，并且修復了我們以前報道過的 HotSpot 編譯器的性能優化問題，這個問題偶爾會導致錯誤結果甚至導致 SIGSEV 崩潰。JDK 6 Update 29 在使用不推薦用于生產服務器的參數 XX:+AggressiveOpts 或者-XX:+OptimizeStringConcat 時，也存在相同的問題，這在此次更新中也得到了修復。
在 Java HotSpot 虛擬機性能增強文檔中，Oracle 描述了其他一些與性能相關的特性。這份簡短的文檔只包含一項改進：-XX:+TieredCompilation。
分層編譯在早先編譯器的混合模式行為上增加了額外的一步。服務器會先對 JVM 分級，然后 Java 7 才會在解釋模式下運行代碼。然后代碼只會在“熱”的時候才被編譯和優化，并被 HotSpot VM 標記，比如說有較高的執行次數。解釋模式無論如何都比運行編譯后的代碼慢很多。-XX:+TieredCompilation 讓虛擬機可以在已經運行編譯后代碼的同時，收集用于優化的統計信息。
盡管這項改變可能會減少高動態性系統的預熱時間，其中節點會不斷地與服務器連接，但是它帶來的改進并不十分明顯，就像桌面或者 applet 程序的啟動沒那么重要一樣。
以下列出的針對 JVM 7 的改進對于 Java 6 都已經生效：
- Compressed Oops自 Java 6 Update 14 有效，自 Update 23 成為默認設置（僅 64 位)
- Escape Analysis自 Java 6 Update 14 有效，自 Update 23 成為默認設置
- 非統一內存訪問垃圾回收（Non Uniform Memory Access Garbage Collection）自 Java 6 Update 2 有效
Compressed Oops 會為 64 位地址的 JVM 節省內存。JVM 將使用更簡短的地址來引用與堆起點相關的對象，而不是從操作系統獲得 64 位內存地址。由于減少了對象引用的內存使用，大多數程序都會受益于這項特性。
Escape Analysis 會查明新分配內存的對象是否要“脫離”當前方法的作用域。如果不是那樣，那么該對象就可能會被分配在方法棧上，甚至同步可能會被移除（鎖省略）。Heinz Kabutz 就該項優化的效果有一篇全面的文章。
非統一內存訪問垃圾回收是一項很有意義的改進，其實已經存在很長一段時間了。在現代內存架構中，有一些內存區比別的內存區的讀寫操作快。特別是在多核系統中，有些內存是專為個體 CPU 保留的。感興趣的讀者可以從 Ulrich Drepper 優秀的文章中更多地了解這些內存區。JVM 將嘗試在執行分配內存線程的核所使用的內存中分配對象的內存。該性能改進要求很高（特別是在 Solaris 機器上），但是-XX:+UseNUMA 選項從來都不是默認的。
隨著大部分改進在 Java 6 Updates 上可用（乃至成為默認項），Java 7 由于性能方面的原因依然沒有吸引我們升級的亮點。
查看英文原文：State of Performance and Stability in Java 7 Update 1