“眼鏡蛇效應(yīng)”一詞源于英國殖民印度統(tǒng)治英國時(shí)所產(chǎn)生的軼事。 英國政府擔(dān)心毒蛇眼鏡蛇的數(shù)量。 因此，政府對(duì)每條死蛇給予懸賞。 最初，這是一個(gè)成功的策略，因?yàn)榇罅可弑粴⑺酪垣@取獎(jiǎng)勵(lì)。 最終，印度人開始養(yǎng)殖眼鏡蛇以賺取收入。

當(dāng)意識(shí)到這一點(diǎn)時(shí)，獎(jiǎng)勵(lì)就被取消了，但是眼鏡蛇飼養(yǎng)者放開了蛇，因此野生眼鏡蛇成倍增加。 解決問題的明顯辦法使情況更加惡化。

那么Java堆大小與殖民地印度和毒蛇有何關(guān)系？ 忍受我，我將以現(xiàn)實(shí)生活中的故事為參考來指導(dǎo)您進(jìn)行類比。 術(shù)語“眼鏡蛇效應(yīng)” 您已經(jīng)創(chuàng)建了一個(gè)了不起的應(yīng)用程序。 令人驚訝的是，它變得真正流行，并且新服務(wù)的龐大流量開始使您的應(yīng)用程序屈服。 通過瀏覽性能指標(biāo)，您可以確定可用于應(yīng)用程序的堆數(shù)量很快將成為瓶頸。

因此，您需要花一些時(shí)間來啟動(dòng)具有原始堆六倍的新基礎(chǔ)結(jié)構(gòu)。 您測(cè)試您的應(yīng)用程序以驗(yàn)證它是否有效。 然后，您可以在新的基礎(chǔ)架構(gòu)上啟動(dòng)它。 投訴立即涌入–您的應(yīng)用程序變得比原始的2GB小堆響應(yīng)速度慢。 您的某些用戶在等待您的應(yīng)用程序響應(yīng)時(shí)會(huì)遇到幾分鐘的延遲。 剛剛發(fā)生了什么事？

當(dāng)然有很多原因。 但是，讓我們關(guān)注最可能的嫌疑犯–堆大小更改。 這有一些可能的副作用，例如延長緩存預(yù)熱時(shí)間，碎片問題等。但是從出現(xiàn)的癥狀來看，您可能會(huì)在完整的GC運(yùn)行期間在應(yīng)用程序中遇到延遲問題 。

這意味著-因?yàn)镴ava是一種垃圾收集語言-JVM內(nèi)部進(jìn)程會(huì)定期對(duì)您使用的堆進(jìn)行垃圾收集。 就像人們可能期望的那樣-如果您有更大的房間要打掃，那么看門人通常會(huì)花費(fèi)更多的時(shí)間來打掃房間。 這同樣適用于從內(nèi)存中清除未使用的對(duì)象。

在小堆（小于4GB）上運(yùn)行應(yīng)用程序時(shí)，通常不需要考慮GC內(nèi)部。 但是，當(dāng)將堆大小增加到數(shù)十GB時(shí)，您絕對(duì)應(yīng)該意識(shí)到整個(gè)GC可能導(dǎo)致的世界停頓。 對(duì)于較小的堆大小，也確實(shí)存在相同的暫停，但是它們的長度明顯縮短了–您現(xiàn)在暫停超過一分鐘的暫停本來可能只跨越了幾百毫秒。

那么，如果您確實(shí)需要更多應(yīng)用程序堆，該怎么辦？

• 第一種選擇是考慮水平縮放而不是垂直縮放。 對(duì)于我們當(dāng)前的情況，這意味著–如果您的應(yīng)用程序是無狀態(tài)的或易于分區(qū)的，則只需添加更多的小節(jié)點(diǎn)并平衡它們之間的負(fù)載即可。 在這種情況下，您可以堅(jiān)持使用32位架構(gòu)，這也會(huì)占用較小的內(nèi)存 。
• 如果無法進(jìn)行水平縮放，則應(yīng)專注于GC配置。 如果您要等待的是延遲，那么您應(yīng)該忘記面向吞吐量的世界一流GC，并開始尋找替代方案。 您很快會(huì)發(fā)現(xiàn)它們僅限于并發(fā)標(biāo)記和掃描（CMS）或垃圾優(yōu)先（G1）收集器。 最可悲的消息是，只有通過實(shí)驗(yàn)才能找到這兩種收集器類型和其他堆配置參數(shù)之間的最佳選擇。 因此，不要僅通過閱讀一些東西，走出去然后嘗試一下實(shí)際的生產(chǎn)負(fù)荷來做出選擇。

但也要注意它們的局限性-這兩個(gè)收集器都給您的應(yīng)用程序帶來了吞吐量開銷-特別是G1的吞吐量數(shù)字往往比世界其他同類產(chǎn)品差。 而且，如果CMS垃圾收集器的速度不夠快，無法在永久性生成器已滿之前完成操作，則它會(huì)退回到標(biāo)準(zhǔn)的世界各地GC。 因此，對(duì)于大小為16 GB及以上的堆，您仍然可以面對(duì)30秒或更長時(shí)間的暫停。

• 如果您無法在Oracle JVM附帶的垃圾收集器上進(jìn)行水平擴(kuò)展或無法達(dá)到所需的延遲結(jié)果，那么您也可以考慮Azul Systems構(gòu)建的Zing JVM 。 使Zing脫穎而出的功能之一是無休止的垃圾收集器（C4） ，這可能正是您所需要的。 但是，要全面披露–我們尚未在實(shí)踐中嘗試過C4。 但這聽起來很酷。
• 最后選擇是真正的硬核家伙。 您可以在堆外部分配內(nèi)存。 這些分配顯然對(duì)垃圾收集器不可見，因此不會(huì)被收集。 這聽起來可能很可怕，但是從Java 1.4開始，我們已經(jīng)可以訪問java.nio.ByteBuffer類，該類為我們提供了一種用于堆外內(nèi)存分配的方法allocateDirect（）。 這使我們可以創(chuàng)建非常大的數(shù)據(jù)結(jié)構(gòu)，而不會(huì)遇到數(shù)秒的GC暫停。 這種解決方案并不太常見-許多BigMemory實(shí)現(xiàn)都在后臺(tái)使用ByteBuffer。 例如， 兵馬俑BigMemory和Apache DirectMemory 。

結(jié)論—即使有良好的意愿進(jìn)行更改，也要注意替代方案和后果。 就像印度政府過去公布死眼鏡蛇的報(bào)酬一樣 。

參考： 增大堆大小–在Plumbr Blog博客上， 請(qǐng)注意我們JCG合作伙伴 Nikita Salnikov Tarnovski 的Cobra 。

翻譯自: https://www.javacodegeeks.com/2012/12/increasing-heap-size-beware-of-the-cobra-effect.html

總結(jié)

以上是生活随笔為你收集整理的增加堆大小–谨防眼镜蛇效应的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。