64位系統環(huán)境時(shí)Java的性能

如果你要買(mǎi)一輛車(chē)而且你的首要目標是性能或者更具體的說(shuō)是原始動(dòng)力，那么在4缸發(fā)動(dòng)機和8缸發(fā)動(dòng)機之間選擇的話(huà)，答案很顯然，因為越大越好。通常而言，當我們看計算機配置列表或者產(chǎn)品宣傳的時(shí)候，64位的性能也比32位有優(yōu)勢，同樣四核比雙核更棒。

　　然而許多在大同世界里很簡(jiǎn)單的道理包括越多/大越好，移到計算機領(lǐng)域里就不是那么回事了。當處理多重CPU時(shí)，你會(huì )覺(jué)得那些多核所多出來(lái)的處理單元很有用，但如果你的工作僅僅是單線(xiàn)程的，那你要做的卻是讓其他核一邊歇著(zhù)。

　　32位與64位的比較則更加細微。x86-64 架構不僅在x86架構的基礎上增大了寄存器，而且還增加了寄存器的數量。從基本上說(shuō)這會(huì )帶來(lái)更好的性能（因為更多的寄存器可以讓編譯器創(chuàng )建更好的機器代碼）。然而很不幸，至今把Java從32位移到64位帶來(lái)的只是性能的下降。

　　談到Java的性能，runtime的兩個(gè)方面很關(guān)鍵：JIT和GC。JIT的作用使盡可能快地執行代碼；GC的作用是（在管理存儲的同時(shí)）從代碼的執行中抽取盡可能少的時(shí)間。因而Java的性能是讓JIT（在更多存儲器的幫助下）產(chǎn)生更多理想代碼，并減少GC用以管理存儲的時(shí)間（指針越大這越困難）。

　　Java 9最初是設計為32位系統的而且這影響了我們在代碼基（code base）做的一些早期決定。早幾年前我曾花費不少時(shí)間試圖在運行64位的PowerPC系統上運行我們的Smalltalk VM，得到的結論是：最直接的解決方式是讓所有的數據結構（對象）變得兩倍大來(lái)處理64位指針。隨著(zhù)Java 9的發(fā)展（大約2001），我們拿到手的最早的一個(gè)64位系統是一個(gè)Dec Alpha，所以我們采用了這種最直接的“變大”解決方法，允許一個(gè)通常的代碼基既支持32位也支持64位。

　　64位CPU擁有更寬的數據總線(xiàn)，但是同樣是這個(gè)64位CPU可以運行32位的代碼，而且擁有同樣寬的數據總線(xiàn)?；仡^看看我們64位的解決方案——將數據結構變得兩倍大，效果卻不如相同硬件上的32位，也就是說(shuō)64位不及32位。這個(gè)問(wèn)題不是Java 9也不是Java所獨有的，因為所有的64位都需要數據擴展。只是說(shuō)Java語(yǔ)言將這一問(wèn)題凸顯得更加明顯，因為Java編程通常與創(chuàng )建、操控對象（也稱(chēng)數據結構）有關(guān)。

　　性能問(wèn)題的解決方法是聰明地處理數據結構，這也正是我們在Java6 JDK中使用壓縮列表特性（compressed references feature）所做的。我們可以玩小聰明而且不會(huì )被抓到，因為使用者（Java程序員）并不清楚Java對象更深處的表現。

　　折中的處理方法是通過(guò)在對象內存儲更少的信息，限制可以被JVM使用的存儲。這是一個(gè)相當不錯的處理方法，因為計算機存儲的規模遠不及64位的極限地址范圍。我們僅使用32位來(lái)存儲指針，并充分利用8字節對象對齊（aligned objects）來(lái)得到一些空位（指針 3）。因此使用壓縮列表（compressed references）——Xcompressedrefs，IBM Java6 JDK可尋址高達32Gb的堆。

　　并不只我們使用這種技巧，Oracle/BEA有-XXcompressedRefs，Sun有-XX:+UseCompressedOops。當然，不同廠(chǎng)商的方法在限制和支持等級上略有不同。也許你會(huì )有異議，但當用戶(hù)運行到32位操作系統的堆棧極限時(shí)，他們就想要64位系統（同時(shí)還要不損失性能）。