理论上来说32位的JVM有4G的堆大小限制。但是因为各种条件限制比如交换区，内核地址空间使用，内存碎片，虚拟管理机的管理开销，实际上可用的堆的大小远远比理论上的4G要少。
在32位windows的机器上，堆最大可以达到1.4G至1.6G。
在32位solaris的机器上，堆最大可以达到2G
而在64位的操作系统上，32位的JVM，堆大小可以达到4G
补充一句，在使用java参数-xms -xmx定义堆大小的时候，
- 如果是32bit的jvm超过4G肯定是没用的，定义了4G，最终使用到的可能只有2G
- 这两个值最好定义成一样，可以减少java gc的操作，有小幅度性能提高
JVM是Java开发人员必不可少的工具，而JVM也有32 bit和64 bit之分.
那实际上32位和64位JDK有什么区别呢？
JVM 32bit 和JVM 64bit的区别如下:
1目前只有server VM支持64bit JVM，client不支持32bit JVM。
2 .The Java Plug-in, AWT Robot and Java Web Start这些组件目前不支持64bit JVM
3.本地代码的影响：对JNI的编程接口没有影响，但是针对32-bit VM写的代码必须重新编译才能在64-bit VM工作。
4.32-bit JVM堆大小最大是4G, 64-bit VMs 上, Java堆的大小受限于物理内存和操作系统提供的虚拟内存。(这里的堆并不严谨)
5.线程的默认堆栈大小：在windows上32位JVM,默认堆栈最大是320k 64-bit JVM是1024K。
6.性能影响:
(1)64bit JVM相比32bit JVM,在大量的内存访问的情况下，其性能损失更少，AMD64和EM64T平台在64位模式下运行时，Java虚拟机得到了一些额外的寄存器，它可以用来生成更有效的原生指令序列。
(2)性能上，在SPARC 处理器上，当一个java应用程序从32bit 平台移植到64bit平台的64bit JVM会用大约 10-20%的性能损失，而在AMD64和 EM64T平台上，其性能损失的范围在0-15%.
以上摘自http://java.sun.com/docs/hotspot/HotSpotFAQ.html#64bit_description
JVM 性能分析
Sun的官网上写着,当一个java应用程序从32bit 平台移植到64bit平台的64bit JVM上,应用会有性能损失，相信很多人都会不解。
从数字上看，我们一般会认为64位JDK比32位JDK好，但是上文说过"实际上在32bit应用程序下，32bit处理器的性能甚至会更强，即使是64bit处理器，目前情况下也是在32bit应用下性能更强"。
许多在大同世界里很简单的道理包括越多大越好，移到计算机领域里就不是那么回事了。当处理多重CPU时，你会觉得那些多核所多出来的处理单元很有用，但如果你的工作仅仅是单线程的，那你要做的却是让其他核一边歇着。
32位与64位的比较则更加细微。x86-64 架构不仅在x86架构的基础上增大了寄存器，而且还增加了寄存器的数量。从基本上说这会带来更好的性能（因为更多的寄存器可以让编译器创建更好的机器代码）。然而很不幸，至今把Java从32位移到64位带来的只是性能的下降。
Java虚拟机（JVM）是一个软件规范，其32位与64位版本性能有所不同，但它们都包括JIT编译器和垃圾回收功能（GC）,其性能关键在JIT编译器和垃圾回收功能的执行效率上。 JIT编译器实现了程序执行之前Java字节码到硬件机器码的动态翻译，其背后的思想在于，相比Java源代码，字节码更小也更容易编译，但付出的代价是需要在Java字节码编译为机器码时花上一点时间，但与直接把Java源代码编译为机器码相比，时间还是少得多的。在32位与64位的JVM中，相应的JIT在把Java字节码编译为最终的机器码时，所花的时间稍微有所不同，但还能进行一些优化；另外，在IBM与Sun这两个版本的客户端与服务端程序上，总体性能也会有所不同。 垃圾回收会收回对象不再需要使用的内存,它必须被经常执行以释放对象不再访问的Java堆。由于在32位与64位平台上，Java堆中的数据大小会有所变化，所以会因为32位与64位JVM的性能差异，然而指针越大越GC管理越困难,导致相应垃圾回收的性能也会有所不同。
