“Stop the World”問題分析

JVM最讓人無奈的痛點(diǎn)！

1、前文回顧

上一篇文章已經(jīng)通過一個(gè)真實(shí)的案例分析了新生代的對(duì)象分配以及如何轉(zhuǎn)移到老年代，如何頻繁觸發(fā)Full GC的一個(gè)場(chǎng)景，同時(shí)給出了優(yōu)化的說明

相信大家通過上一篇文章就已經(jīng)非常深刻的理解了JVM的核心運(yùn)行原理了。

這篇文章我們就來討論一下基于JVM運(yùn)行的Java系統(tǒng)，最讓我們Java工程師內(nèi)心痛苦的到底是個(gè)什么問題？

2、先來回顧一個(gè)新生代GC的場(chǎng)景

大家先來看下面的圖，新生代的內(nèi)存大家都知道是分為Eden和兩個(gè)Survivor的。

那么此時(shí)如果系統(tǒng)不停的運(yùn)行，然后把Eden給塞滿了呢？如下圖所示。

這個(gè)時(shí)候勢(shì)必就會(huì)觸發(fā)Minor GC了，好，那么之前給大家說過，進(jìn)行垃圾回收是有專門的垃圾回收線程的，而且對(duì)不同的內(nèi)存區(qū)域會(huì)有不同的垃圾回收器，大家還記得這個(gè)事兒?jiǎn)幔?/span>

相當(dāng)于垃圾回收線程和垃圾回收器配合起來，使用自己的垃圾回收算法，對(duì)指定的內(nèi)存區(qū)域進(jìn)行垃圾回收，大家看看下圖。

通過上面這個(gè)圖，大家對(duì)垃圾回收線程、垃圾回收器以及垃圾回收算法，是不是就有了一個(gè)非常清晰的關(guān)系的認(rèn)識(shí)了？

沒錯(cuò)，垃圾回收一定會(huì)通過一個(gè)后臺(tái)運(yùn)行的垃圾回收線程來執(zhí)行他具體的一個(gè)邏輯

比如針對(duì)新生代我們會(huì)用ParNew垃圾回收器來進(jìn)行回收，然后ParNew垃圾回收器針對(duì)新生代采用的就是復(fù)制算法來垃圾回收。

這個(gè)時(shí)候垃圾回收器，就會(huì)把Eden區(qū)中的存活對(duì)象都標(biāo)記出來，然后全部轉(zhuǎn)移到Survivor1去，接著一次性清空掉Eden中的垃圾對(duì)象，如下圖。

接著系統(tǒng)繼續(xù)運(yùn)行，新的對(duì)象繼續(xù)分配在Eden中，如下圖所示。

當(dāng)Eden再次塞滿的時(shí)候，就又要觸發(fā)Minor GC了，此時(shí)已然是垃圾回收線程運(yùn)行垃圾回收器中的算法邏輯，也就是采用復(fù)制算法邏輯，去標(biāo)記出來Eden和Survivor1中的存活對(duì)象

然后一次性把存活對(duì)象轉(zhuǎn)移到Survivor2中去，接著把Eden和Survivor1中的垃圾對(duì)象都回收掉，如下圖。

3、GC的時(shí)候還能繼續(xù)創(chuàng)建新的對(duì)象嗎？

不知道大家有沒有考慮過一個(gè)問題，之前我們一直都是說GC的原理和JVM整體運(yùn)行的機(jī)制

但是從來沒說過在GC的時(shí)候，到底我們寫好的Java系統(tǒng)在運(yùn)行期間還能不能繼續(xù)在新生代里創(chuàng)建新的對(duì)象了？

大家可以自己思考一下，假設(shè)允許在GC期間，然后還可以繼續(xù)讓系統(tǒng)在新生代的Eden區(qū)里創(chuàng)建新的對(duì)象，會(huì)是一個(gè)什么樣的場(chǎng)景？

大家看下圖。

根據(jù)上圖所示，如果一邊垃圾回收器在想辦法把Eden和Survivor2里的存活對(duì)象標(biāo)記出來轉(zhuǎn)移到Survivor1去，然后還在想辦法把Eden和Survivor2里的垃圾對(duì)象都清理掉，結(jié)果這個(gè)時(shí)候系統(tǒng)程序還在不停的在Eden里創(chuàng)建新的對(duì)象。

這些新的對(duì)象有的很快就成了垃圾對(duì)象，有的還有人引用是存活對(duì)象，那現(xiàn)在咋辦？

全部亂套了，對(duì)于程序新創(chuàng)建的這些對(duì)象，你怎么讓垃圾回收器去持續(xù)追蹤這些新對(duì)象的狀態(tài)？

怎么想辦法在這次垃圾回收的過程中把新對(duì)象中的那些存活對(duì)象轉(zhuǎn)移到Survivor2中去？

怎么想辦法把新創(chuàng)建的對(duì)象中的垃圾都給回收了？

有的同學(xué)可能會(huì)想當(dāng)然的說，那就想辦法讓垃圾回收器來做到??！

我只能說，大家可以去搞清楚JVM的運(yùn)行原理，但是不要隨意去質(zhì)疑人家JVM的垃圾回收機(jī)制為什么不去那么設(shè)計(jì)。

因?yàn)橛行┦虑橄胫芎?jiǎn)單，但是一旦你要在JVM中去實(shí)現(xiàn)的時(shí)候，會(huì)發(fā)現(xiàn)務(wù)必的復(fù)雜，成本極高，而且很難做到。

所以說，在垃圾回收的過程中，同時(shí)還允許我們寫的Java系統(tǒng)繼續(xù)不停的運(yùn)行在Eden里持續(xù)創(chuàng)建新的對(duì)象，目前來看是非常不合適的一個(gè)事情。

4、JVM的痛點(diǎn)：Stop the World

所以現(xiàn)在大家就好理解了，我們平時(shí)使用JVM最大的痛點(diǎn)，其實(shí)就是在垃圾回收的這個(gè)過程

因?yàn)樵诶厥盏臅r(shí)候，盡可能要讓垃圾回收器專心致志的干工作，不能隨便讓我們寫的Java系統(tǒng)繼續(xù)對(duì)象了，所以此時(shí)JVM會(huì)在后臺(tái)直接進(jìn)入“Stop the World”狀態(tài)。

也就是說，他會(huì)直接停止我們寫的Java系統(tǒng)的所有工作線程，讓我們寫的代碼不再運(yùn)行！

然后讓垃圾回收線程可以專心致志的進(jìn)行垃圾回收的工作，如下圖所示。

這樣的話，就可以讓我們的系統(tǒng)暫停運(yùn)行，然后不再創(chuàng)建新的對(duì)象，同時(shí)讓垃圾回收線程盡快完成垃圾回收的工作，就是標(biāo)記和轉(zhuǎn)移Eden以及Survivor2的存活對(duì)象到Survivor1中去，然后盡快一次性回收掉Eden和Survivor2中的垃圾對(duì)象，如下圖。

接著一旦垃圾回收完畢，就可以繼續(xù)恢復(fù)我們寫的Java系統(tǒng)的工作線程的運(yùn)行了，然后我們的那些代碼就可以繼續(xù)運(yùn)行，繼續(xù)在Eden中創(chuàng)建新的對(duì)象，如下圖。

5、Stop the World造成的系統(tǒng)停頓

現(xiàn)在大家就很清晰“Stop the World”會(huì)對(duì)系統(tǒng)造成的影響了， 假設(shè)我們的Minor GC要運(yùn)行100ms，那么可能就會(huì)導(dǎo)致我們的系統(tǒng)直接停頓100ms不能處理任何請(qǐng)求

在這100ms期間用戶發(fā)起的所有請(qǐng)求都會(huì)出現(xiàn)短暫的卡頓，因?yàn)橄到y(tǒng)的工作線程不在運(yùn)行，不能處理請(qǐng)求。

假設(shè)你開發(fā)的是一個(gè)Web系統(tǒng)，那么可能導(dǎo)致你的用戶從網(wǎng)頁或者APP上點(diǎn)擊一個(gè)按鈕，然后平時(shí)只要幾十ms就可以返回響應(yīng)了

現(xiàn)在因?yàn)槟愕腤eb系統(tǒng)的JVM正在執(zhí)行Minor GC，暫停了所有的工作線程，導(dǎo)致你的請(qǐng)求過來到響應(yīng)返回，這次需要等待幾百毫秒。

那么大家可以思考一下，回憶一下上篇文章講到的案例，因?yàn)閮?nèi)存分配不合理，導(dǎo)致對(duì)象頻繁進(jìn)入老年代，平均七八分鐘一次Full GC，而Full GC是最慢的，有的時(shí)候弄不好一次回收要進(jìn)行幾秒鐘，甚至幾十秒，有的極端場(chǎng)景幾分鐘都是有可能的。

那么此時(shí)一旦你頻繁的Full GC，難道你希望你的系統(tǒng)每隔七八分鐘就卡死個(gè)30秒嗎？

在30秒內(nèi)任何用戶的請(qǐng)求全部卡死無法處理，然后用戶看到的都是系統(tǒng)超時(shí)之類的提示，這會(huì)讓用戶體驗(yàn)極差

所以說，無論是新生代GC還是老年代GC，都盡量不要讓頻率過高，也避免持續(xù)時(shí)間過長(zhǎng)，避免影響系統(tǒng)正常運(yùn)行，這也是使用JVM過程中一個(gè)最需要優(yōu)化的地方，也是最大的一個(gè)痛點(diǎn)。

6、不同的垃圾回收器的不同的影響

接著今天的話題，再來延伸說一下昨天提到的那些垃圾回收器

比如對(duì)新生代的回收，Serial垃圾回收器就是用一個(gè)線程進(jìn)行垃圾回收，然后此時(shí)暫停系統(tǒng)工作線程，所以一般我們?cè)诜?wù)器程序中很少用這種方式。

但是我們平時(shí)常用的新生代垃圾回收器是ParNew，他針對(duì)服務(wù)器一般都是多核CPU做了優(yōu)化，他是支持多線程個(gè)垃圾回收的，可以大幅度提升回收的性能，縮短回收的時(shí)間

所以下周我們深入分析這塊的時(shí)候，會(huì)告訴大家他的很多參數(shù)該如何優(yōu)化

大致原理圖如下

大家可以看到，不同的垃圾回收器他會(huì)有不同的機(jī)制和原理，使用多線程或者單線程，都是有區(qū)別的。

然后包括之前給大家提到的CMS垃圾回收器，專門負(fù)責(zé)老年代的垃圾回收，他也有自己特殊的一套機(jī)制和原理，非常的復(fù)雜

下周會(huì)深入講CMS垃圾回收器的原理和參數(shù)優(yōu)化，他也是基于多線程的，而且可以使用一套獨(dú)特的機(jī)制盡可能的在垃圾回收的過程中減少“Stop the World”的時(shí)間，避免長(zhǎng)時(shí)間卡死我們的系統(tǒng)。

包括下下周要深入剖析的現(xiàn)在很多公司都在使用的最新的G1垃圾回收器，他更是將采用復(fù)雜的回收機(jī)制將回收性能優(yōu)化到機(jī)制，盡可能更多的降低“Stop the World”的時(shí)間。

其實(shí)JVM本身的迭代演進(jìn)，就是不斷的在優(yōu)化垃圾回收器的機(jī)制和算法，盡可能的降低垃圾回收的過程對(duì)我們的系統(tǒng)運(yùn)行的影響。

而我們作為一個(gè)合格的Java工程師，我們的責(zé)任就是盡可能搞懂這些垃圾回收器的運(yùn)行機(jī)制和算法

然后合理的對(duì)線程系統(tǒng)優(yōu)化內(nèi)存分配和垃圾回收，盡可能減少垃圾回收的頻率，降低垃圾回收的時(shí)間，減少垃圾回收對(duì)系統(tǒng)運(yùn)行的影響。

所謂的JVM優(yōu)化，其實(shí)指的就是這個(gè)。后續(xù)我們會(huì)結(jié)合大量的案例展開

相信大家一旦堅(jiān)持3個(gè)多月學(xué)習(xí)完這個(gè)專欄，一定會(huì)從此脫胎換骨，對(duì)JVM的運(yùn)行原理，垃圾回收機(jī)制，然后各種生產(chǎn)故障的監(jiān)控、排查、定位、分析和解決，都有一個(gè)本質(zhì)的能力提升，在公司里絕對(duì)可以搞定自己負(fù)責(zé)的生產(chǎn)系統(tǒng)的JVM故障。

7、昨日思考題

昨天給大家分析了一個(gè)經(jīng)典的案例，是一個(gè)非常經(jīng)典的真實(shí)生產(chǎn)案例和優(yōu)化實(shí)踐經(jīng)驗(yàn)

建議大家不要光看，自己把今天的案例，從背景到分析到解決，一步一步自己畫圖來推演一遍，徹底吃透這個(gè)案例。

這對(duì)大家以后分析更多的JVM案例和優(yōu)化，有非常好的作用。

8、今日思考題

給大家一個(gè)小小思考題：到底是單線程進(jìn)行垃圾回收好呢？還是多線程進(jìn)行垃圾回收好呢？在不同的場(chǎng)景下有各自的優(yōu)缺點(diǎn)嗎？

End

版權(quán)：公眾號(hào)儒猿技術(shù)窩

未經(jīng)許可不得傳播，如有侵權(quán)將追究法律責(zé)任