Java 32位和64位優化模式（-XX：-UseCompressedOops）內存開銷

我試圖預測堆內存需求更改的情況下，當我在配置爲使用超過32GB的內存的JVM中運行我的Java應用程序時不變。Java 32位和64位優化模式（-XX：-UseCompressedOops）內存開銷

我希望在將Xmx參數從32GB重新配置到64GB後，我在內存中保留相同數量的「有用」對象會產生大量內存開銷。

我試圖通過在本地機器上運行-XX:-UserCompressedOps來模擬和估計差異，我的本地機器使用小堆（8GB）運行，但尚未得出結論。根據運行時間計算，在兩種情況下，我的對象都佔用相同數量的內存。已關閉優化的堆使用會更多一些，但絕不會再增加兩倍，因爲我可以期望讀一些解釋。

在我的使用案例中，我簡單地在程序的整個生命週期中保存大量相對較大的POJO對象100-1K。

僅僅通過跨越32GB限制（當32位優化不再適用時），對於內存要求如何增長，有沒有經驗法則？

所以問題是當你關閉CompressedOops會發生什麼？或者，當您有<32GB堆內存時，JVM是否還有其他優化？ – Thilo

我只用這一個參數設置/未設置進行測試，其餘的都是default HotSpot 1.7參數。我也試圖比較只有最大堆從小於32GB增加到更多的情況。 –

據說（http://stackoverflow.com/a/13549938/14955）丟失CompressedOops意味着堆大小在32GB到48GB之間是沒有意義的。你需要超越48GB來彌補更長的指針。 – Thilo

但絕不會再增加兩倍，因爲我可以期望讀一些解釋。

我的理解是禁用CompressedOops只會增加指針大小（引用類型），而不是原始類型，特別是不是字符串，字節數組等等。所以如果你的堆是由原始類型的數組支配的，那麼增加可能很難注意到。

對齊要求也使得尺寸差異不那麼直接，因爲較大的指針可能只是最終填充一些對齊填充。

2015-01-16 17:30:24 the8472

這個答案總結了它。 Oracle詳細信息：https：//wikis.oracle.com/display/HotSpotInternals/CompressedOops – spudone

對，這不是估計的經驗法則。我正在考慮使用jmap，計算對象的數量並從中推導出數字。 –

只會給你下限，因爲每個對象必須被引用一次/至少一個指針本身。另一方面，如果它完全由參考數組組成，你會看到你的堆幾乎完全翻倍。 – the8472

回答