文章來源：https://dwz.cn/7YcSeVQk
看ES官方文檔時，提到的一個觀點：
Don’t Cross 32 GB！
因為當JVM堆少於32G時，HotSpot虛擬機會啟用一個壓縮對象指針，而如果超過32G，這個壓縮對象指針就會失效。
那麼，糾結這個臨界值的精確值是多大呢？
開啟壓縮指針相比沒有開啟，能節省多少內存呢？
讓我們一探究竟！
不要超過32 GB!
在Java的世界裡，絕大部分對象分配在堆裡，並且被一個指針引用（Student stu = new Student()，new的這個Student對象就是分配在堆裡，stu就是持有這個對象的引用）。
32位的操作系統，最大隻支持4G內存（即2^32）。當然，對於當下來說，32位服務器應該是絕種了，所以本文討論的是64位操作系統。對於64位操作系統來說，理論上分配的堆可以非常非常大。但是，64位指針的開銷就意味著有更多的浪費空間，這僅僅是因為指針更大。比浪費空間更糟糕的是，64位指針在主內存和多級緩存之間移動數據的時候，還會消費更多的帶寬。
Java用"compressed oops"術解決了這個問題，指針不再是指向內存中精確位置，而是對象的偏移量（原文：Instead of pointing at exact byte locations in memory, the pointers reference object offsets）。這就意味著，32位指針能引用2^32個對象（大約43億個對象），而不是引用總計2^32個字節大小對象。基本上，堆大小直到32G左右還能保持32位指針。
一旦你越過這個32G--一個具有魔法般的數值。指針將切回到普通的對象指針。每個指針變大，意味著需要更多的CPU，內存和帶寬，真正用來保持對象的內存就會更少。這就可能導致一種奇怪的現象，使用compressed oops的32G的堆和40~50G沒有使用compressed oops的堆保存的對象數量是一樣的。
這個事實告訴我們：即使你有多餘的內存，也應該儘量避免超過32G這個界限。它會浪費內存，降低CPU性能，並且大堆情況下GC表現也一般般。更麻煩的是，那麼大的堆，DUMP分析將是一件極其痛苦，極其麻煩的事情。相信我，你一定不想碰到那種局面。
應該設置多大？
32G是個近似值，這個臨界值跟JVM和平臺有關。如果不想精確設置的話，31G是個決定安全的數值，31G肯定默認開啟compressed oops。我們可以通過增加JVM參數-XX:+PrintFlagsFinal，驗證UseCompressedOops的值，從而得知，到底是不是真的開啟了壓縮指針，還是壓縮指針失效！
實踐才是檢驗真理的唯一標準！JUST DO IT！讓我們動手驗證這個臨界值吧！
驗證情況--JDK8前提下，32760m的堆是開啟壓縮指針的，32770m的堆壓縮指針已經關閉：
32G，即32*1024=32768M，剛好在範圍[32760, 32770]中。
土豪我有1T內存
JVM大堆的缺點太多了；
- 超過32G壓縮指針失效；
- DUMP分析將是災難；
- 堆越大，GC表現越差；
總之，不要嘗試吃這個螃蟹！那如果我是在一家有錢任性的公司，服務器牛逼的不要不要的，都是128G起步！畢竟不要讓貧窮限制了想象！
這種情況下，我有小建議：開多個32G的JVM實例。4個32G的JVM實例絕對比1個128G實例表現要好。
簡單測試驗證
筆者做了一個簡單測試，（測試源碼請看原文）驗證一下這個問題：分配設置Xmx為Xmx32760m和Xmx32770m，Xmn都是100M（S0:S1:Eden默認1:1:8）。總結分配一個包含8個對象類型和8個原子類型以及String，總計17個類型屬性的對象1kw次。看它們分別觸發了多少YGC，結論如下表所示：
由執行結果可知，Young區完全一樣的情況下，開啟壓縮指針相比關閉壓縮指針，能節省20%多的內存。由此可知，32G還真是一個奇妙的魔法數值！另外需要說明的是YGC次數有小數，是表示Eden區佔用比例，比如17.52次YGC表示發生了17次YGC別切Eden還佔了52%。
執行的命令：
說明：
-Xmx32760m -Xms32760m即表示開啟壓縮指針；
-Xmx32770m -Xms32770m即表示關閉壓縮指針。
我目前是在職Java開發，如果你現在正在瞭解Java技術，想要學好Java，渴望成為一名Java開發工程師，在入門學習Java的過程當中缺乏基礎的入門視頻教程，你可以關注並私信我：01。我這裡有一套最新的Java基礎JavaSE的精講視頻教程，這套視頻教程是我在年初的時候，根據市場技術棧需求錄製的，非常的系統完整。
閱讀更多 Java架構人生 的文章
