JVM垃圾回收算法的概念介紹

本篇內(nèi)容主要講解“JVM垃圾回收算法的概念介紹”，感興趣的朋友不妨來看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“JVM垃圾回收算法的概念介紹”吧!

前言

在JVM內(nèi)存模型中會(huì)將堆內(nèi)存劃分新生代、老年代兩個(gè)區(qū)域，兩塊區(qū)域的主要區(qū)別在于新生代存放存活時(shí)間較短的對(duì)象，老年代存放存活時(shí)間較久的對(duì)象，除了存活時(shí)間不同外，還有垃圾回收策略的不同，在JVM中中有以下回收算法：

標(biāo)記清除  標(biāo)記整理  復(fù)制算法  分代收集算法

有了垃圾回收算法，那JVM是如果確定對(duì)象是垃圾對(duì)象的呢？判斷對(duì)象是否存活JVM也會(huì)有幾套自己判斷算法了：

引用記數(shù)  可達(dá)性分析

有了垃圾回收和判斷對(duì)象存在這兩個(gè)概念后，再來逐步分析它們。

JVM是如何判斷對(duì)象是否存活的？

要是讓開發(fā)人員來判斷一個(gè)對(duì)象是否有用是很簡(jiǎn)單的，簡(jiǎn)單的說就是：對(duì)象沒有任何引用就認(rèn)為該對(duì)象可以被回收了。假設(shè)有如下程序代碼：

public class App { public static void main(){  checkFile("/"); } public static boolean checkFile(String path ){  File file = new File(path);  return file.exists(); }}

程序執(zhí)行起來在調(diào)用checkFile的時(shí)候JVM圖大概像這樣：

到checkFile方法執(zhí)行完成之后，它里面的局部變量file就會(huì)隨著棧幀一起被清理，這個(gè)時(shí)候還存活在JVM堆中的File對(duì)象也是無用的了：

要是人為來判斷非常清晰的就發(fā)現(xiàn)File對(duì)象已經(jīng)無用了，那換成JVM它又是如何來判斷對(duì)象是否能存活的呢？

引用記數(shù)

引用記數(shù)算法原理比較簡(jiǎn)單，想象下有個(gè)對(duì)象它有一個(gè)count屬性，每次引用該對(duì)象都會(huì)使count加1，假設(shè)JVM在判斷該對(duì)象是否存活的時(shí)候去檢查這個(gè)count屬性，發(fā)現(xiàn)這個(gè)屬性不為0說明還有其他對(duì)象在引用該對(duì)象。

等到checkFile方法執(zhí)行完之后count就會(huì)減1變成0：

這樣一來JVM就很容易判斷一個(gè)對(duì)象是否存活了。

但是引用記數(shù)有一個(gè)明顯的缺點(diǎn)，就是無法解決循環(huán)引用的問題比如：A --> B --> A 這樣的對(duì)象關(guān)系它是沒有辦法來判斷對(duì)象是否該不該回收的。

GC Root（可達(dá)性分析）

為什么會(huì)被稱為可達(dá)性分析算法呢？可以這樣理解如果通過GC Root能到達(dá)一個(gè)對(duì)象那么這個(gè)對(duì)象就是存活的。那什么樣的對(duì)象才是GC Root呢？

在Java語言中，可作為GC Roots的對(duì)象包括下面幾種：

1. 虛擬機(jī)棧中引用的對(duì)象（棧幀中的本地變量表）；  方法區(qū)中類靜態(tài)屬性引用的對(duì)象；  方法區(qū)中常量引用的對(duì)象；  本地方法棧中JNI（Native方法）引用的對(duì)象。

還是用上面的例子，在checkFile方法執(zhí)行時(shí)，因?yàn)闂兞縡ile可做為GC Root所以在執(zhí)行期間JVM是絕對(duì)不會(huì)回收掉這個(gè)File對(duì)象：

但是等到checkFile執(zhí)行完成之后，這個(gè)棧幀會(huì)被彈出，其中的變量也會(huì)被釋放，相應(yīng)的沒有GC Root能到達(dá)堆中的File對(duì)象，這個(gè)時(shí)候就可以判斷這個(gè)對(duì)象是一個(gè)無用的對(duì)象了，然后安全回收。

垃圾收回算法

標(biāo)記清除

這種算法分兩分：標(biāo)記、清除兩個(gè)階段，

標(biāo)記階段是從根集合（GC Root)開始掃描，每到達(dá)一個(gè)對(duì)象就會(huì)標(biāo)記該對(duì)象為存活狀態(tài)，清除階段在掃描完成之后將沒有標(biāo)記的對(duì)象給清除掉。

用一張圖說明：

這個(gè)算法有個(gè)缺陷就是會(huì)產(chǎn)生內(nèi)存碎片，如上圖B被清除掉后會(huì)留下一塊內(nèi)存區(qū)域，如果后面需要分配大的對(duì)象就會(huì)導(dǎo)致沒有連續(xù)的內(nèi)存可供使用。

標(biāo)記整理

標(biāo)記整理就沒有內(nèi)存碎片的問題了，也是從根集合（GC Root)開始掃描進(jìn)行標(biāo)記然后清除無用的對(duì)象，清除完成后它會(huì)整理內(nèi)存。

這樣內(nèi)存就是連續(xù)的了，但是產(chǎn)生的另外一個(gè)問題是：每次都得移動(dòng)對(duì)象，因此成本很高。

復(fù)制算法

復(fù)制算法會(huì)將JVM推分成二等分，如果堆設(shè)置的是1g，那使用復(fù)制算法的時(shí)候堆就會(huì)有被劃分為兩塊區(qū)域各512m。給對(duì)象分配內(nèi)存的時(shí)候總是使用其中的一塊來分配，分配滿了以后，GC就會(huì)進(jìn)行標(biāo)記，然后將存活的對(duì)象移動(dòng)到另外一塊空白的區(qū)域，然后清除掉所有沒有存活的對(duì)象，這樣重復(fù)的處理，始終就會(huì)有一塊空白的區(qū)域沒有被合理的利用到。

兩塊區(qū)域交替使用，最大問題就是會(huì)導(dǎo)致空間的浪費(fèi)，現(xiàn)在堆內(nèi)存的使用率只有50%。

分代回收

新生代回收

JVM的堆分為新生代和老年代，兩種類型有不同的特性，根據(jù)它們的特性來選擇不同的回收算法，這種算法會(huì)將新生代劃分為一塊Eden和二個(gè)Survivor區(qū)：

如上面的圖有三塊區(qū)域它們會(huì)按照8:1:1的比例進(jìn)行分配，如1000m的堆Eden是800m,二個(gè)Survivor各占100m，那它們是如何運(yùn)行的呢？

1. 始終會(huì)有一塊Survivor是空著的，內(nèi)存使用率是90%  程序運(yùn)行會(huì)在Eden和其中一塊Survivor 1中分配內(nèi)存  等到執(zhí)行Minor gc，會(huì)將存活下來的對(duì)象移動(dòng)到空著的Survivor 2中  然后在Eden和Survivor 2中繼續(xù)分配內(nèi)存，Survivor 1空著等著下次使用

這樣就能使內(nèi)存使用率達(dá)到90%，也不會(huì)產(chǎn)生內(nèi)存碎片。

老年代回收

老年代對(duì)象即使進(jìn)行了垃圾回收，對(duì)象的存活率也高，所以采用標(biāo)記清除或標(biāo)記整理算法都是不錯(cuò)的選擇，這里就不做闡述。

到此，相信大家對(duì)“JVM垃圾回收算法的概念介紹”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！