JVM虛擬機器32位和64位有什麼不同
阿新 • • 發佈：2019-01-06
其實就是因為作業系統有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位處理器的優勢還體現在系統對記憶體的控制上。
在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管理越困難,導致相應垃圾回收的效能也會有所不同。
引用連結 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位處理器的優勢還體現在系統對記憶體的控制上。
理論上來說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管理越困難,導致相應垃圾回收的效能也會有所不同。