即使到了今天（2015年），我們仍然有兩個版本或Oracle HotSpot JDK –已調整為32或64位體系結構。 問題是我們是否真的想在服務器甚至筆記本電腦上使用32位JVM？ 我們應該有很受歡迎的意見！ 如果只需要較小的堆，則使用32位–它具有較小的內存占用空間，因此您的應用程序將使用較少的內存并觸發較短的GC暫停。 但這是真的嗎？ 我將探索三個不同的領域：

內存占用

GC性能

整體表現

讓我們從內存消耗開始。

內存占用

眾所周知，32位和64位JVM之間的主要區別與內存尋址有關。 這意味著所有在64位版本上的引用都占用8個字節而不是4個字節。幸運的是，JVM附帶了壓縮對象指針 ，默認情況下，所有小于26GB的堆都啟用該對象指針 。 只要32位JVM可以尋址大約2GB（取決于目標操作系統，它仍然要少13倍），那么這個限制對我們來說是可以接受的。 因此，不必擔心對象引用。 唯一不同的對象布局是標記標頭，它在64位上大4個字節。 我們還知道Java中的所有對象都是8字節對齊的，因此有兩種可能的情況：

• 最糟糕的是– 64位對象比32位對象大8個字節。 這是因為在標頭中添加4個字節會導致對象被丟棄到另一個內存插槽中，因此我們必須再添加4個字節來填充對齊間隙。
• 最佳–兩種體系結構上的對象具有相同的大小。 當在32位上有4個字節的對齊間隙時，就會發生這種情況，可以通過其他標記頭字節簡單地填充該間隙。

現在假設兩種不同的應用程序大小來計算這兩種情況。 加載了相當大項目的IntelliJ IDEA包含大約700萬個對象，這將是我們的較小項目。 對于第二個選項，假設我們有一個大型項目（我稱其為“巨大”），其中包含5000萬個對象。 現在讓我們計算最壞的情況：

• IDEA -> 7 millions * 8 bytes = 53 MB
• Huge -> 50 millions * 8 bytes = 381 MB

上面的計算向我們顯示，在最壞的情況下，IntelliJ會增加大約50MB的堆，而對于某些帶有很小對象的高度粒度化的大型項目，實際的應用程序占地會增加大約400MB。 在第二種情況下，它可能占總堆的25％左右，但是對于絕大多數項目而言，它約為2％，幾乎沒有。

GC性能

這個想法是使用長鍵將800萬個String對象放入Cache中。 一個測試包含4個調用，這意味著有2400萬次放入緩存映射。 我使用并行GC，將總堆大小設置為2GB。 結果令人驚訝，因為整個測試很快就在32位JDK上完成了。 3分40秒，而64位虛擬機為4分30秒。 比較GC日志后，我們可以看到，差異主要來自GC暫停：114秒到157秒。 這意味著實際上32位JVM帶來的GC開銷要低得多-64位554可以暫停到618。 在下面，您可以查看GC Viewer的屏幕截圖（兩個軸上的縮放比例均相同）

32位JVM并行GC

64位JVM并行GC

我原本希望64位JVM的開銷較小，但是基準測試表明，即使總堆使用量在32位上也差不多，我們在Full GC上釋放了更多的內存。 年輕一代的停頓時間也相似-兩種架構大約為0.55秒。 但是，平均主要停頓在64位上更高，為3.2，而32位上為2.7。 事實證明，小堆的GC性能在32位JDK上要好得多。 問題是您的應用程序對GC的要求是否很高–在測試中，平均吞吐量約為42-48％。

在更多的“企業”場景中進行了第二次測試。 我們正在從數據庫加載實體，并在加載的列表上調用size（）方法。 對于大約6分鐘的總測試時間，對于64位，我們有133.7s的總暫停時間，對于32位，我們有130.0s的總暫停時間。 堆的使用也非常相似– 64位為730MB，32位JVM為688MB。 這向我們顯示，對于正常的“企業”用法，在各種JVM架構上的GC性能之間沒有太大差異。

從數據庫中選擇32位JVM并行GC

64位JVM并行GC從數據庫中選擇

即使具有類似的GC性能，32位JVM仍可以在20秒前完成工作（大約5％）。

整體表現

當然，要驗證適用于所有應用程序的JVM性能幾乎是不可能的，但是我將嘗試提供一些有意義的結果。 首先，讓我們檢查時間性能。

Benchmark 32bits [ns] 64bits [ns] ratioSystem.currentTimeMillis() 113.662 22.449 5.08 System.nanoTime() 128.986 20.161 6.40findMaxIntegerInArray 2780.503 2790.969 1.00 findMaxLongInArray 8289.475 3227.029 2.57 countSinForArray 4966.194 3465.188 1.43UUID.randomUUID() 3084.681 2867.699 1.08

正如我們所看到的，與長變量相關的所有操作的最大且絕對明顯的區別是。 在64位JVM上，這些操作的速度是2.6到6.3倍之間。 使用整數非常相似，生成隨機UUID的速度也快7％左右。 值得一提的是，解釋代碼（-Xint）具有相似的速度-僅64位版本的JIT效率更高。 那么有什么特別的區別嗎？ 是! 64位體系結構帶有JVM使用的其他處理器寄存器。 檢查生成的程序集后，看起來性能提升主要來自使用64位寄存器的可能性，這可以簡化長時間的操作。 可以在Wiki頁面下找到任何其他更改。 如果要在計算機上運行此程序，則可以在我的GitHub上找到所有基準測試– https://github.com/jkubrynski/benchmarks_arch

結論

在整個IT世界中，我們不能簡單地回答-“是的，您應該始終使用** bits JVM”。 這在很大程度上取決于您的應用程序特征。 如我們所見，32位和64位體系結構之間存在許多差異。 即使長期相關操作的JIT性能提高了幾百個百分點，我們也可以看到，經過測試的批處理進程在32位JVM上更早完成。 結論–沒有簡單的答案。 您應該始終檢查哪種架構更適合您的要求。

非常感謝Wojtek Kudla審閱本文并執行其他測試:)

翻譯自: https://www.javacodegeeks.com/2015/05/do-we-really-still-need-a-32-bit-jvm.html

總結

以上是生活随笔為你收集整理的我们真的仍然需要32位JVM吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。