什麼是垃圾回收

垃圾回收（Garbage Collection，GC），顧名思義就是釋放垃圾佔用的空間，防止內存泄露。有效的使用可以使用的內存，對內存堆中已經死亡的或者長時間沒有使用的對象進行清除和回收。

與C/C++相比，java語言不需要程序員直接控制內存回收，java程序的內存分配和回收都是由JRE在後臺自動進行，JRE會負責回收那些不再使用的內存，這種機制被稱爲垃圾回收機制(Garbage Collection,GC)。

一、主要負責兩件事情：

1.發現無用的對象；

2.回收被無用對象佔用的內存空間，使之再次被程序使用(一般是在CPU空閒或者內存不足時)。

注：事實上，除了釋放沒用對象佔用的內存空間外，垃圾回收也可以清除內存紀錄碎片（由於創建對象和垃圾回收器釋放丟棄對象所佔的內存空間）

二、特點

1.垃圾回收機制的工作目標是回收無用對象的內存空間，這些內存空間都是jvm堆內存（運行時數據區，用以保存類的實例，即對象）裏的內存空間，不包含其它物力資源，比如數據庫連接、磁盤I/O等；

2.Java語言沒有顯式的提供分配內存和刪除內存的方法，一些開發人員將引用對象設置爲null或者調用System.gc()或者Runtime.getRuntime.gc()來釋放內存(後兩種方法僅是建議，慎重使用)；

3.垃圾回收不可預知，不同的jvm採用不同的垃圾回收機制和算法，有可能定時發生，有可能CPU空閒時發生，也有可能內存耗盡時發生；

下面進入正文，在瞭解什麼是垃圾回收的概念時，我們大致回答這幾個問題：首先，回顧一下jvm中的內存結構；然後，確定那些對象是垃圾？其次，有哪些算法回收這些垃圾？接下來，講講堆和方法區的垃圾回收（核心是堆的回收），最後，jvm提供了哪些垃圾回收器。

jvm中的內存結構

我們的垃圾回收都是基於內存去回收的，因此，先要對內存結構有一個大概的瞭解，下面這一張是java7的內存結構：

從上面我們可以看到，Java內存運行時區域大概分了三部分，

其中PC寄存器、java虛擬機棧、本地方法棧3個區域是所有線程獨有的一塊區域，隨線程而生，隨線程而滅。棧中的棧幀隨着方法的進入和退出而有條不紊地執行着入棧和出棧操作。每一個棧幀中分配多少內存基本上是在類結構確定下來時就已知的，因此這幾個區域的內存分配和回收都具備確定性，在這幾個區域內就不需要過多考慮回收的問題，因爲方法結束或者線程結束，內存自然就跟隨着回收了。

而Java堆和方法區則不一樣，一個接口中的多個實現類需要的內存可能不一樣，一個方法中的多個實現類需要的內存可能不一樣，一個方法中的多個分支需要的內存也可能不一樣，只有在程序處於運行期間時才能知道會創建哪些對象，這部分內存的分配和回收是動態的，垃圾收集關注的是這部分的內存。知道了我們要回收的這部分區域之後，下面就是確定那些對象是垃圾的問題了。

哪些對象是垃圾呢？

既然我們要做垃圾回收，首先我們得搞清楚垃圾的定義是什麼，哪些內存是需要回收的。

引用計數算法

引用計數算法（Reachability Counting）是通過在對象頭中分配一個空間來保存該對象被引用的次數（Reference Count）。如果該對象被其它對象引用，則它的引用計數加1，如果刪除對該對象的引用，那麼它的引用計數就減1，當該對象的引用計數爲0時，那麼該對象就會被回收。

String m = new String("jack");

先創建一個字符串，這時候"jack"有一個引用，就是 m。

然後將 m 設置爲 null，這時候"jack"的引用次數就等於0了，在引用計數算法中，意味着這塊內容就需要被回收了。

m = null;

引用計數算法是將垃圾回收分攤到整個應用程序的運行當中了，而不是在進行垃圾收集時，要掛起整個應用的運行，直到對堆中所有對象的處理都結束。因此，採用引用計數的垃圾收集不屬於嚴格意義上的"Stop-The-World"的垃圾收集機制。

看似很美好，但我們知道JVM的垃圾回收就是"Stop-The-World"的，那是什麼原因導致我們最終放棄了引用計數算法呢？看下面的例子。

public class ReferenceCountingGC {

    public Object instance;

    public ReferenceCountingGC(String name){}
}

public static void testGC(){

    ReferenceCountingGC a = new ReferenceCountingGC("objA");
    ReferenceCountingGC b = new ReferenceCountingGC("objB");

    a.instance = b;
    b.instance = a;

    a = null;
    b = null;
}

1. 定義2個對象

2. 相互引用

3. 置空各自的聲明引用

我們可以看到，最後這2個對象已經不可能再被訪問了，但由於他們相互引用着對方，導致它們的引用計數永遠都不會爲0，通過引用計數算法，也就永遠無法通知GC收集器回收它們。

可達性分析算法

可達性分析算法（Reachability Analysis）的基本思路是，通過一些被稱爲引用鏈（GC Roots）的對象作爲起點，從這些節點開始向下搜索，搜索走過的路徑被稱爲（Reference Chain)，當一個對象到 GC Roots 沒有任何引用鏈相連時（即從 GC Roots 節點到該節點不可達），則證明該對象是不可用的。

通過可達性算法，成功解決了引用計數所無法解決的問題-“循環依賴”，只要你無法與 GC Root 建立直接或間接的連接，系統就會判定你爲可回收對象。那這樣就引申出了另一個問題，哪些屬於 GC Root。

Java 內存區域

在 Java 語言中，可作爲 GC Root 的對象包括以下4種：

虛擬機棧（棧幀中的本地變量表）中引用的對象
方法區中類靜態屬性引用的對象
方法區中常量引用的對象
本地方法棧中 JNI（即一般說的 Native 方法）引用的對象

虛擬機棧（棧幀中的本地變量表）中引用的對象
此時的 s，即爲 GC Root，當s置空時，localParameter 對象也斷掉了與 GC Root 的引用鏈，將被回收。

public class StackLocalParameter {
    public StackLocalParameter(String name){}
}

public static void testGC(){
    StackLocalParameter s = new StackLocalParameter("localParameter");
    s = null;
}

方法區中類靜態屬性引用的對象
s 爲 GC Root，s 置爲 null，經過 GC 後，s 所指向的 properties 對象由於無法與 GC Root 建立關係被回收。

而 m 作爲類的靜態屬性，也屬於 GC Root，parameter 對象依然與 GC root 建立着連接，所以此時 parameter 對象並不會被回收。

public class MethodAreaStaicProperties {
    public static MethodAreaStaicProperties m;
    public MethodAreaStaicProperties(String name){}
}

public static void testGC(){
    MethodAreaStaicProperties s = new MethodAreaStaicProperties("properties");
    s.m = new MethodAreaStaicProperties("parameter");
    s = null;
}

方法區中常量引用的對象
m 即爲方法區中的常量引用，也爲 GC Root，s 置爲 null 後，final 對象也不會因沒有與 GC Root 建立聯繫而被回收。

public class MethodAreaStaicProperties {
    public static final MethodAreaStaicProperties m = MethodAreaStaicProperties("final");
    public MethodAreaStaicProperties(String name){}
}

public static void testGC(){
    MethodAreaStaicProperties s = new MethodAreaStaicProperties("staticProperties");
    s = null;
}

本地方法棧中引用的對象
任何 Native 接口都會使用某種本地方法棧，實現的本地方法接口是使用 C 連接模型的話，那麼它的本地方法棧就是 C 棧。當線程調用 Java 方法時，虛擬機會創建一個新的棧幀並壓入 Java 棧。然而當它調用的是本地方法時，虛擬機會保持 Java 棧不變，不再在線程的 Java 棧中壓入新的幀，虛擬機只是簡單地動態連接並直接調用指定的本地方法。

有哪些算法回收這些垃圾

在確定了哪些垃圾可以被回收後，垃圾收集器要做的事情就是開始進行垃圾回收，但是這裏面涉及到一個問題是：如何高效地進行垃圾回收。由於Java虛擬機規範並沒有對如何實現垃圾收集器做出明確的規定，因此各個廠商的虛擬機可以採用不同的方式來實現垃圾收集器，這裏我們討論幾種常見的垃圾收集算法的核心思想。

標記 --- 清除算法

標記清除算法（Mark-Sweep）是最基礎的一種垃圾回收算法，它分爲2部分，先把內存區域中的這些對象進行標記，哪些屬於可回收標記出來，然後把這些垃圾拎出來清理掉。就像上圖一樣，清理掉的垃圾就變成未使用的內存區域，等待被再次使用。

這邏輯再清晰不過了，並且也很好操作，但它存在一個很大的問題，那就是內存碎片。

上圖中等方塊的假設是 2M，小一些的是 1M，大一些的是 4M。等我們回收完，內存就會切成了很多段。我們知道開闢內存空間時，需要的是連續的內存區域，這時候我們需要一個 2M的內存區域，其中有2個 1M 是沒法用的。這樣就導致，其實我們本身還有這麼多的內存的，但卻用不了。

特點：簡單方便、容易產生內存碎片

複製算法

複製算法（Copying）是在標記清除算法上演化而來，解決標記清除算法的內存碎片問題。它將可用內存按容量劃分爲大小相等的兩塊，每次只使用其中的一塊。當這一塊的內存用完了，就將還存活着的對象複製到另外一塊上面，然後再把已使用過的內存空間一次清理掉。保證了內存的連續可用，內存分配時也就不用考慮內存碎片等複雜情況，邏輯清晰，運行高效。

上面的圖很清楚，也很明顯的暴露了另一個問題，合着我這140平的大三房，只能當70平米的小兩房來使？代價實在太高。

特點：簡單、不會產生碎片、內存利用率太低，只用了一半

標記整理算法

標記整理算法（Mark-Compact）標記過程仍然與標記 --- 清除算法一樣，但後續步驟不是直接對可回收對象進行清理，而是讓所有存活的對象都向一端移動，再清理掉端邊界以外的內存區域。

標記整理算法一方面在標記-清除算法上做了升級，解決了內存碎片的問題，也規避了複製算法只能利用一半內存區域的弊端。看起來很美好，但從上圖可以看到，它對內存變動更頻繁，需要整理所有存活對象的引用地址，在效率上比複製算法要差很多。

特點：適合存活對象多，垃圾少的情況、需要整理的過程

堆和方法區的垃圾回收

上面我提到了三種方法來回收內存，下面要講的分代回收算法是第四種。首先在文章的第一部分我們曾說到，java中的垃圾回收大致在兩部分，第一個就是堆、第二個就是方法區。爲此先看方法區是如何進行垃圾回收的。

1、方法區的垃圾回收

方法區又叫做永久代（或者持久代）。永久代的垃圾回收主要有兩部分：廢棄常量和無用的類。

首先是廢棄常量垃圾回收的一般步驟：

第一步：判定一個常量是否是廢棄常量：沒有任何一個地方對這個常量進行引用就表示是廢棄常量。

第二步：垃圾回收

然後是無用的類垃圾回收的一般步驟

第一步：判定一個類是否是“無用的類”：需要滿足下面三個條件

Java堆中不存在該類的任何實例，也就是該類的所有實例都被回收加載該類的ClassLoader已經被回收該類對應的Class對象在任何地方沒有引用了，也不能通過反射訪問該類的方法。第二步：滿足上面三個條件就可以回收了，但不是強制的。

注意：《java虛擬機規範》裏面曾經說到過，不要求虛擬機對方法區進行垃圾回收。而且方法區進行垃圾回收性價比比較低。

2、Java 堆的垃圾回收：分代回收算法

分代收集算法分代收集算法（Generational Collection）嚴格來說並不是一種思想或理論，而是融合上述3種基礎的算法思想，而產生的針對不同情況所採用不同算法的一套組合拳。對象存活週期的不同將內存劃分爲幾塊。一般是把 Java 堆分爲新生代和老年代，這樣就可以根據各個年代的特點採用最適當的收集算法。

在新生代中，每次垃圾收集時都發現有大批對象死去，只有少量存活，那就選用複製算法，只需要付出少量存活對象的複製成本就可以完成收集。特點：存活對象少、垃圾多。

而老年代中因爲對象存活率高、沒有額外空間對它進行分配擔保，就必須使用標記-清理或者標記 --- 整理算法來進行回收。特點：存活對象多、垃圾少。

下圖就是 Java 堆的結構。

(1)新生代－複製回收機制

Java 堆主要分爲2個區域-年輕代與老年代，其中年輕代又分 Eden 區和 Survivor 區，其中 Survivor 區又分 From 和 To 2個區。可能這時候大家會有疑問，爲什麼需要 Survivor 區，爲什麼Survivor 還要分2個區。不着急，我們從頭到尾，看看對象到底是怎麼來的，而它又是怎麼沒的。

Eden 區

IBM 公司的專業研究表明，有將近98%的對象是朝生夕死，所以針對這一現狀，大多數情況下，對象會在新生代 Eden 區中進行分配，當 Eden 區沒有足夠空間進行分配時，虛擬機會發起一次 Minor GC，Minor GC 相比 Major GC 更頻繁，回收速度也更快。

通過 Minor GC 之後，Eden 會被清空，Eden 區中絕大部分對象會被回收，而那些無需回收的存活對象，將會進到 Survivor 的 From 區（若 From 區不夠，則直接進入 Old 區）。

Survivor 區

Survivor 區相當於是 Eden 區和 Old 區的一個緩衝，類似於我們交通燈中的黃燈。Survivor 又分爲2個區，一個是 From 區，一個是 To 區。每次執行 Minor GC，會將 Eden 區和 From 存活的對象放到 Survivor 的 To 區（如果 To 區不夠，則直接進入 Old 區）。

爲啥需要？

不就是新生代到老年代麼，直接 Eden 到 Old 不好了嗎，爲啥要這麼複雜。想想如果沒有 Survivor 區，Eden 區每進行一次 Minor GC，存活的對象就會被送到老年代，老年代很快就會被填滿。而有很多對象雖然一次 Minor GC 沒有消滅，但其實也並不會蹦躂多久，或許第二次，第三次就需要被清除。這時候移入老年區，很明顯不是一個明智的決定。

所以，Survivor 的存在意義就是減少被送到老年代的對象，進而減少 Major GC 的發生。Survivor 的預篩選保證，只有經歷16次 Minor GC 還能在新生代中存活的對象，纔會被送到老年代。

爲啥需要倆？

設置兩個 Survivor 區最大的好處就是解決內存碎片化。

我們先假設一下，Survivor 如果只有一個區域會怎樣。Minor GC 執行後，Eden 區被清空了，存活的對象放到了 Survivor 區，而之前 Survivor 區中的對象，可能也有一些是需要被清除的。問題來了，這時候我們怎麼清除它們？在這種場景下，我們只能標記清除，而我們知道標記清除最大的問題就是內存碎片，在新生代這種經常會消亡的區域，採用標記清除必然會讓內存產生嚴重的碎片化。因爲 Survivor 有2個區域，所以每次 Minor GC，會將之前 Eden 區和 From 區中的存活對象複製到 To 區域。第二次 Minor GC 時，From 與 To 職責兌換，這時候會將 Eden 區和 To 區中的存活對象再複製到 From 區域，以此反覆。

這種機制最大的好處就是，整個過程中，永遠有一個 Survivor space 是空的，另一個非空的 Survivor space 是無碎片的。那麼，Survivor 爲什麼不分更多塊呢？比方說分成三個、四個、五個?顯然，如果 Survivor 區再細分下去，每一塊的空間就會比較小，容易導致 Survivor 區滿，兩塊 Survivor 區可能是經過權衡之後的最佳方案。

（2）老年代－標記整理回收機制

老年代佔據着2/3的堆內存空間，只有在 Major GC 的時候纔會進行清理，每次 GC 都會觸發“Stop-The-World”。內存越大，STW 的時間也越長，所以內存也不僅僅是越大就越好。由於複製算法在對象存活率較高的老年代會進行很多次的複製操作，效率很低，所以老年代這裏採用的是標記 --- 整理算法。

除了上述所說，在內存擔保機制下，無法安置的對象會直接進到老年代，以下幾種情況也會進入老年代。

大對象

大對象指需要大量連續內存空間的對象，這部分對象不管是不是“朝生夕死”，都會直接進到老年代。這樣做主要是爲了避免在 Eden 區及2個 Survivor 區之間發生大量的內存複製。當你的系統有非常多“朝生夕死”的大對象時，得注意了。

長期存活對象

虛擬機給每個對象定義了一個對象年齡（Age）計數器。正常情況下對象會不斷的在 Survivor 的 From 區與 To 區之間移動，對象在 Survivor 區中每經歷一次 Minor GC，年齡就增加1歲。當年齡增加到15歲時，這時候就會被轉移到老年代。當然，這裏的15，JVM 也支持進行特殊設置。

動態對象年齡

虛擬機並不重視要求對象年齡必須到15歲，纔會放入老年區，如果 Survivor 空間中相同年齡所有對象大小的總合大於 Survivor 空間的一半，年齡大於等於該年齡的對象就可以直接進去老年區，無需等你“成年”。

這其實有點類似於負載均衡，輪詢是負載均衡的一種，保證每臺機器都分得同樣的請求。看似很均衡，但每臺機的硬件不通，健康狀況不同，我們還可以基於每臺機接受的請求數，或每臺機的響應時間等，來調整我們的負載均衡算法。

到了這，基本上對堆內存的分代回收機制進行了描述。但是要有一個問題沒有解決，那就是jvm提供的垃圾回收器。

jvm提供了哪些垃圾回收器

如果說收集算法是內存回收的方法論，那麼垃圾收集器就是內存回收的具體實現。

在瞭解垃圾回收器之前，首先得了解一下垃圾回收器的幾個名詞。

1. 吞吐量

CPU 用於運行用戶代碼的時間與 CPU 總消耗時間的比值。比如說虛擬機總運行了 100 分鐘，用戶代碼時間 99 分鐘，垃圾回收時間 1 分鐘，那麼吞吐量就是 99%。

2. 停頓時間

停頓時間指垃圾回收器正在運行時，應用程序的暫停時間。

3. GC的名詞

新生代GC：Minor GC

老年代GC：Major GC

4. 併發與並行

（1）串行（Parallel）

垃圾回收線程進行垃圾回收工作，但此時用戶線程仍然處於等待狀態。

（2）併發（Concurrent）

這裏的併發指用戶線程與垃圾回收線程交替執行。

（3）並行（Parallel）

這裏的並行指用戶線程和多條垃圾回收線程分別在不同 CPU 上同時工作。

下面其中垃圾回收器是基於HotSpot虛擬機。先給一張圖看一下

在 JVM 中，具體實現有 Serial、ParNew、Parallel Scavenge、CMS、Serial Old（MSC）、Parallel Old、G1 等。在上圖中，你可以看到不同垃圾回收器適合於不同的內存區域，如果兩個垃圾回收器之間存在連線，那麼表示兩者可以配合使用。

下面對這其中垃圾回收器有一個瞭解。

第一種：Serial（單線程）

Serial 回收器是最基本的新生代垃圾回收器，是單線程的垃圾回收器。採用的是複製算法。垃圾清理時，Serial回收器不存在線程間的切換，因此，在單 CPU` 的環境下，垃圾清除效率比較高。

第二種：Serial Old（單線程）

Serial Old回收器是 Serial回收器的老生代版本，單線程回收器，使用標記-整理算法。在 JDK1.5 及其以前，它常與Parallel Scavenge回收器配合使用，達到較好的吞吐量，另外它也是 CMS 回收器在Concurrent Mode Failure時的後備方案。

第三種：ParNew（多線程）

ParNew回收器是在Serial回收器的基礎上演化而來的，屬於Serial回收器的多線程版本，採用複製算法。運行在新生代區域。在實現上，兩者共用很多代碼。在不同運行環境下，根據CPU核數，開啓不同的線程數，從而達到最優的垃圾回收效果。

第四種：Parallel Scavenge（多線程）

Parallel Scavenge回收器也是運行在新生代區域，屬於多線程的回收器，採用複製算法。與ParNew不同的是，ParNew回收器是通過控制垃圾回收的線程數來進行參數調整，而Parallel Scavenge回收器更關心的是程序運行的吞吐量。即一段時間內用戶代碼運行時間佔總運行時間的百分比。

第五種：Parallel Old（多線程）

Parallel Old回收器是Parallel Scavenge回收器的老生代版本，屬於多線程回收器，採用標記-整理算法。Parallel Old回收器和Parallel Scavenge回收器同樣考慮了吞吐量優先這一指標，非常適合那些注重吞吐量和CPU資源敏感的場合。

第六種：CMS（多線程回收）

CMS回收器是在最短回收停頓時間爲前提的回收器，屬於多線程回收器，採用標記-清除算法。

第七種：G1回收器

G1是 JDK 1.7中正式投入使用的用於取代CMS的壓縮回收器。它雖然沒有在物理上隔斷新生代與老生代，但是仍然屬於分代垃圾回收器。G1仍然會區分年輕代與老年代，年輕代依然分有Eden區與Survivor區。

G1首先將堆分爲大小相等的 Region，避免全區域的垃圾回收。G1的分區示例如下圖所示：

這種使用區域劃分內存空間以及有優先級的區域回收方式，保證G1回收器在有限的時間內可以獲得儘可能高的回收效率。

下面對這幾種垃圾回收機制進行一個總結：

【Java】垃圾回收機制

什麼是垃圾回收

jvm中的內存結構

哪些對象是垃圾呢？

引用計數算法

可達性分析算法

有哪些算法回收這些垃圾

標記 --- 清除算法

複製算法

堆和方法區的垃圾回收

jvm提供了哪些垃圾回收器

【Consul】ConsulClient獲取服務，註冊服務

【SpringCloud】application.yml和 bootstrap.yml 區別

【Nginx】配置返回文本或json

【Java】統計一個字符串中，指定字符串出現的次數

【Java】WIN解析exe文件

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結