在學(xué)習(xí) Java 堆內(nèi)存的時(shí)候，有了解過(guò) Java 有個(gè)垃圾回收機(jī)制，會(huì)不定時(shí)回收堆內(nèi)存里面的垃圾。本篇文章將為您簡(jiǎn)要概述 Java 在虛擬機(jī)中的垃圾收集器，以及對(duì)象生存法則，以下是詳細(xì)內(nèi)容。
Java與C++之間有一堵由內(nèi)存分配和垃圾收集技術(shù)所圍成的高墻，墻外面的人想進(jìn)去，墻里面的人卻想出來(lái)。
一、概述
Java堆和方法區(qū)這兩個(gè)區(qū)域有著很顯著的不確定性：
1、一個(gè)接口的多個(gè)實(shí)現(xiàn)類需要的內(nèi)存可能會(huì)不一樣，一個(gè)方法所執(zhí)行的不同條件分支所需要的內(nèi)存也可能不一樣
2、只有處于運(yùn)行期間，我們才能知道程序究竟會(huì)創(chuàng)建哪些對(duì)象，創(chuàng)建多少個(gè)對(duì)象，這部分內(nèi)存的分配和回收是動(dòng)態(tài)的
垃圾收集器所關(guān)注的正是這部分的內(nèi)存該如何管理
二、對(duì)象已死？
1、引用計(jì)數(shù)法
在對(duì)象中添加一個(gè)引用計(jì)數(shù)器，每當(dāng)有一個(gè)地方引用它時(shí)，計(jì)數(shù)器就加一；當(dāng)引用失效時(shí)，計(jì)數(shù)器就減一；任何時(shí)刻計(jì)數(shù)器為零的對(duì)象是不可能再被使用的。
引用計(jì)數(shù)器雖然占用了一些額外的內(nèi)存空間來(lái)進(jìn)行計(jì)數(shù)，原理簡(jiǎn)單，判定效率很高；
為什么主流Java虛擬機(jī)沒(méi)有使用引用計(jì)數(shù)器來(lái)管理內(nèi)存呢？
引用計(jì)數(shù)法看似簡(jiǎn)單的算法有很多例外情況要考慮，必須配合大量額外處理才能保證正確的工作，比如單純的引用計(jì)數(shù)很難解決對(duì)象之間互相循環(huán)引用的問(wèn)題。
引用計(jì)數(shù)器的缺陷
/**
* @Author: yky
* @CreateTime: 2020-12-13
* @Description: 引用計(jì)數(shù)器的缺陷
*/
public class ReferenceCountingGC {
public Object instance = null;
private static final int _1MB = 1024 * 1024;
/**
* 這個(gè)成員變量唯一作用是占內(nèi)存
*/
private byte[] bigSize = new byte[2 * _1MB];
public static void testGC(){
ReferenceCountingGC objA = new ReferenceCountingGC();
ReferenceCountingGC objB = new ReferenceCountingGC();
objA.instance = objB;
objB.instance = objA;
//發(fā)生GC，objA、objB能否被回收
System.gc();
}
}運(yùn)行代碼收查看日志信息發(fā)現(xiàn)，這兩個(gè)對(duì)象均被回收虛擬機(jī)并沒(méi)有因?yàn)檫@兩個(gè)相互引用就放棄回收他們---->Java虛擬機(jī)并不是通過(guò)計(jì)數(shù)算法來(lái)判斷對(duì)象是否存活的；
2、可達(dá)性分析算法
該算法的核心思想：通過(guò)一系列稱為“GC Roots”的根對(duì)象作為起始節(jié)點(diǎn)集，從這些結(jié)點(diǎn)開(kāi)始，根據(jù)引用關(guān)系向下搜索，搜索過(guò)程所走過(guò)的路徑稱為“引用鏈”，如果某個(gè)對(duì)象到GC Roots間沒(méi)有任何引用鏈相連（圖論話來(lái)說(shuō)從GC Roots到這個(gè)對(duì)象不可達(dá)時(shí)，則證明此對(duì)象是不可能再被使用的）
對(duì)象obj5、obj6、obj7雖然有關(guān)聯(lián)，但是他們到GC roots不可達(dá)因此他們會(huì)被判定為可回收對(duì)象
在 Java 語(yǔ)言中，可作為 GC Roots 的對(duì)象包括以下幾種：
- 虛擬機(jī)棧（棧中的本地變量表）中的引用對(duì)象，如各線程被調(diào)用的方法堆棧中使用到的參數(shù)、局部變量、臨時(shí)變量等；
- 方法區(qū)中的類靜態(tài)屬性引用的對(duì)象，如Java類的引用類型靜態(tài)變量；
- 方法區(qū)中的常量引用的對(duì)象，如字符串常量里的引用；
- 本地方法?？侸NI（Navicat方法）引用的對(duì)象；
- Java虛擬機(jī)內(nèi)部的引用
- 所有被同步鎖（synchronized關(guān)鍵字）持有的對(duì)象
- 反應(yīng)Java虛擬機(jī)內(nèi)部情況的JMXBean、JVMTI中注冊(cè)的回調(diào)、本地代碼緩存等；
- 根據(jù)用戶所選的垃圾收集器以及當(dāng)前回收的內(nèi)存區(qū)域不同，還可以有其他對(duì)象“臨時(shí)性”地加入；
無(wú)論通過(guò)哪種算法判斷對(duì)象是否存活都和“引用”離不開(kāi)關(guān)系。
1）強(qiáng)引用
是指在程序代碼之間普遍存在的引用賦值，Object obj = new Object();這種引用關(guān)系。
無(wú)論什么情況下，只要強(qiáng)引用關(guān)系還在，垃圾收集器就不會(huì)回收掉被引用的對(duì)象；
2）軟引用
用來(lái)描述一些還有用，但非必須的對(duì)象。只要軟引用關(guān)聯(lián)著的對(duì)象，在系統(tǒng)將要發(fā)生內(nèi)存溢出前，會(huì)把這些對(duì)象列進(jìn)回收范圍之中進(jìn)行第二次回收；如果這次的回收還沒(méi)有足夠的空間，才會(huì)拋出內(nèi)存溢出的異常；
JDK1.2后提供SoftReference類實(shí)現(xiàn)軟引用：
Soft reference objects, which are cleared at the discretion of the garbage
collector in response to memory demand. Soft references are most often used
to implement memory-sensitive caches.
3）弱引用
弱引用也被用來(lái)描那些非必須對(duì)象，強(qiáng)度比軟引用更弱一些，被弱引用關(guān)聯(lián)的對(duì)象只能生存到下一次垃圾收集發(fā)生為止，當(dāng)垃圾收集器開(kāi)始工作，無(wú)論當(dāng)前內(nèi)存是足夠，都會(huì)回收掉只被弱引用關(guān)聯(lián)的對(duì)象；
JDK1.2后WeakReference類用來(lái)實(shí)現(xiàn)弱引用：
Weak reference objects, which do not prevent their referents from being
made finalizable, finalized, and then reclaimed. Weak references are most
often used to implement canonicalizing mappings.
4）虛引用
也叫“幽靈引用”、“幻影引用”，最弱的一種引用關(guān)系
- 一個(gè)對(duì)象是否有虛引用的存在，完全不會(huì)對(duì)其生存時(shí)間構(gòu)成影響，也無(wú)法通過(guò)虛引用獲得一個(gè)對(duì)象的實(shí)例；
- 為一個(gè)對(duì)象設(shè)置虛引用的唯一目的是為了能在這個(gè)對(duì)象被收集器回收時(shí)收到一個(gè)系統(tǒng)通知；
PhantomReference類來(lái)實(shí)現(xiàn)虛引用：
Phantom reference objects, which are enqueued after the collector determines that their referents may otherwise be reclaimed. Phantom references are most often used to schedule post-mortem cleanup actions.
應(yīng)用需要讀取大量本地圖片：
如果每次讀取圖片都從硬盤(pán)讀取，則會(huì)嚴(yán)重影響性能；解決方案：【軟引用或者弱引用】
Map<String,SoftReference<BitMap>> imp = new HashMap<String,SoftReference<BitMap>>4、生存還是死亡？
在進(jìn)行過(guò)可達(dá)性分析后的對(duì)象也不一定是非死不可的，該對(duì)象進(jìn)行可達(dá)性分析后，發(fā)現(xiàn)沒(méi)有與GC Roots相連接的引用鏈
- 這個(gè)對(duì)象就會(huì)第一次被標(biāo)記起來(lái)；對(duì)對(duì)象是否必要執(zhí)行finalize()方法進(jìn)行判斷（已經(jīng)被虛擬機(jī)調(diào)用過(guò)finalize()方法或者沒(méi)有覆蓋finalize()方法都認(rèn)為是沒(méi)有必要執(zhí)行該finalize()方法）
- F-Queue隊(duì)列中存放該對(duì)象，優(yōu)先級(jí)較低的Finalizer線程會(huì)去執(zhí)行它；Gc 會(huì)對(duì)這個(gè)隊(duì)列里面的對(duì)象再進(jìn)行一次標(biāo)記，如果在finalize方法中，對(duì)象沒(méi)有自己自救的話，它就會(huì)被標(biāo)記回收
- finalize方法自救自己的辦法是：重新與引用鏈上面的任何一個(gè)對(duì)象建立連接；如把自己this賦值給某個(gè)類或?qū)ο蟮某蓡T變量
結(jié)果如下：
finalize method executed !
yes,I am still alive :)
no, i am dead :(
- 并不鼓勵(lì)使用這種辦法來(lái)拯救對(duì)象，它的運(yùn)行代價(jià)高昂，不確定性大，無(wú)法保證順序；
- finalize方法能做的所有工作，try-finally也可以做的更好，更及時(shí)，所以希望忘記這個(gè)方法的存在；
5、回收方法區(qū)
很多人認(rèn)為方法區(qū)（或者HotSpot虛擬機(jī)中的元空間或永久代）是沒(méi)有垃圾收集行為的，《Java虛擬機(jī)規(guī)范》中確實(shí)說(shuō)過(guò)可以不要求虛擬機(jī)在方法區(qū)實(shí)現(xiàn)垃圾收集，而且在方法區(qū)進(jìn)行垃圾收集的“性價(jià)比”一般比較低：在堆中，尤其是在新生代中，常規(guī)應(yīng)用進(jìn)行一次垃圾收集一般可以回收70%～95%的空間，而永久代的垃圾收集效率遠(yuǎn)低于此。
方法區(qū)的垃圾收集主要回收兩部分：廢棄的常量和不再使用的類型；
- 回收廢棄常量與回收J(rèn)ava堆中的對(duì)象非常類似。以常量池中字面量的回收為例：
假如一個(gè)字符串“Java”已經(jīng)進(jìn)入了常量池中，但是當(dāng)前系統(tǒng)沒(méi)有任何一個(gè)字符串對(duì)象的值是“Java”，換句話說(shuō)是沒(méi)有任何String對(duì)象引用常量池中的“Java”常量，也沒(méi)有其他地方引用了這個(gè)字面量，如果在這時(shí)候發(fā)生內(nèi)存回收，而且必要的話，這個(gè)“Java”常量就會(huì)被系統(tǒng)清理出常量池。
- 常量池中的其他類（接口）、方法、字段的符號(hào)引用也與此類似。
判定一個(gè)常量是否是“廢棄常量”比較簡(jiǎn)單。而要判定一個(gè)類是否是“無(wú)用的類”的條件則相對(duì)苛刻許多。類需要同時(shí)滿足下面3個(gè)條件才能算是“無(wú)用的類”：
- 該類所有的實(shí)例都已經(jīng)被回收，也就是Java堆中不存在該類的任何實(shí)例。
- 加載該類的ClassLoader已經(jīng)被回收。
- 該類對(duì)應(yīng)的java.lang.Class對(duì)象沒(méi)有在任何地方被引用，無(wú)法在任何地方通過(guò)反射訪問(wèn)該類的方法。
虛擬機(jī)可以對(duì)滿足上述3個(gè)條件的無(wú)用類進(jìn)行回收，這里說(shuō)的僅僅是“被允許”，而不是和對(duì)象一樣，不使用了就必然會(huì)回收。在大量使用反射、動(dòng)態(tài)代理、CGLib等bytecode框架的場(chǎng)景，以及動(dòng)態(tài)生成JSP和OSGi這類頻繁自定義ClassLoader的場(chǎng)景都需要虛擬機(jī)具備類卸載的功能，以保證不會(huì)被方法區(qū)造成過(guò)大的內(nèi)存壓力。
以上就是關(guān)于簡(jiǎn)述 Java 虛擬機(jī)中的垃圾收集器，以及對(duì)象生存法則的全部?jī)?nèi)容。如果想要了解更多相關(guān)Java虛擬機(jī)的內(nèi)容請(qǐng)搜索W3Cschool以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持我們！
