Java jvm垃圾回收詳解

Posted on 2021-10-26 by WalkonNet

常見面試題

如何判斷對象是否死亡
簡單介紹一下強引用、軟引用、弱引用、虛引用
如何判斷常量是一個廢棄常量
如何判斷類是一個無用類
垃圾收集有哪些算法、各自的特點？
常見的垃圾回收器有哪些？
介紹一下CMS，G1收集器？
minor gc和full gc有什麼不同呢？

1.JVM內存回收和分配

1.1主要的區域？

在伊甸區先產生對象
然後發生一次gc之後去到幸存區幸存區
如果年齡大於閾值那麼就會升級到老年代

閾值的計算

如果某個年齡段的大小大於幸存區的一半,那麼就取閾值或者是這個年齡最小的那個作為新的閾值升級到老年代

gc的時候是幸存區的from和伊甸區的存活對象復制到to,然後再清理其它的對象,接著from和to就會交換指針

gc測試

場景就是先給eden分配足量的空間，然後再申請大量空間，問題就是幸存區的空間不夠用

那麼這個時候就會觸發分配擔保機制，把多餘的對象分配到老年代，而不會觸發full gc。仍然還是monor gc

public class GCTest {
    public static void main(String[] args) {
        byte[] allocation1, allocation2;
        allocation1 = new byte[50900*1024];
        allocation2 = new byte[9500*1024];
    }
}

1.2大對象進入老年代

防止在標記復制的時候占用大量的時間，降低gc的效率

1.3長期存活的對象進入老年代

每次gc都會把eden和from的存活對象放到to，每次gc存活年齡就會+1，如果超過閾值那麼就能夠升級到老年代，設置的參數是-XX:MaxTenuringThreshold
下面是計算的方式，每個年齡的人數累加，累加一個就+1，如果對象數量大於幸存區的一半的時候就需要更新閾值（新計算的age和MaxTenuringThreshold）
通常晉升閾值是15，但是CMS是6

uint ageTable::compute_tenuring_threshold(size_t survivor_capacity) {
    //survivor_capacity是survivor空間的大小
    size_t desired_survivor_size = (size_t)((((double)survivor_capacity)*TargetSurvivorRatio)/100);
    size_t total = 0;
    uint age = 1;
    while (age < table_size) {
        //sizes數組是每個年齡段對象大小
        total += sizes[age];
        if (total > desired_survivor_size) {
            break;
        }
        age++;
    }
    uint result = age < MaxTenuringThreshold ? age : MaxTenuringThreshold;
    ...
}

1.4主要進行gc的區域

gc的類型

Partial Gc

Young Gc：收集新生代的

Old Gc:隻收集老年代的

Mixed Gc：新生代和部分老年代

Full Gc：新生代，老年代都會收集

Young Gc

每次都是收集新生代的，並且晉升那些存活久的

Full Gc

如果發現幸存區要晉升的對象內存空間比老年代內存空間更大那麼就進行full Gc。有的虛擬機會先進行young gc來清理掉一些，減少full gc的時間消耗

1.5空間分配擔保？

jdk1.6之前需要判斷老年代剩餘的空間是不是完全大於新生代的空間，如果是那麼才能進行minorgc保證不會出現問題。如果是不行就會去檢查-XX：handlePromotionFailure也就是晉升的對象平均大小是不是小於老年代剩餘空間，如果是那麼就直接minor gc否則就full gc
jdk1.6之後直接檢查新生代晉升平均大小如果小於老年代那麼就會直接晉升

2.對象已經死亡？

2.1引用計數法

其實就是每次被引用那麼計數+1，如果計數不是0那麼就不會被回收
但是不使用的原因就是循環引用依賴，如果兩個對象互相引用就會導致計數永遠不會為0

2.2可達性分析

Gc roots作為起點一直往下面的一條引用鏈

gc Roots的對象

虛擬機棧引用的對象（棧的本地局部變量表）
本地方法棧引用的對象
方法區常量引用的對象（常量池引用的對象）
方法區靜態屬性引用的對象
被同步鎖持有的對象
java虛擬機內部引用，比如Integer這些基本類型的

2.3再談引用

強引用：垃圾回收器不會對他進行回收
軟引用：內存空間不足會回收
弱引用：gc就回收
虛引用：隨時會被回收而且需要引用隊列

虛引用、軟引用、弱引用的區別？

虛引用的對象在gc之前會被送到引用隊列，並且程序在對象回收之前做相應的活動（臨死之前的處理）
軟引用是用的最多的，可以提高gc的效率，維護系統安全，防止內存溢出

2.4不可達對象不一定回收

在回收之前會對對象進行一次標記，看是否會執行finalize方法。如果沒有那麼這些對象將會先被回收
如果有那麼進行第二次標記，讓對象執行finalize之後再進行回收

2.5如何判斷一個常量是廢棄常量？

如果常量池對象沒有被任何對象引用就會被回收
jdk1.7之前運行時常量池包含字符串常量池，需要進行復制來返回新的引用（堆有一個，常量池有一個）
jdk1.7的時候字符串池已經不在運行時常量池，如果調用intern就會把當前對象放入常量池並且返回引用（隻有常量池有一個）。如果本來就存在就會返回對象實例的地址。
jdk1.8之後運行時常量池已經轉移到瞭元空間

2.6如果判斷一個類沒有用？

類的實例都回收瞭
類的類加載器回收瞭
類信息沒有被引用
大量的反射和動態代理生成類信息會對方法區產生很大的壓力

3.垃圾回收算法

hotspot為什麼要區分老年代和新生代？

原因就是不同的存活對象需要不同的垃圾回收算法

如果新生代用的是標記整理，問題就是每次清除大量的對象，移動時間很長，整理消耗很大。但是標記復制就很快，因為存活對象少
但是老年代如果使用標記整理就很好，因為存活多移動少，復制就相反
不能夠統一設計為弱分代假說和強分代假說

跨代收集假說？

如果老年代和新生代互相引用，新生代的年齡就會被拉長。但是為瞭知道新生代什麼時候被gc，這個時候可以給新生代加上一個記憶集（把老年代劃分為很多個格子，代表誰引用瞭我），避免掃描整個老年代

4.垃圾回收器

4.1Serial收集器

單線程收集器，每次都要阻塞其它線程（STW），一個垃圾線程單獨回收
新生代是標記復制，老年代是標記整理
它簡單高效，沒有和其它線程交換不會產生並發問題
但是STW會導致響應很慢

4.2ParNew收集器

Serial的多線程版本，但是還是會STW
新生代是標記復制，老年代是標記整理

4.3Parallel Scavenge收集器

新生代是標記復制，老年代是標記整理
和ParNew不同的地方就是它完全關註cpu的利用率，也就是處理任務的吞吐量，而不會管STW到底停多久

4.4SerialOld

Serial的老年代版本，1.5以前和Parallel Scavenge一起使用，還有別的用途就是CMS的後備方案

4.5Parallel Old收集器

Parallel Scavenge收集器的老年代也是註重吞吐量

4.6CMS收集器

註重最小響應時間
垃圾收集器和用戶線程同時工作
初始標記記錄gc root直接相連的對象
並發標記遍歷整個鏈，但是可以和用戶線程並發運行
重新標記修正那些更新的對象的引用鏈，比並發標記短
並發清除

問題？

內存碎片多對cpu資源敏感

4.7G1收集器

同時滿足響應快處理多的問題

特點

並行和並發，使用多個cpu執行gc線程來縮短stw,而且還能與java線程並發執行
分代收集
空間整合：大部分時候使用標記復制
可預測停頓:響應時間快，可以設置stw時間
分區之間的跨代引用，young這裡使用瞭rset（非收集區指向收集區）記錄，老年代那個區域指向瞭我，老年代使用瞭卡表劃分瞭很多個區域，那麼minor gc的時候就不需要遍歷整個其它所有區域去看看當前的區域的對象到底有沒有被引用。

補充字符串池的本質

第一個問題是String a=”a”的時候做瞭什麼？

先去找常量池是否存在a如果存在那麼就直接返回常量池的引用地址返回，如果不存在那麼就創建一個在常量池然後再返回引用地址

第二個問題new String(“a”)發生瞭什麼？

先看看常量池是否存在a，如果不存在創建一個在常量池，而且在堆單獨創建一個a對象返回引用（而不是返回常量池的），相當於就是創建瞭兩次。
如果第二次創建發現已經存在就直接在堆中創建對象。

第三個問題intern的原理？

看看常量池有沒有這個字符串，沒有就創建並返回常量池對象的地址引用
如果有那麼直接返回常量池對象的地址引用

String s1=new String(“a”)

String s2=s1.intern();

很明顯s1不等於s2如果上面的問題都清晰知道。s1引用的是堆，而s2引用的是常量池的

第四個問題

String s3=new String(“1”)+new String(“1”);

String s5=s3.intern();

String s4=“11”

那麼地方他們相等嗎？當然是相等的，s3會把1存入常量池，但是不會吧11存入常量池因為，還沒編譯出來。調用瞭intern之後才會把對象存入常量池，而這個時候存入的對象就是s3指向的那個。所以s4指向的也是s3的。如果是s0=”11″的話那就不一樣瞭，s3.intern隻會返回常量池的對象引用地址，而不是s3的，因為s3是不能重復intern 11進去的。jdk1.6的話那麼無論怎麼樣都是錯的，intern是復制一份，而不是把對象存入常量池（因為字符串常量池在方法區，而jdk1.7它在堆所以可以很好的保存s3的引用）

下面的代碼正確分析應該是三個true，但是在test裡面就會先緩存瞭11導致false， true，false的問題。

@Test
public void test4(){
    String s3 = new String("1") + new String("1");
    String s5 = s3.intern();
    String s4 = "11";
    System.out.println(s5 == s3);
    System.out.println(s5 == s4);
    System.out.println(s3 == s4);
    System.out.println("======================");
    String s6 = new String("go") +new String("od");
    String s7 = s6.intern();
    String s8 = "good";
    System.out.println(s6 == s7);
    System.out.println(s7 == s8);
    System.out.println(s6 == s8);
}

finalize的原理

其實就是對象重寫瞭finalize，那麼第一次gc的時候如果發現有finalize，就會把對象帶到F-Queue上面等待，執行finalize方法進行自救，下面就是一個自救過程，new瞭一個GCTest對象，這個時候test不引用瞭，那麼正常來說這個GCTest就會被回收，但是它觸發瞭finalize的方法，最後再次在finalize中使用test引用它所以對象沒有被消除
但是finalize是一個守護線程，防止有的finalize是個循環等待方法阻塞整個隊列，影響回收效率
最後一次標記就是在F-queue裡面標記這個對象（如果沒有引用）然後釋放
finalize實際上是放到瞭Finalizer線程上實現。然後然引用隊列指向這個雙向鏈表，一旦遇到gc，那麼就會調用ReferenceHandler來處理這些節點的finalize調用，調用之後斷開節點，節點就會被回收瞭
finalize上鎖導致執行很慢

public class GCTest {
    static GCTest test;
    public void isAlive(){
        System.out.println("我還活著");
    }
    @Override
    protected void finalize() throws Throwable {
        System.out.println("我要死瞭");
        test=this;
    }
    public static void main(String[] args) throws InterruptedException {
       test = new GCTest();
        test=null;
        System.gc();
        Thread.sleep(500);
        if(test!=null){
            test.isAlive();
        }else{
            System.out.println("死瞭");
        }
        test=null;
        System.gc();
        if(test!=null){
            test.isAlive();
        }else{
            System.out.println("死瞭");
        }
    }
}

總結

本篇文章就到這裡瞭，希望能夠給你帶來幫助，也希望您能夠多多關註WalkonNet的更多內容！

目錄