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由于性能方面的原因依然沒有吸引我們升級的亮點。

原文轉自：http://www.anti-gravitydesign.com