1. 为什么我们需要64位架构？
一直以来，如何处理呈几何级数增长的海量数据不仅仅是Java开发者面临的挑战，而且是硬件和软件制造商同样面临的挑战。今天，我们见证了一个计算机发展史上的进化： 从32位架构转移到64位架构。在过去的15年里， 32位架构被认为是足够运行大多数的企业应用；但是，今天日新月异的业务领域对系统提出了更高的需求，因此64位架构应需而生。
64位硬件已经成为了工业标准，CPU 如IBM Power、Sun SPARC以及Intel Itanium都已经支持64位， 包括AMD Opteron chips 和 Intel Xeon EM64T chips。除了硬件，操作系统厂商如Microsoft、HP、IBM、Sun 以及 Linux都已经有了64位的产品。只有64位的JVM发展相对落后。今天，64位的JVM仍然很少见，并且只使用在特别领域中，比如那些需要超大Heap空间的应用。
2. 64位架构
如图所示，底层是64位的，上层可以选择32位的；反过来则不行。可以看出，要想安装64位的JVM，操作系统和硬件必须都是64位的才行。3. 使用64位架构的好处
理论上，32位最多支持4G内存（2的32次方），64位最多支持内存（2的64次方）。
下图展示Heap大小与GC的关系：
可以看出，Heap=1.5G时的GC所占用的时间几乎是Heap=13.5G的5倍。也就是说，Heap=13.5G时的吞吐率是Heap=1.5G时的5倍。但是，评估GC好坏的另一个指标是GC暂停时间，而GC暂停时间与两个因素有关：Heap大小和“活对象“的数量。一方面，Heap越大，GC暂停时间越长；另一方面，Heap越大，“活对象“的数量越小，数据访问集中在内存中，访问硬盘的几率很小，因此GC暂停时间越小。
4. 使用64位架构的成功案例
目前已经证实的是，64位架构已经在金融领域（如银行、保险、投资）、科学领域（如地理信息系统）中大显身手。这里有两个成功案例：
（1）野外勘探测量：海量数据处理。
（2）金融产品风险评估：海量数据计算。
5. 64位不是万能的
6. 移植到64位
从32位移植到64位的主要问题是JNI native code：
如果使用了32位的JNI native code，则移植到64位上会有问题，因为32位的JNI native code无法运行在64位的操作系统中。
你需要在64位平台上重新编译32位的JNI native code，如果你有源代码。如果没有源代码，则无法移植。
7. 64位适合你吗？
当你有如下需求时，可以考虑使用64位：
（1）需要Heap空间超过4 GB。
（2）GC时间过长（由于Heap空间过小的缘故）。
（3）海量数据计算。
当你有如下需求时，可以考虑使用32位：
（1）4 GB的Heap空间足够用。
（2）希望GC暂停时间越小越好。
下图展示了在32位和64位架构下，Server端Java应用的性能比较（前提：1G的Heap足够用）：
下图展示了在32位和64位架构下，Client端Java应用的性能比较（前提：1G的Heap足够用）：
下图展示了在32位和64位架构下，Java应用的性能比较（前提：1G的Heap不够用）：
趋势分析显示了Heap中最常见的对象类型、 对象类型的增长率、对象类型的实例数、所占内存大小 。趋势分析的运行时间越长，趋势就越可靠。
右键最大数组，选择“添加到实例图形”，发现有一个HashTable指向该数组。继续展开全部节点——有两个DemoThread 对象引用了该HashTable。
2.2 并行收集器（Throughput Collector），吞吐量优先。
可以看出，在单个CPU时，并行收集器并没有体现出优势（多个线程分享一个CPU <= 一个线程独占一个CPU），只有在2个以上的CPU时，并行收集器才会优于串行收集器。
【暂停时间】：指垃圾收集器运行时，应用程序停止响应的时间。
