YGC前后新生代是否變大分析詳解
問(wèn)題描述
我們都知道gc是為了釋放內(nèi)存,但是你是否碰到過(guò)ygc前后新生代反增不減的情況呢?gc日志效果類(lèi)似下面的:
2016-05-18T15:06:13.011+0800: [GC [ParNew (promotion failed): 636088K->690555K(707840K), 0.2958900 secs][CMS: 1019739K->1019733K(1310720K), 2.6208600 secs] 1655820K->1655820K(2018560K), [CMS Perm : 205486K->205486K(262144K)], 2.9174390 secs] [Times: user=3.74 sys=0.01, real=2.91 secs]
從上面的gc日志來(lái)看,我們新生代使用的是ParNew,而老生代用的是CMS GC,我們注意到ParNew的效果是新生代從636088K新增到了690555K,這是什么情況?
原理分析
要解釋這個(gè)問(wèn)題,我們先要弄清楚YGC的過(guò)程,parNew是新生代的gc算法,簡(jiǎn)單來(lái)說(shuō)從gc roots開(kāi)始掃描對(duì)象,當(dāng)掃到一個(gè)只要是屬于新生代的對(duì)象就將其挪到to space,但是老的對(duì)象還不會(huì)做釋放,直到gc完成之后再看是否釋放老的對(duì)象(比如說(shuō)上面我們看到了promotion failed的關(guān)鍵字,意味著晉升失敗了,也就是說(shuō)to和old都裝不下新生代晉升來(lái)的對(duì)象,那么在這種情況下其實(shí)是不會(huì)對(duì)eden和from里的老對(duì)象做釋放的,盡管to space里已經(jīng)可能存在一份副本了),但是在gc前后不管是否晉升成功,都會(huì)對(duì)from space和to space做一個(gè)對(duì)換,也就是原來(lái)的from變成to,原來(lái)的to變成from,再來(lái)看看打印gc前后內(nèi)存變化的代碼
void GenCollectedHeap::print_heap_change(size_t prev_used) const {
if (PrintGCDetails && Verbose) {
gclog_or_tty->print(" " SIZE_FORMAT
"->" SIZE_FORMAT
"(" SIZE_FORMAT ")",
prev_used, used(), capacity());
} else {
gclog_or_tty->print(" " SIZE_FORMAT "K"
"->" SIZE_FORMAT "K"
"(" SIZE_FORMAT "K)",
prev_used / K, used() / K, capacity() / K);
}
}
size_t GenCollectedHeap::used() const {
size_t res = 0;
for (int i = 0; i < _n_gens; i++) {
res += _gens[i]->used();
}
return res;
}
size_t DefNewGeneration::used() const {
return eden()->used()
+ from()->used(); // to() is only used during scavenge
}
從上面代碼我們知道,gc之后的內(nèi)存情況是used()方法返回的,其中新生代的used方法返回的是eden+from的內(nèi)存,同樣的上面的prev_used也是這么計(jì)算的,只是發(fā)生在gc之前,這樣一來(lái),根據(jù)我上面提到的情況,在gc之后不管是否成功都會(huì)做一次from和to的swap,那么gc之前新生代的使用大小,其實(shí)是gc之前eden+from的使用大小,而gc之后的新生代的使用大小,其實(shí)是eden+原來(lái)的to現(xiàn)在是使用的大小,原來(lái)的to現(xiàn)在使用的大小其實(shí)就是在gc過(guò)程中將eden和from拷貝過(guò)來(lái)的對(duì)象所占的大小。
綜上分析你應(yīng)該知道為什么會(huì)出現(xiàn)這種情況了,其實(shí)是一種特殊情況,只有在出現(xiàn)promotion failed的情況下才會(huì)發(fā)生這樣的情況,因?yàn)樵谶@個(gè)情況下存在to里新增對(duì)象,而from和eden不會(huì)變化的情況
以上就是YGC前后新生代是否變大分析詳解的詳細(xì)內(nèi)容,更多關(guān)于YGC前后新生代是否變的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
Springboot集成Actuator監(jiān)控功能詳解
這篇文章主要介紹了Springboot集成Actuator監(jiān)控功能詳解,有時(shí)候我們想要實(shí)時(shí)監(jiān)控我們的應(yīng)用程序的運(yùn)行狀態(tài),比如實(shí)時(shí)顯示一些指標(biāo)數(shù)據(jù),觀察每時(shí)每刻訪問(wèn)的流量,或者是我們數(shù)據(jù)庫(kù)的訪問(wèn)狀態(tài)等等,這時(shí)候就需要Actuator了,需要的朋友可以參考下2023-09-09
深入解析StringBuffer和StringBuilder的區(qū)別
以下是對(duì)java中StringBuffer與StringBuilder的區(qū)別進(jìn)行了詳細(xì)的分析介紹,需要的朋友可以參考下2013-07-07
SpringBoot整合Ehcache3的實(shí)現(xiàn)步驟
本文主要介紹了SpringBoot整合Ehcache3的實(shí)現(xiàn)步驟,文中通過(guò)示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2022-01-01
Apache DolphinScheduler實(shí)現(xiàn)自動(dòng)化打包單機(jī)/集群部署詳解
這篇文章主要為大家介紹了Apache DolphinScheduler實(shí)現(xiàn)自動(dòng)化打包單機(jī)/集群部署詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-09-09
Sleuth(Micrometer)+ZipKin分布式鏈路問(wèn)題小結(jié)
在微服務(wù)架構(gòu)中,分布式鏈路追蹤技術(shù)成為了解決系統(tǒng)復(fù)雜調(diào)用問(wèn)題的關(guān)鍵,本文介紹了其他鏈路追蹤方案,如Cat、Pinpoint和Skywalking,展示了分布式鏈路追蹤技術(shù)的多樣化,感興趣的朋友一起看看吧2024-10-10

