JVM的內存回收及常見算法小結
什么樣的對象應該被回收?
某個對象不再被棧直接或間接地引用,此時就應該被回收了。
o被指向null的時候,new Object()創(chuàng)建的對象就不在被棧引用了,可以被回收。
p1和personList均不再指向第一個Person對象的時候,第一個Person對象、list對象可以被回收。
經歷前面的幾個階段,內存引用是這樣的情況。
p1 = null后,p1曾經指向的對象雖然不再被棧直接引用,但是仍然間接通過persons引用。
此時p1指向的對象和list指向的對象都可以被回收了。
怎么樣確定哪些需要回收?
對我們仍然需要使用的對象進行標記,回收沒有標記的對象。
以此為例,如何進行標記的呢?
垃圾回收進行之前,所有對象的標記位是0
如果僅僅標記棧直接引用的對象,p1就會被回收,但是p1間接被list引用,因此也被標記為1
標記算法
-Stop the World(GC Root可達性算法)
在進行上面的標記過程的時候,如果有新的對象被創(chuàng)建,而剛好被標記過程錯過的時候,就可能錯誤地把有用的對象給回收掉,因為標記位是0.因此,Stop the World正如其名,將應用的核心線程停掉,開始專心標記。
-引用計數(shù)法
對對象進行引用數(shù)量的標記,沒有引用的對象標記是0,有引用的對象標記是引用數(shù)量。清除標記為0的對象即可。但是引用計數(shù)法有個問題,無法解決循環(huán)引用的問題,導致內存泄露。
這里聲明一個對象,內部包含一個跟自己一個類型的成員變量。
在執(zhí)行第五行之前,兩個對象的引用計數(shù)均為2,各自引用,加上n1和n2.
執(zhí)行完第五六行以后,按道理,棧上已經不在引用這兩個對象,可以被回收了,但是因為n1和n2相互引用,導致引用計數(shù)為1,無法正?;厥铡?/p>
清除算法
一般清除算法:直接將未標記的對象清理掉
經過清理,未標記的對象被回收。
但是存在內存碎片化的問題,只能從間隙處繼續(xù)分配內存,
存在內存不連續(xù)的問題,內存空間浪費嚴重,容易oom
清除-整理算法:先清除沒有標記的對象,然后將剩余的存活對象進行整理,讓內存空間更加連續(xù)。
就是代價比較高,幾乎需要移動所有的對象。
復制-清除算法:將活躍的對象復制到另一個內存區(qū)域,然后清除當前區(qū)域的所有對象!
完成復制后,清除原有的區(qū)域
這種算法的弊端就是需要更多的內存空間。
常見的GC類型
GC類別 | 新生代垃圾回收 | 老年代垃圾回收 | 特點 |
Serial GC | 標記-復制&清除 | 標記-清除&整理 | Stop the World
使用單個線程處理 適合小應用 |
Parallel GC | Java 8默認垃圾回收器
Stop the World 使用多個線程處理 | ||
CMS GC | 標記-復制&清除
(Stop the World) | 接近并行的標記-清除
初始標記->并發(fā)標記 -> 并發(fā)預清理->可中斷預清理->重新標記->并發(fā)清除->并發(fā)重置 | |
G1 GC | 更細粒度的邏輯分區(qū),更小的停頓時間 采用復制&整理-清理的方式,優(yōu)先回收垃圾最多的區(qū)域 對字符串的合并整理,多個相同的字符串合并到一起,移除冗余字符串對象 | -XX:UseStringDeduplication | |
Z GC | 不在維護映射,而是對象上保持一個標記來表示活躍對象 僅支持64位系統(tǒng) 采用重定位解決內存碎片化問題 | Java 15 |
到此這篇關于JVM的內存回收及常見算法的文章就介紹到這了,更多相關JVM的內存回收內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!
相關文章
java線程之Happens before規(guī)則案例詳解
這篇文章主要為大家介紹了java線程之Happens-before規(guī)則,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪<BR>2022-08-08SpringMVC中的@RequestMapping注解解析
這篇文章主要介紹了SpringMVC中的@RequestMapping注解解析,SpringMVC使用@RequestMapping注解為控制器指定可以處理哪些?URL?請求,在控制器的類定義及方法定義處都可標注@RequestMapping,需要的朋友可以參考下2023-12-12

Yml轉properties文件工具類YmlUtils的詳細過程(不用引任何插件和依賴)

controller接口跳轉到另一個controller接口的實現(xiàn)