64位系统环境中Java的性能

　　32位与64位的比较则更加细微。x86-64 架构不仅在x86架构的基础上增大了寄存器，而且还增加了寄存器的数量。从基本上说这会带来更好的性能(因为更多的寄存器可以让编译器创建更好的机器代码)。然而很不幸，至今把Java从32位移到64位带来的只是性能的下降。

　　谈到Java的性能，runTIme的两个方面很关键：JIT和GC。JIT的作用使尽可能快地执行代码;GC的作用是(在管理存储的同时)从代码的执行中抽取尽可能少的时间。因而Java的性能是让JIT(在更多存储器的帮助下)产生更多理想代码，并减少GC用以管理存储的时间(指针越大这越困难)。

　　Java 9最初是设计为32位系统的而且这影响了我们在代码基(code base)做的一些早期决定。早几年前我曾花费不少时间试图在运行64位的PowerPC系统上运行我们的Smalltalk VM，得到的结论是：最直接的解决方式是让所有的数据结构(对象)变得两倍大来处理64位指针。随着Java 9的发展(大约2001)，我们拿到手的最早的一个64位系统是一个Dec Alpha，所以我们采用了这种最直接的“变大”解决方法，允许一个通常的代码基既支持32位也支持64位。

　　64位CPU拥有更宽的数据总线，但是同样是这个64位CPU可以运行32位的代码，而且拥有同样宽的数据总线。回头看看我们64位的解决方案——将数据结构变得两倍大，效果却不如相同硬件上的32位，也就是说64位不及32位。这个问题不是Java 9也不是Java所独有的，因为所有的64位都需要数据扩展。只是说Java语言将这一问题凸显得更加明显，因为Java编程通常与创建、 *** 控对象(也称数据结构)有关。

　　性能问题的解决方法是聪明地处理数据结构，这也正是我们在Java6 JDK中使用压缩列表特性(compressed references feature)所做的。我们可以玩小聪明而且不会被抓到，因为使用者(Java程序员)并不清楚Java对象更深处的表现。

　　折中的处理方法是通过在对象内存储更少的信息，限制可以被JVM使用的存储。这是一个相当不错的处理方法，因为计算机存储的规模远不及64位的极限地址范围。我们仅使用32位来存储指针，并充分利用8字节对象对齐(aligned objects)来得到一些空位(指针<< 3)。因此使用压缩列表(compressed references)——Xcompressedrefs，IBM Java6 JDK可寻址高达32Gb的堆。

　　并不只我们使用这种技巧，Oracle/BEA有-XXcompressedRefs，Sun有-XX:+UseCompressedOops。当然，不同厂商的方法在限制和支持等级上略有不同。也许你会有异议，但当用户运行到32位 *** 作系统的堆栈极限时，他们就想要64位系统(同时还要不损失性能)。