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

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

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

　　32位與64位的比較則更加細(xì)微。x86-64 架構(gòu)不僅在x86架構(gòu)的基礎(chǔ)上增大了寄存器，而且還增加了寄存器的數(shù)量。從基本上說(shuō)這會(huì)帶來(lái)更好的性能（因?yàn)楦嗟募拇嫫骺梢宰尵幾g器創(chuàng)建更好的機(jī)器代碼）。然而很不幸，至今把Java從32位移到64位帶來(lái)的只是性能的下降。

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

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

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

　　性能問(wèn)題的解決方法是聰明地處理數(shù)據(jù)結(jié)構(gòu)，這也正是我們?cè)贘ava6 JDK中使用壓縮列表特性（compressed references feature）所做的。我們可以玩小聰明而且不會(huì)被抓到，因?yàn)槭褂谜撸↗ava程序員）并不清楚Java對(duì)象更深處的表現(xiàn)。

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

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