Java知識點解析——JVM篇

一、JVM 基礎知識

1）Java 是如何實現跨平臺的？

注意：跨平臺的是 Java 程式，而不是 JVM。JVM 是用 C/C++ 開發的，是編譯後的機器碼，不能跨平臺，不同平臺下需要安裝不同版本的 JVM

答：我們編寫的 Java 原始碼，編譯後會生成一種 .class 檔案，稱為位元組碼檔案。Java 虛擬機器（JVM）就是負責將位元組碼檔案翻譯成特定平臺下的機器碼然後執行，也就是說，只要在不同平臺上安裝對應的 JVM，就可以執行位元組碼檔案，執行我們編寫的 Java 程式。

而這個過程，我們編寫的 Java 程式沒有做任何改變，僅僅是通過 JVM 這一 “中間層” ，就能在不同平臺上執行，真正實現了 “一次編譯，到處執行” 的目的。

640

2）什麼是 JVM ？

解析：不僅僅是基本概念，還有 JVM 的作用。

答：JVM，即 Java Virtual Machine，Java 虛擬機器。它通過模擬一個計算機來達到一個計算機所具有的的計算功能。JVM 能夠跨計算機體系結構來執行 Java 位元組碼，主要是由於 JVM 遮蔽了與各個計算機平臺相關的軟體或者硬體之間的差異，使得與平臺相關的耦合統一由 JVM 提供者來實現。

3）JVM 由哪些部分組成？

解析：這是對 JVM 體系結構的考察

答：JVM 的結構基本上由 4 部分組成：

類載入器，在 JVM 啟動時或者類執行時將需要的 class 載入到 JVM 中
執行引擎，執行引擎的任務是負責執行 class 檔案中包含的位元組碼指令，相當於實際機器上的 CPU
記憶體區，將記憶體劃分成若干個區以模擬實際機器上的儲存、記錄和排程功能模組，如實際機器上的各種功能的暫存器或者 PC 指標的記錄器等
本地方法呼叫，呼叫 C 或 C++ 實現的本地方法的程式碼返回結果

640

4）類載入器是有了解嗎？

解析：底層原理的考察，其中涉及到類載入器的概念，功能以及一些底層的實現。

答：顧名思義，類載入器（class loader）用來載入 Java 類到 Java 虛擬機器中。一般來說，Java 虛擬機器使用 Java 類的方式如下：Java 源程式（.java 檔案）在經過 Java 編譯器編譯之後就被轉換成 Java 位元組程式碼（.class 檔案）。

類載入器負責讀取 Java 位元組程式碼，並轉換成 java.lang.Class類的一個例項。每個這樣的例項用來表示一個 Java 類。通過此例項的 newInstance()方法就可以創建出該類的一個物件。實際的情況可能更加複雜，比如 Java 位元組程式碼可能是通過工具動態生成的，也可能是通過網路下載的。

面試官：Java 虛擬機器是如何判定兩個 Java 類是相同的？

答：Java 虛擬機器不僅要看類的全名是否相同，還要看載入此類的類載入器是否一樣。只有兩者都相同的情況，才認為兩個類是相同的。即便是同樣的位元組程式碼，被不同的類載入器載入之後所得到的類，也是不同的。比如一個 Java 類 com.example.Sample，編譯之後生成了位元組程式碼檔案 Sample.class。兩個不同的類載入器 ClassLoaderA和 ClassLoaderB分別讀取了這個 Sample.class檔案，並定義出兩個 java.lang.Class類的例項來表示這個類。這兩個例項是不相同的。對於 Java 虛擬機器來說，它們是不同的類。試圖對這兩個類的物件進行相互賦值，會丟擲執行時異常 ClassCastException。

5）類載入器是如何載入 class 檔案的？

答：下圖所示是 ClassLoader 載入一個 class 檔案到 JVM 時需要經過的步驟：

640

第一個階段是找到 .class 檔案並把這個檔案包含的位元組碼載入到記憶體中

第二階段又可以分為三個步驟，分別是位元組碼驗證、Class 類資料結構分析及相應的記憶體分配和最後的符號表的連結

第三個階段是類中靜態屬性和初始化賦值，以及靜態塊的執行等

面試官：能詳細講講嗎？

答：

1.載入

查詢並載入類的二進位制資料載入時類載入過程的第一個階段，在載入階段，虛擬機器需要完成以下三件事情：

通過一個類的全限定名來獲取其定義的二進位制位元組流。
將這個位元組流所代表的靜態儲存結構轉化為方法區的執行時資料結構。
在Java堆中生成一個代表這個類的 java.lang.Class 物件，作為對方法區中這些資料的訪問入口。

相對於類載入的其他階段而言，載入階段（準確地說，是載入階段獲取類的二進位制位元組流的動作）是可控性最強的階段，因為開發人員既可以使用系統提供的類載入器來完成載入，也可以自定義自己的類載入器來完成載入。

載入階段完成後，虛擬機器外部的二進位制位元組流就按照虛擬機器所需的格式儲存在方法區之中，而且在Java堆中也建立一個 java.lang.Class類的物件，這樣便可以通過該物件訪問方法區中的這些資料。

2.連線

驗證：確保被載入的類的正確性

驗證是連線階段的第一步，這一階段的目的是為了確保Class檔案的位元組流中包含的資訊符合當前虛擬機器的要求，並且不會危害虛擬機器自身的安全。驗證階段大致會完成4個階段的檢驗動作：

檔案格式驗證：驗證位元組流是否符合Class檔案格式的規範；例如：是否以 0xCAFEBABE開頭、主次版本號是否在當前虛擬機器的處理範圍之內、常量池中的常量是否有不被支援的型別。
元資料驗證：對位元組碼描述的資訊進行語義分析（注意：對比javac編譯階段的語義分析），以保證其描述的資訊符合Java語言規範的要求；例如：這個類是否有父類，除了 java.lang.Object之外。
位元組碼驗證：通過資料流和控制流分析，確定程式語義是合法的、符合邏輯的。
符號引用驗證：確保解析動作能正確執行。

驗證階段是非常重要的，但不是必須的，它對程式執行期沒有影響，如果所引用的類經過反覆驗證，那麼可以考慮採用 -Xverifynone 引數來關閉大部分的類驗證措施，以縮短虛擬機器類載入的時間。

準備：為類的靜態變數分配記憶體，並將其初始化為預設值

準備階段是正式為類變數分配記憶體並設定類變數初始值的階段，這些記憶體都將在方法區中分配。對於該階段有以下幾點需要注意：

① 這時候進行記憶體分配的僅包括類變數（static），而不包括例項變數，例項變數會在物件例項化時隨著物件一塊分配在Java堆中。
② 這裡所設定的初始值通常情況下是資料型別預設的零值（如0、0L、null、false等），而不是被在Java程式碼中被顯式地賦予的值。

假設一個類變數的定義為： public static int value = 3;

那麼變數value在準備階段過後的初始值為 0，而不是 3，因為這時候尚未開始執行任何 Java 方法，而把 value 賦值為 3 的public static指令是在程式編譯後，存放於類構造器 <clinit>（）方法之中的，所以把value賦值為3的動作將在初始化階段才會執行。

這裡還需要注意如下幾點：
對基本資料型別來說，對於類變數（static）和全域性變數，如果不顯式地對其賦值而直接使用，則系統會為其賦予預設的零值，而對於區域性變數來說，在使用前必須顯式地為其賦值，否則編譯時不通過。
對於同時被static和final修飾的常量，必須在宣告的時候就為其顯式地賦值，否則編譯時不通過；而只被final修飾的常量則既可以在宣告時顯式地為其賦值，也可以在類初始化時顯式地為其賦值，總之，在使用前必須為其顯式地賦值，系統不會為其賦予預設零值。
對於引用資料型別reference來說，如陣列引用、物件引用等，如果沒有對其進行顯式地賦值而直接使用，系統都會為其賦予預設的零值，即null。
如果在陣列初始化時沒有對陣列中的各元素賦值，那麼其中的元素將根據對應的資料型別而被賦予預設的零值。

③ 如果類欄位的欄位屬性表中存在 ConstantValue 屬性，即同時被 final 和 static 修飾，那麼在準備階段變數 value 就會被初始化為 ConstValue 屬性所指定的值。

假設上面的類變數 value 被定義為： public static final int value = 3;

編譯時 Javac 將會為 value 生成 ConstantValue 屬性，在準備階段虛擬機器就會根據 ConstantValue 的設定將 value 賦值為 3。我們可以理解為 static final 常量在編譯期就將其結果放入了呼叫它的類的常量池中

解析：把類中的符號引用轉換為直接引用

解析階段是虛擬機器將常量池內的符號引用替換為直接引用的過程，解析動作主要針對類或介面、欄位、類方法、介面方法、方法型別、方法控制代碼和呼叫點限定符7類符號引用進行。符號引用就是一組符號來描述目標，可以是任何字面量。

直接引用就是直接指向目標的指標、相對偏移量或一個間接定位到目標的控制代碼。

3.初始化

初始化，為類的靜態變數賦予正確的初始值，JVM負責對類進行初始化，主要對類變數進行初始化。在Java中對類變數進行初始值設定有兩種方式：

① 宣告類變數是指定初始值
② 使用靜態程式碼塊為類變數指定初始值

JVM初始化步驟

1、假如這個類還沒有被載入和連線，則程式先載入並連線該類
2、假如該類的直接父類還沒有被初始化，則先初始化其直接父類
3、假如類中有初始化語句，則系統依次執行這些初始化語句

類初始化時機：只有當對類的主動使用的時候才會導致類的初始化，類的主動使用包括以下六種：

建立類的例項，也就是new的方式
訪問某個類或介面的靜態變數，或者對該靜態變數賦值
呼叫類的靜態方法
反射（如 Class.forName(“com.shengsiyuan.Test”)）
初始化某個類的子類，則其父類也會被初始化
Java虛擬機器啟動時被標明為啟動類的類（ JavaTest），直接使用 java.exe命令來執行某個主類

結束生命週期

在如下幾種情況下，Java虛擬機器將結束生命週期

執行了 System.exit()方法
程式正常執行結束
程式在執行過程中遇到了異常或錯誤而異常終止
由於作業系統出現錯誤而導致Java虛擬機器程序終止

參考文章：jvm系列(一):java類的載入機制 - 純潔的微笑

6）雙親委派模型（Parent Delegation Model）？

解析：類的載入過程採用雙親委派機制，這種機制能更好的保證 Java 平臺的安全性

答：類載入器 ClassLoader 是具有層次結構的，也就是父子關係，其中，Bootstrap 是所有類載入器的父親，如下圖所示：

640

該模型要求除了頂層的 Bootstrap class loader 啟動類載入器外，其餘的類載入器都應當有自己的父類載入器。子類載入器和父類載入器不是以繼承（Inheritance）的關係來實現，而是通過組合（Composition）關係來複用父載入器的程式碼。每個類載入器都有自己的名稱空間（由該載入器及所有父類載入器所載入的類組成，在同一個名稱空間中，不會出現類的完整名字（包括類的包名）相同的兩個類；在不同的名稱空間中，有可能會出現類的完整名字（包括類的包名）相同的兩個類）

面試官：雙親委派模型的工作過程？

答：

1.當前 ClassLoader 首先從自己已經載入的類中查詢是否此類已經載入，如果已經載入則直接返回原來已經載入的類。

每個類載入器都有自己的載入快取，當一個類被載入了以後就會放入快取，
等下次載入的時候就可以直接返回了。

2.當前 ClassLoader 的快取中沒有找到被載入的類的時候，委託父類載入器去載入，父類載入器採用同樣的策略，首先檢視自己的快取，然後委託父類的父類去載入，一直到 bootstrap ClassLoader.

當所有的父類載入器都沒有載入的時候，再由當前的類載入器載入，並將其放入它自己的快取中，以便下次有載入請求的時候直接返回。

面試官：為什麼這樣設計呢？

解析：這是對於使用這種模型來組織累加器的好處

答：主要是為了安全性，避免使用者自己編寫的類動態替換 Java 的一些核心類，比如 String，同時也避免了重複載入，因為 JVM 中區分不同類，不僅僅是根據類名，相同的 class 檔案被不同的 ClassLoader 載入就是不同的兩個類，如果相互轉型的話會拋java.lang.ClassCaseException.

參考文章： JVM 的工作原理，層次結構以及 GC工作原理

二、JVM 記憶體管理

1）JVM 記憶體劃分：

640

答：

方法區（執行緒共享）：各個執行緒共享的一個區域，用於儲存虛擬機器載入的類資訊、常量、靜態變數、即時編譯器編譯後的程式碼等資料。雖然 Java 虛擬機器規範把方法區描述為堆的一個邏輯部分，但是它卻又一個別名叫做 Non-Heap（非堆），目的應該是與 Java 堆區分開來。

執行時常量池：是方法區的一部分，用於存放編譯器生成的各種字面量和符號引用。

堆記憶體（執行緒共享）：所有執行緒共享的一塊區域，垃圾收集器管理的主要區域。目前主要的垃圾回收演算法都是分代收集演算法，所以 Java 堆中還可以細分為：新生代和老年代；再細緻一點的有 Eden 空間、From Survivor 空間、To Survivor 空間等，預設情況下新生代按照8:1:1的比例來分配。根據 Java 虛擬機器規範的規定，Java 堆可以處於物理上不連續的記憶體空間中，只要邏輯上是連續的即可，就像我們的磁碟一樣。
程式計數器： Java 執行緒私有，類似於作業系統裡的 PC 計數器，它可以看做是當前執行緒所執行的位元組碼的行號指示器。如果執行緒正在執行的是一個 Java 方法，這個計數器記錄的是正在執行的虛擬機器位元組碼指令的地址；如果正在執行的是 Native 方法，這個計數器值則為空（Undefined）。此記憶體區域是唯一一個在 Java 虛擬機器規範中沒有規定任何 OutOfMemoryError 情況的區域。
虛擬機器棧（棧記憶體）：Java執行緒私有，虛擬機器展描述的是Java方法執行的記憶體模型：每個方法在執行的時候，都會建立一個棧幀用於儲存區域性變數、運算元、動態連結、方法出口等資訊；每個方法呼叫都意味著一個棧幀在虛擬機器棧中入棧到出棧的過程；
本地方法棧：和Java虛擬機器棧的作用類似，區別是該區域為 JVM 提供使用 native 方法的服務

2）物件分配規則？

答：

物件優先分配在Eden區，如果Eden區沒有足夠的空間時，虛擬機器執行一次Minor GC。
大物件直接進入老年代（大物件是指需要大量連續記憶體空間的物件）。這樣做的目的是避免在Eden區和兩個Survivor區之間發生大量的記憶體拷貝（新生代採用複製演算法收集記憶體）。
長期存活的物件進入老年代。虛擬機器為每個物件定義了一個年齡計數器，如果物件經過了1次Minor GC那麼物件會進入Survivor區，之後每經過一次Minor GC那麼物件的年齡加1，知道達到閥值物件進入老年區。
動態判斷物件的年齡。如果Survivor區中相同年齡的所有物件大小的總和大於Survivor空間的一半，年齡大於或等於該年齡的物件可以直接進入老年代。
空間分配擔保。每次進行Minor GC時，JVM會計算Survivor區移至老年區的物件的平均大小，如果這個值大於老年區的剩餘值大小則進行一次Full GC，如果小於檢查HandlePromotionFailure設定，如果true則只進行Monitor GC,如果false則進行Full GC。

3）Java 的記憶體模型：

答：

640

Java 虛擬機器規範中試圖定義一種 Java 記憶體模型（Java Memory Model, JMM）來遮蔽掉各層硬體和作業系統的記憶體訪問差異，以實現讓 Java 程式在各種平臺下都能達到一致的記憶體訪問效果。

Java 記憶體模型規定了所有的變數都儲存在主記憶體（Main Memory）中。每條執行緒還有自己的工作記憶體（Working Memory），執行緒的工作記憶體中儲存了被該執行緒使用到的變數的主記憶體副本拷貝，執行緒對變數的所有操作（讀取、賦值等）都必須在主記憶體中進行，而不能直接讀寫主記憶體中的變數。不同的執行緒之間也無法直接訪問對方工作記憶體中的變數，執行緒間的變數值的傳遞均需要通過主記憶體來完成，執行緒、主記憶體、工作記憶體三者的關係如上圖。

面試官：兩個執行緒之間是如何通訊的呢？

答：在共享記憶體的併發模型裡，執行緒之間共享程式的公共狀態，執行緒之間通過寫-讀記憶體中的公共狀態來隱式進行通訊，典型的共享記憶體通訊方式就是通過共享物件進行通訊。

640

例如上圖執行緒 A 與執行緒 B 之間如果要通訊的話，那麼就必須經歷下面兩個步驟：

1.首先，執行緒 A 把本地記憶體 A 更新過得共享變數重新整理到主記憶體中去
2.然後，執行緒 B 到主記憶體中去讀取執行緒 A 之前更新過的共享變數

640

在訊息傳遞的併發模型裡，執行緒之間沒有公共狀態，執行緒之間必須通過明確的傳送訊息來顯式進行通訊，在 Java 中典型的訊息傳遞方式就是 wait() 和 notify()。

4）記憶體屏障？

解析：在這之前應該對重排序的問題有所瞭解，這裡我找到一篇很好的文章分享一下：Java記憶體訪問重排序的研究：https://tech.meituan.com/java-memory-reordering.html

答：記憶體屏障，又稱記憶體柵欄，是一組處理器指令，用於實現對記憶體操作的順序限制。

面試官：記憶體屏障為何重要？

答：對主存的一次訪問一般花費硬體的數百次時鐘週期。處理器通過快取（caching）能夠從數量級上降低記憶體延遲的成本這些快取為了效能重新排列待定記憶體操作的順序。也就是說，程式的讀寫操作不一定會按照它要求處理器的順序執行。當資料是不可變的，同時/或者資料限制線上程範圍內，這些優化是無害的。如果把這些優化與對稱多處理（symmetric multi-processing）和共享可變狀態（shared mutable state）結合，那麼就是一場噩夢。當基於共享可變狀態的記憶體操作被重新排序時，程式可能行為不定。一個執行緒寫入的資料可能被其他執行緒可見，原因是資料寫入的順序不一致。適當的放置記憶體屏障通過強制處理器順序執行待定的記憶體操作來避免這個問題。

5）類似-Xms、-Xmn這些引數的含義：

答：

堆記憶體分配：

JVM初始分配的記憶體由-Xms指定，預設是實體記憶體的1/64
JVM最大分配的記憶體由-Xmx指定，預設是實體記憶體的1/4
預設空餘堆記憶體小於40%時，JVM就會增大堆直到-Xmx的最大限制；空餘堆記憶體大於70%時，JVM會減少堆直到 -Xms的最小限制。
因此伺服器一般設定-Xms、-Xmx相等以避免在每次GC 後調整堆的大小。物件的堆記憶體由稱為垃圾回收器的自動記憶體管理系統回收。

非堆記憶體分配：

JVM使用-XX:PermSize設定非堆記憶體初始值，預設是實體記憶體的1/64；
由XX:MaxPermSize設定最大非堆記憶體的大小，預設是實體記憶體的1/4。
-Xmn2G：設定年輕代大小為2G。
-XX:SurvivorRatio，設定年輕代中Eden區與Survivor區的比值。

6）記憶體洩漏和記憶體溢位

答：

概念：

記憶體溢位指的是記憶體不夠用了。
記憶體洩漏是指物件可達，但是沒用了。即本該被GC回收的物件並沒有被回收
記憶體洩露是導致記憶體溢位的原因之一；記憶體洩露積累起來將導致記憶體溢位。

記憶體洩漏的原因分析：

長生命週期的物件引用短生命週期的物件
沒有將無用物件置為null

小結：本小節涉及到 JVM 虛擬機器，包括對記憶體的管理等知識，相對較深。除了以上問題，面試官會繼續問你一些比較深的問題，可能也是為了看看你的極限在哪裡吧。比如：記憶體調優、記憶體管理，是否遇到過記憶體洩露的實際案例、是否真正關心過記憶體等。

7）簡述一下 Java 中建立一個物件的過程？

解析：回答這個問題首先就要清楚類的生命週期

答：下圖展示的是類的生命週期流向：

640

Java中物件的建立就是在堆上分配記憶體空間的過程，此處說的物件建立僅限於new關鍵字建立的普通Java物件，不包括陣列物件的建立。

大致過程如下：

1.檢測類是否被載入：

當虛擬機器執行到new時，會先去常量池中查詢這個類的符號引用。如果能找到符號引用，說明此類已經被載入到方法區（方法區儲存虛擬機器已經載入的類的資訊），可以繼續執行；如果找不到符號引用，就會使用類載入器執行類的載入過程，類載入完成後繼續執行。

2.為物件分配記憶體：

類載入完成以後，虛擬機器就開始為物件分配記憶體，此時所需記憶體的大小就已經確定了。只需要在堆上分配所需要的記憶體即可。

具體的分配記憶體有兩種情況：第一種情況是記憶體空間絕對規整，第二種情況是記憶體空間是不連續的。

對於記憶體絕對規整的情況相對簡單一些，虛擬機器只需要在被佔用的記憶體和可用空間之間移動指標即可，這種方式被稱為指標碰撞。
對於記憶體不規整的情況稍微複雜一點，這時候虛擬機器需要維護一個列表，來記錄哪些記憶體是可用的。分配記憶體的時候需要找到一個可用的記憶體空間，然後在列表上記錄下已被分配，這種方式成為空閒列表。

分配記憶體的時候也需要考慮執行緒安全問題，有兩種解決方案：

第一種是採用同步的辦法，使用CAS來保證操作的原子性。
另一種是每個執行緒分配記憶體都在自己的空間內進行，即是每個執行緒都在堆中預先分配一小塊記憶體，稱為本地執行緒分配緩衝（TLAB），分配記憶體的時候再TLAB上分配，互不干擾。

3.為分配的記憶體空間初始化零值：

物件的記憶體分配完成後，還需要將物件的記憶體空間都初始化為零值，這樣能保證物件即使沒有賦初值，也可以直接使用。

4.對物件進行其他設定：

分配完記憶體空間，初始化零值之後，虛擬機器還需要對物件進行其他必要的設定，設定的地方都在物件頭中，包括這個物件所屬的類，類的元資料資訊，物件的hashcode，GC分代年齡等資訊。

5.執行 init 方法：

執行完上面的步驟之後，在虛擬機器裡這個物件就算建立成功了，但是對於Java程式來說還需要執行init方法才算真正的建立完成，因為這個時候物件只是被初始化零值了，還沒有真正的去根據程式中的程式碼分配初始值，呼叫了init方法之後，這個物件才真正能使用。

到此為止一個物件就產生了，這就是new關鍵字建立物件的過程。過程如下：

640

參考文章：Java建立物件的過程簡介

面試官：物件的記憶體佈局是怎樣的？

答：物件的記憶體佈局包括三個部分：物件頭，例項資料和對齊填充。

物件頭：物件頭包括兩部分資訊，第一部分是儲存物件自身的執行時資料，如雜湊碼，GC分代年齡，鎖狀態標誌，執行緒持有的鎖等等。第二部分是型別指標，即物件指向類元資料的指標。
例項資料：就是資料啦
對齊填充：不是必然的存在，就是為了對齊的嘛

面試官：物件是如何定位訪問的？

答：物件的訪問定位有兩種：控制代碼定位和直接指標

控制代碼定位：Java 堆會畫出一塊記憶體來作為控制代碼池，reference中儲存的就是物件的控制代碼地址，而控制代碼中包含了物件例項資料與型別資料各自的具體地址資訊

640

直接指標訪問：java堆物件的不居中就必須考慮如何放置訪問型別資料的相關資訊，而reference中儲存的直接就是物件地址

640

比較：使用直接指標就是速度快，使用控制代碼reference指向穩定的控制代碼，物件被移動改變的也只是控制代碼中例項資料的指標，而reference本身並不需要修改。

參考文章：JAVA物件建立的過程

三、GC 相關

1）如何判斷一個物件是否已經死去？

答：

引用計數：每個物件有一個引用計數屬性，新增一個引用時計數加1，引用釋放時計數減1，計數為0時可以回收。此方法簡單，無法解決物件相互迴圈引用的問題。
可達性分析（Reachability Analysis）：從GC Roots開始向下搜尋，搜尋所走過的路徑稱為引用鏈。當一個物件到GC Roots沒有任何引用鏈相連時，則證明此物件是不可用的。不可達物件。

2）垃圾回收演算法有哪些？

答：

引用計數：
原理是此物件有一個引用，即增加一個計數，刪除一個引用則減少一個計數。垃圾回收時，只用收集計數為0的物件。此演算法最致命的是無法處理迴圈引用的問題。
標記-清除：
此演算法執行分兩階段。第一階段從引用根節點開始標記所有被引用的物件，第二階段遍歷整個堆，把未標記的物件清除。此演算法需要暫停整個應用，同時，會產生記憶體碎片。

640

複製演算法：
此演算法把記憶體空間劃為兩個相等的區域，每次只使用其中一個區域。垃圾回收時，遍歷當前使用區域，把正在使用中的物件複製到另外一個區域中。此演算法每次只處理正在使用中的物件，因此複製成本比較小，同時複製過去以後還能進行相應的記憶體整理，不會出現“碎片”問題。當然，此演算法的缺點也是很明顯的，就是需要兩倍記憶體空間。

640

標記-整理：
此演算法結合了 “標記-清除” 和 “複製” 兩個演算法的優點。也是分兩階段，第一階段從根節點開始標記所有被引用物件，第二階段遍歷整個堆，把清除未標記物件並且把存活物件“壓縮”到堆的其中一塊，按順序排放。此演算法避免了 “標記-清除” 的碎片問題，同時也避免了 “複製” 演算法的空間問題。

640

分代收集演算法：

分代收集演算法並沒有提出新的思想，只是根據物件存活週期的不同將記憶體劃為幾塊。一般Java堆分為新生代和老年代，這樣就可以根據各個年代的特點採用適當的收集演算法。
在新生袋中每次垃圾手機時都會由大批物件死去，只有少量存活，那就用複製演算法，只需要付出少量存活物件的複製成本就可以。老年代中物件存活率高、沒有額外擔保，所以必須使用“標記-清理”或者“標記整理演算法。

參考文章：jvm系列(三):GC演算法垃圾收集器——純潔的微笑

3）GC什麼時候開始？

答：GC經常發生的區域是堆區，堆區還可以細分為新生代、老年代，新生代還分為一個Eden區和兩個Survivor區。

物件優先在Eden中分配，當Eden中沒有足夠空間時，虛擬機器將發生一次Minor GC，因為Java大多數物件都是朝生夕滅，所以Minor GC非常頻繁，而且速度也很快；
Full GC，發生在老年代的GC，當老年代沒有足夠的空間時即發生Full GC，發生Full GC一般都會有一次Minor GC。大物件直接進入老年代，如很長的字串陣列，虛擬機器提供一個-XX:PretenureSizeThreadhold引數，令大於這個引數值的物件直接在老年代中分配，避免在Eden區和兩個Survivor區發生大量的記憶體拷貝；
發生Minor GC時，虛擬機器會檢測之前每次晉升到老年代的平均大小是否大於老年代的剩餘空間大小，如果大於，則進行一次Full GC，如果小於，則檢視HandlePromotionFailure設定是否允許擔保失敗，如果允許，那隻會進行一次Minor GC，如果不允許，則改為進行一次Full GC。

4）引用的分類？

答：

強引用：通過new出來的引用，只要強引用還存在，則不會回收。
軟引用：通過SoftReference類來實現，用來描述一些有用但非必須的物件。在系統將要發生記憶體溢位異常之前，會把這些物件回收了，如果這次回收還是記憶體不夠的話，才丟擲記憶體溢位異常。
弱引用：非必須物件，通過WeakReference類來實現，被弱引用引用的物件，只要已發生GC就會把它幹掉。
虛引用：通過PhantomReference類來實現，無法通過徐引用獲得物件的例項，唯一作用就是在這個物件被GC時會收到一個系統通知。

擴充套件閱讀：重新認識java（一） ---- 萬物皆物件，文章中有對這四個引用有詳細的描述，還有一些典型的應用，這裡就不摘過來啦...

5）垃圾收集器？

解析：如果說收集演算法是記憶體回收的方法論，垃圾收集器就是記憶體回收的具體實現

答：

1. Serial 收集器

序列收集器是最古老，最穩定以及效率高的收集器，可能會產生較長的停頓，只使用一個執行緒去回收。新生代、老年代使用序列回收；新生代複製演算法、老年代標記-壓縮；垃圾收集的過程中會 Stop The World（服務暫停）

引數控制： -XX:+UseSerialGC 序列收集器

640

2.ParNew 收集器

ParNew收集器 ParNew收集器其實就是Serial收集器的多執行緒版本。新生代並行，老年代序列；新生代複製演算法、老年代標記-壓縮

引數控制：

-XX:+UseParNewGC ParNew收集器
-XX:ParallelGCThreads 限制執行緒數量

640

3.Parallel Scavenge收集器

Parallel Scavenge收集器類似ParNew收集器，Parallel收集器更關注系統的吞吐量。可以通過引數來開啟自適應調節策略，虛擬機器會根據當前系統的執行情況收集效能監控資訊，動態調整這些引數以提供最合適的停頓時間或最大的吞吐量；也可以通過引數控制GC的時間不大於多少毫秒或者比例；新生代複製演算法、老年代標記-壓縮

引數控制： -XX:+UseParallelGC 使用Parallel收集器+ 老年代序列

4.Parallel Old 收集器

Parallel Old是Parallel Scavenge 收集器的老年代版本，使用多執行緒和“標記－整理”演算法。這個收集器是在 JDK 1.6 中才開始提供

引數控制： -XX:+UseParallelOldGC 使用Parallel收集器+ 老年代並行

5.CMS收集器

CMS（Concurrent Mark Sweep）收集器是一種以獲取最短回收停頓時間為目標的收集器。目前很大一部分的Java應用都集中在網際網路站或B/S系統的服務端上，這類應用尤其重視服務的響應速度，希望系統停頓時間最短，以給使用者帶來較好的體驗。

從名字（包含“Mark Sweep”）上就可以看出CMS收集器是基於“標記-清除”演算法實現的，它的運作過程相對於前面幾種收集器來說要更復雜一些，整個過程分為4個步驟，包括：

初始標記（CMS initial mark）
併發標記（CMS concurrent mark）
重新標記（CMS remark）
併發清除（CMS concurrent sweep）

其中初始標記、重新標記這兩個步驟仍然需要“Stop The World”。初始標記僅僅只是標記一下GC Roots能直接關聯到的物件，速度很快，併發標記階段就是進行GC Roots Tracing的過程，而重新標記階段則是為了修正併發標記期間，因使用者程式繼續運作而導致標記產生變動的那一部分物件的標記記錄，這個階段的停頓時間一般會比初始標記階段稍長一些，但遠比並發標記的時間短。

由於整個過程中耗時最長的併發標記和併發清除過程中，收集器執行緒都可以與使用者執行緒一起工作，所以總體上來說，CMS收集器的記憶體回收過程是與使用者執行緒一起併發地執行。老年代收集器（新生代使用ParNew）

優點: 併發收集、低停頓
缺點: 產生大量空間碎片、併發階段會降低吞吐量

引數控制：

-XX:+UseConcMarkSweepGC 使用CMS收集器
-XX:+ UseCMSCompactAtFullCollection Full GC後，進行一次碎片整理；整理過程是獨佔的，會引起停頓時間變長
-XX:+CMSFullGCsBeforeCompaction 設定進行幾次Full GC後，進行一次碎片整理
-XX:ParallelCMSThreads 設定CMS的執行緒數量（一般情況約等於可用CPU數量）

640

6.G1收集器

G1是目前技術發展的最前沿成果之一，HotSpot開發團隊賦予它的使命是未來可以替換掉JDK1.5中釋出的CMS收集器。與CMS收集器相比G1收集器有以下特點：

空間整合，G1收集器採用標記整理演算法，不會產生記憶體空間碎片。分配大物件時不會因為無法找到連續空間而提前觸發下一次GC。
可預測停頓，這是G1的另一大優勢，降低停頓時間是G1和CMS的共同關注點，但G1除了追求低停頓外，還能建立可預測的停頓時間模型，能讓使用者明確指定在一個長度為N毫秒的時間片段內，消耗在垃圾收集上的時間不得超過N毫秒，這幾乎已經是實時Java（RTSJ）的垃圾收集器的特徵了。

上面提到的垃圾收集器，收集的範圍都是整個新生代或者老年代，而G1不再是這樣。使用G1收集器時，Java堆的記憶體佈局與其他收集器有很大差別，它將整個Java堆劃分為多個大小相等的獨立區域（Region），雖然還保留有新生代和老年代的概念，但新生代和老年代不再是物理隔閡了，它們都是一部分（可以不連續）Region的集合。

640

G1的新生代收集跟ParNew類似，當新生代佔用達到一定比例的時候，開始出發收集。和CMS類似，G1收集器收集老年代物件會有短暫停頓。

收集步驟：

1、標記階段，首先初始標記(Initial-Mark),這個階段是停頓的(Stop the World Event)，並且會觸發一次普通Mintor GC。對應GC log:GC pause (young) (inital-mark)

2、Root Region Scanning，程式執行過程中會回收survivor區(存活到老年代)，這一過程必須在young GC之前完成。

3、Concurrent Marking，在整個堆中進行併發標記(和應用程式併發執行)，此過程可能被young GC中斷。在併發標記階段，若發現區域物件中的所有物件都是垃圾，那個這個區域會被立即回收(圖中打X)。同時，併發標記過程中，會計算每個區域的物件活性(區域中存活物件的比例)。

640

4、Remark, 再標記，會有短暫停頓(STW)。再標記階段是用來收集併發標記階段產生新的垃圾(併發階段和應用程式一同執行)；G1中採用了比CMS更快的初始快照演算法:snapshot-at-the-beginning (SATB)。

5、Copy/Clean up，多執行緒清除失活物件，會有STW。G1將回收區域的存活物件拷貝到新區域，清除Remember Sets，併發清空回收區域並把它返回到空閒區域連結串列中。

640

6、複製/清除過程後。回收區域的活性物件已經被集中回收到深藍色和深綠色區域。

640