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

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

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

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

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

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

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

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

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