其實就是因為操作系統有32位和64位，這兩者有什么區別呢？
引用鏈接 http://blog.sina.com.cn/s/blog_4adc4b090102vr3a.html
所謂32位處理器就是一次只能處理32位，也就是4個字節的數據，而64位處理器一次就能處理64位，即8個字節的數據。如果我們將總長128位的指令分別按照16位、32位、64位為單位進行編輯的話：舊的16位處理器，比如Intel 80286 CPU需要8個指令，32位的處理器需要4個指令，而64位處理器則只要兩個指令，顯然，在工作頻率相同的情況下，64位處理器的處理速度會比16位、32位的更快。而且除了運算能力之外，與32位處理器相比，64位處理器的優勢還體現在系統對內存的控制上。由於地址使用的是特殊的整數，而64位處理器的一個ALU（算術邏輯運算器）和寄存器可以處理更大的整數，也就是更大的地址。傳統32位處理器的尋址空間最大為4GB，使得很多需要大容量內存的數據處理程序在這時都會顯得捉襟見肘，形成了運行效率的瓶頸。而64位的處理器在理論上則可以達到1800萬個TB，1TB等於1024GB，1GB等於1024MB，所以64位的處理器能夠徹底解決32位計算系統所遇到的瓶頸現象，速度快人一等，對於那些要求多處理器可擴展性、更大的可尋址內存、視頻/音頻/三維處理或較高計算准確性的應用程序而言，AMD 64處理器可提供卓越的性能。
引用鏈接 http://blog.sina.com.cn/s/blog_4adc4b090102vr3a.html
所謂32位處理器就是一次只能處理32位，也就是4個字節的數據，而64位處理器一次就能處理64位，即8個字節的數據。如果我們將總長128位的指令分別按照16位、32位、64位為單位進行編輯的話：舊的16位處理器，比如Intel 80286 CPU需要8個指令，32位的處理器需要4個指令，而64位處理器則只要兩個指令，顯然，在工作頻率相同的情況下，64位處理器的處理速度會比16位、32位的更快。而且除了運算能力之外，與32位處理器相比，64位處理器的優勢還體現在系統對內存的控制上。由於地址使用的是特殊的整數，而64位處理器的一個ALU（算術邏輯運算器）和寄存器可以處理更大的整數，也就是更大的地址。傳統32位處理器的尋址空間最大為4GB，使得很多需要大容量內存的數據處理程序在這時都會顯得捉襟見肘，形成了運行效率的瓶頸。而64位的處理器在理論上則可以達到1800萬個TB，1TB等於1024GB，1GB等於1024MB，所以64位的處理器能夠徹底解決32位計算系統所遇到的瓶頸現象，速度快人一等，對於那些要求多處理器可擴展性、更大的可尋址內存、視頻/音頻/三維處理或較高計算准確性的應用程序而言，AMD 64處理器可提供卓越的性能。
理論上來說32位的JVM有4G的堆大小限制。但是因為各種條件限制比如交換區，內核地址空間使用，內存碎片，虛擬管理機的管理開銷，實際上可用的堆的大小遠遠比理論上的4G要少。
在32位windows的機器上，堆最大可以達到1.4G至1.6G。
在32位solaris的機器上，堆最大可以達到2G
而在64位的操作系統上，32位的JVM，堆大小可以達到4G
補充一句，在使用java參數-xms -xmx定義堆大小的時候，
1. 如果是32bit的jvm超過4G肯定是沒用的，定義了4G，最終使用到的可能只有2G
2. 這兩個值最好定義成一樣，可以減少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管理越困難,導致相應垃圾回收的性能也會有所不同。