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

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

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

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

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

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

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

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

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

歡迎轉(zhuǎn)載，信息來源維庫電子市場網(wǎng)（www.dzsc.com）