[[188968]]

概述

通過上篇關(guān)于數(shù)組動(dòng)態(tài)擴(kuò)容導(dǎo)致頻繁GC的文章假笨說-又抓了一個(gè)導(dǎo)致頻繁GC的鬼--數(shù)組動(dòng)態(tài)擴(kuò)容大家或許GET到了這么一些點(diǎn)。

• List里新數(shù)組在新生代分配
• 通過老生代使用率達(dá)到了閾值觸發(fā)的CMS GC，會(huì)把新生代里的對象作為GC ROOT的一部分，從而阻止了那些byte數(shù)組被回收
• 通過-XX:+CMSScavengeBeforeRemark這個(gè)參數(shù)可以解決這個(gè)問題

那是否還想過這么一些問題呢?

• List里新數(shù)組是否可以在老生代分配?
• -XX:+CMSScavengeBeforeRemark該參數(shù)是否一定會(huì)觸發(fā)YGC?

接下來主要圍繞這兩個(gè)問題展開，算是對上篇文章的一個(gè)補(bǔ)充

新數(shù)組在哪里分配

老實(shí)說，如果之前線上碰到的那個(gè)問題新數(shù)組是在老生代分配的話，那就不會(huì)有上篇文章，更不會(huì)有這篇文章，但是到底有沒有可能在老生代分配呢?其實(shí)是有可能的。

上面的代碼是慢速路徑分配的代碼，先判斷是否應(yīng)該到新生代分配

其中_pretenure_size_threshold_words的值是jvm參數(shù)PretenureSizeThreshold指定的，如果我們指定了這個(gè)值，那意味著如果我們單次要求分配的超過了這個(gè)值就想到老生代去分配，當(dāng)然這個(gè)值默認(rèn)是0，表示不會(huì)對對象的大小做check，都優(yōu)先到新生代分配。

如果不到新生代分配，或者新生代分配不了，然后有判斷是否會(huì)到老生代分配的條件。

• 如果要分配的內(nèi)存超過了eden大小，那毫無疑問只能到老生代分配了
• 如果GC_locker正在起作用，有線程正在通過JNI操作臨界內(nèi)存，并且操作完之后會(huì)觸發(fā)一次gc的話，那先到old分配解燃眉之急。
• 如果上一次YGC效果并不好，比如晉升失敗，或者因?yàn)轭A(yù)測到上一次YGC可能是一次失敗的YGC而沒做YGC了等，那就直接到老生代分配吧！

所以新的數(shù)組分配還是有各種可能在老生代分配的，因?yàn)殡S著數(shù)組的不斷擴(kuò)容，數(shù)組也會(huì)變得越來越大，當(dāng)大到某個(gè)程度，或者到上面的某個(gè)條件成立的時(shí)候，還是可能在老生代直接分配的。

那如果新數(shù)組是在老生代分配的話，那經(jīng)過CMS GC就會(huì)將老生代里不可達(dá)的那個(gè)新數(shù)組給回收了，那就不存在新生代指向老生代的跨代引用，因而其實(shí)并不會(huì)發(fā)生這樣的問題。

CMSScavengeBeforeRemark一定能觸發(fā)YGC嗎

CMSScavengeBeforeRemark這個(gè)參數(shù)本意是希望在CMS GC remark之前做一次YGC，正常情況下其實(shí)是會(huì)做一次YGC的，這個(gè)參數(shù)的好處是如果YGC比較有效果的話是能有效降低remark的時(shí)間長度，可以簡單理解為如果大部分新生代的對象被回收了，那作為根的部分少了，從而提高了remark的效率。

但是，但是這個(gè)YGC一定會(huì)發(fā)生嗎?下面對CMS GC remark之前你看到的現(xiàn)象分為三種情況：

• 你壓根看不到Y(jié)GC的日志
• 你可以看到Y(jié)GC日志，同時(shí)能看到內(nèi)存被回收了
• 你可以看到Y(jié)GC日志，但是發(fā)現(xiàn)內(nèi)存根本沒被回收

對于看不到GC日志的情況，可以肯定是沒有發(fā)生YGC，這種情況通過是因?yàn)樯厦嫣岬降腉C_locker導(dǎo)致的，有線程正在訪問臨界區(qū)的內(nèi)存，訪問這些內(nèi)存的時(shí)候是不允許發(fā)生GC的，因?yàn)樗麄冋谥苯硬僮鲀?nèi)存，而GC是會(huì)對對象做遷移的。另外你可能平時(shí)還會(huì)觀察到一個(gè)非常奇怪的現(xiàn)象，偶爾你會(huì)看到有連續(xù)的兩次YGC，其中后面那一次你會(huì)看到新生代使用的內(nèi)存其實(shí)非常少但是也觸發(fā)了一次YGC，其實(shí)就是因?yàn)镚C_locker有補(bǔ)償GC的邏輯。

對于第二種情況，你看到了YGC日志，同時(shí)也發(fā)現(xiàn)內(nèi)存被回收了，這個(gè)毫無疑問，就是真的做了一次正常的YGC。

對于第三種情況，其實(shí)可能并沒有做YGC，當(dāng)然也不排除確實(shí)做了YGC，但是確實(shí)效果不好的情況，那什么情況下會(huì)不做YGC呢，我們看看下面在做YGC之前的代碼。

如果這個(gè)判斷成立，那就直接return了。

而collection_attempt_is_safe在ParNew下的實(shí)現(xiàn)如下

***一條相對比較關(guān)鍵，具體實(shí)現(xiàn)如下：

如果老生代可用的空間足以容得下之前的新生代平均晉升的size，或者容的下新生代現(xiàn)在使用的size，那說明是可以正常做YGC的，那接下來就會(huì)準(zhǔn)備做YGC，但是如果上面的條件都不滿足，那就會(huì)認(rèn)為這次YGC做起來會(huì)沒什么效果，或者比較危險(xiǎn)，***不做，于是就會(huì)直接返回，但是這種情況下，YGC的日志還是照常會(huì)打的，你看到的現(xiàn)象就是YGC前后內(nèi)存大小不變。

總結(jié)

還是總結(jié)下吧，針對動(dòng)態(tài)數(shù)組擴(kuò)容的問題，可以有兩種情況

• 如果新擴(kuò)容的數(shù)組是在老生代的，如果該數(shù)組不可達(dá)了，那經(jīng)過CMS GC是會(huì)回收數(shù)組里的內(nèi)容的。
• 如果新擴(kuò)容的數(shù)組是在新生代的，如果該數(shù)組不可達(dá)了，CMSScavengeBeforeRemark無法完全保證YGC能順利進(jìn)行，如果真的做了YGC，那肯定可以回收掉數(shù)組里的不可達(dá)的那些byte數(shù)組，如果因?yàn)楦鞣N限制導(dǎo)致YGC并沒有做，那還是無法回收掉數(shù)組里面的內(nèi)容。

【本文是51CTO專欄作者李嘉鵬的原創(chuàng)文章，轉(zhuǎn)載請通過微信公眾號(你假笨，id:lovestblog)聯(lián)系作者本人獲取授權(quán)】

戳這里，看該作者更多好文