淺談對java-GC的理解

眸色發表於2019-06-21

前段時間,一個線上專案忽然很卡,通過監控,發現記憶體很高,果不其然在幾個小時後,OOM。雖說有人很快處理好了。但我還是想站在我的角度,對這件事發表一下自己的觀點。

記憶體溢位,多發生在專案上線後,而且在系統開發階段和單元測試階段幾乎不被發現。這其實是和開發者習慣有關。譬如一些空的引用,就會佔著茅廁不拉屎等等

而要搞明白這個過程,不得不提一下java是如何管理記憶體的。主要涉及到物件的分配和釋放。

在java中,記憶體分配是由程式完成的,而釋放,是由垃圾回收機制自動完成的。

記憶體分配扯到各種new 物件,此處不多寫,主要談談GC過程 。

我用idea裝了Java VisualVM外掛 ,用自己的測試工程啟動後,可以看到這樣一個介面,說明外掛安裝成功,已經成功監視到我的工程

 

 

我不是來講這個外掛如何使用的,我本人也在學習階段,所以直接看本文重點

在我第一次看到這個圖的時候,恍然大明白,原來之前看的GC分割槽,就是這麼回事。但是過程是什麼樣的呢,就這個圖我做下說明(其實是我自己在網上整理了一下,然後講出來,加上自己的一些理解)

希望能對和我一樣曾經徘徊在GC門口的人一點幫助。

圖示,在整個GC過程中,大概有3個歷程。

Eden Space:新生

Old Gen:老年

Metaspace:持久代。持久好啊^_^

新生代和老年代之間,有2個Survivor區,圖裡面為S0,S1.這兩個作用是什麼,彆著急,我們一步步來,要有前戲。

首先當物件被建立的時候,new一個女朋友,是每個程式猿的夢想。但是在這裡,女朋友需要從相親物件不斷的跨越山河大海,才能成為女朋友,持續在一起。我開闢一個主任務(系統棧):我要相親,媒婆給我找一些相親物件來。於是乎,很多相親物件被new了出來,要大面撒網嘛。所以很多各種模樣的相親物件就排著隊進到Eden區,高的,矮的,胖的,瘦的,瓜子臉,O型腿,什麼樣的都有。

護衛何在,在。去把這些矮的,胖的,長相怪異的,都給我趕出門外,還有媒婆你下次挑的時候,長點眼睛。Eden:S區預設大小是8:1

於是一些看了一眼,甚至看都沒看一眼的垃圾物件被清了出去。剩下的,都還看的過去。全部給我去S0房間待著啊,進行第一輪考核。此刻S1是空的。

此時Eden房間已經閒置了,但是在整個專案執行期間,只要有人進行任何操作,都會不斷的有新物件進來到記憶體中。

所以Eden很快又滿了,在經歷了S0房間的篩選後,一些人由於思想問題,也要被趕出去,同時呢Eden這一批也有留下的,於是,S0剩下的和Eden剩下的,全都給我去S1待著去,那裡會繼續審查。為什麼這批S0的已經審查過了,還有繼續審查呢,那是因為現在網路這麼發達,太多東西都可以作假,一次可能瞞混過關,需要進行多次選擇。注意此刻S0是空的。(複製、引用計數法。Scavenge GC)

當這批S1的檢查完後,去掉一些家底不乾淨的,還留了一部分,而新的Eden依舊有一批篩選後的,這兩部分人,又全部進去S0再次給我檢查,身上有胎記的,毛太長的,有狐臭的等等都給我趕出去。此刻S1是空的。(複製、引用計數法。Scavenge GC)

當如此迴圈多次後,篩選來篩選後,發現某次S0或者S1擠滿了,不能再和新的Eden區剩下的人去擠進一個S房間了,系統就認為這批相親物件,質量很高(物件的引用一直存在),全部移步到Old Gen。此刻S0和S1空了,繼續和Eden進行新的迴圈。

此刻我來到Old Gen,開始逐個進行洗腦,這是個漫長的過程:因為要成為我的女朋友,要心甘情願的洗衣做飯暖床等等。過了很長一段時間的試戀愛後,Old Gen房間太滿了,而且還有很多不同意以上條件的美女們,我不能白養著啊,不合適就走吧,我不是慈善家。都走後門出去啊,別太惹人注目。

此處對應GC中,Eden和S區調整不能騰出足夠的空間時,要進行的FULL GC,此時JVM GC停止所有在heap中 執行的執行緒並執行清除動作。(標記壓縮-清除)

而經歷了多次FULL GC還留下的,我要把你們納入後宮,都去Metaspace吧。我在那裡等著你們。那裡有我喜歡的生活用品,交通工具等。幾乎不會改變,只會把一些舊的更換成新的。只要我有肉吃,就少不了你們的湯喝。

有幾個點需要強調一下,如果Eden中有極品美女,是可以直接進入到Old Gen的。對應一些大的物件,直接進老年代。

以上只是一些總結,隨著學習的深入,我會繼續補充。有寫錯的,歡迎在評論區糾正。哈哈,第一次寫這麼長。自我鼓勵一下

 

相關文章