一文讀懂JVM

（一）JVM 基礎知識

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

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

答：咱們編寫的 Java 源碼，編譯後會生成一種 .class 文件，稱爲字節碼文件。Java 虛擬機（JVM）就是負責將字節碼文件翻譯成特定平臺下的機器碼而後運行，也就是說，只要在不一樣平臺上安裝對應的 JVM，就能夠運行字節碼文件，運行咱們編寫的 Java 程序。

而這個過程，咱們編寫的 Java 程序沒有作任何改變，僅僅是經過 JVM 這一 「中間層」 ，就能在不一樣平臺上運行，真正實現了 「一次編譯，處處運行」 的目的。

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++ 實現的本地方法的代碼返回結果

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 時須要通過的步驟：

第一個階段是找到 .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初始化步驟

• 一、假如這個類尚未被加載和鏈接，則程序先加載並鏈接該類
• 二、假如該類的直接父類尚未被初始化，則先初始化其直接父類
• 三、假如類中有初始化語句，則系統依次執行這些初始化語句

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

• 建立類的實例，也就是new的方式
• 訪問某個類或接口的靜態變量，或者對該靜態變量賦值
• 調用類的靜態方法
• 反射（如 Class.forName(「com.shengsiyuan.Test」)）
• 初始化某個類的子類，則其父類也會被初始化
• Java虛擬機啓動時被標明爲啓動類的類（ JavaTest），直接使用 java.exe命令來運行某個主類

結束生命週期

在以下幾種狀況下，Java虛擬機將結束生命週期

• 執行了 System.exit()方法
• 程序正常執行結束
• 程序在執行過程當中遇到了異常或錯誤而異常終止
• 因爲操做系統出現錯誤而致使Java虛擬機進程終止

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

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

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

答：類加載器 ClassLoader 是具備層次結構的，也就是父子關係，其中，Bootstrap 是全部類加載器的父親，以下圖所示：

該模型要求除了頂層的 Bootstrap class loader 啓動類加載器外，其他的類加載器都應當有本身的父類加載器。子類加載器和父類加載器不是以繼承（Inheritance）的關係來實現，而是經過組合（Composition）關係來複用父加載器的代碼。每一個類加載器都有本身的命名空間（由該加載器及全部父類加載器所加載的類組成，在同一個命名空間中，不會出現類的完整名字（包括類的包名）相同的兩個類；在不一樣的命名空間中，有可能會出現類的完整名字（包括類的包名）相同的兩個類）

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

答：

1.當前 ClassLoader 首先從本身已經加載的類中查詢是否此類已經加載，若是已經加載則直接返回原來已經加載的類。

每一個類加載器都有本身的加載緩存，當一個類被加載了之後就會放入緩存，
等下次加載的時候就能夠直接返回了。

2.當前 ClassLoader 的緩存中沒有找到被加載的類的時候，委託父類加載器去加載，父類加載器採用一樣的策略，首先查看本身的緩存，而後委託父類的父類去加載，一直到 bootstrap ClassLoader.

當全部的父類加載器都沒有加載的時候，再由當前的類加載器加載，並將其放入它本身的緩存中，以便下次有加載請求的時候直接返回。

面試官：爲何這樣設計呢？

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

答：主要是爲了安全性，避免用戶本身編寫的類動態替換 Java 的一些核心類，好比 String，同時也避免了重複加載，由於 JVM 中區分不一樣類，不只僅是根據類名，相同的 class 文件被不一樣的 ClassLoader 加載就是不一樣的兩個類，若是相互轉型的話會拋java.lang.ClassCaseException.

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

---

（二）JVM 內存管理

1）JVM 內存劃分：

答：

1. 方法區（線程共享）：各個線程共享的一個區域，用於存儲虛擬機加載的類信息、常量、靜態變量、即時編譯器編譯後的代碼等數據。雖然 Java 虛擬機規範把方法區描述爲堆的一個邏輯部分，可是它卻又一個別名叫作 Non-Heap（非堆），目的應該是與 Java 堆區分開來。

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

1. 堆內存（線程共享）：全部線程共享的一塊區域，垃圾收集器管理的主要區域。目前主要的垃圾回收算法都是分代收集算法，因此 Java 堆中還能夠細分爲：新生代和老年代；再細緻一點的有 Eden 空間、From Survivor 空間、To Survivor 空間等，默認狀況下新生代按照8:1:1的比例來分配。根據 Java 虛擬機規範的規定，Java 堆能夠處於物理上不連續的內存空間中，只要邏輯上是連續的便可，就像咱們的磁盤同樣。

2. 程序計數器： Java 線程私有，相似於操做系統裏的 PC 計數器，它能夠看作是當前線程所執行的字節碼的行號指示器。若是線程正在執行的是一個 Java 方法，這個計數器記錄的是正在執行的虛擬機字節碼指令的地址；若是正在執行的是 Native 方法，這個計數器值則爲空（Undefined）。此內存區域是惟一一個在 Java 虛擬機規範中沒有規定任何 OutOfMemoryError 狀況的區域。

3. 虛擬機棧（棧內存）：Java線程私有，虛擬機展描述的是Java方法執行的內存模型：每一個方法在執行的時候，都會建立一個棧幀用於存儲局部變量、操做數、動態連接、方法出口等信息；每一個方法調用都意味着一個棧幀在虛擬機棧中入棧到出棧的過程；

4. 本地方法棧 ：和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 的內存模型：

答：

Java 虛擬機規範中試圖定義一種 Java 內存模型（Java Memory Model, JMM）來屏蔽掉各層硬件和操做系統的內存訪問差別，以實現讓 Java 程序在各類平臺下都能達到一致的內存訪問效果。

Java 內存模型規定了全部的變量都存儲在主內存（Main Memory）中。每條線程還有本身的工做內存（Working Memory），線程的工做內存中保存了被該線程使用到的變量的主內存副本拷貝，線程對變量的全部操做（讀取、賦值等）都必須在主內存中進行，而不能直接讀寫主內存中的變量。不一樣的線程之間也沒法直接訪問對方工做內存中的變量，線程間的變量值的傳遞均須要經過主內存來完成，線程、主內存、工做內存三者的關係如上圖。

面試官：兩個線程之間是如何通訊的呢？

答：在共享內存的併發模型裏，線程之間共享程序的公共狀態，線程之間經過寫-讀內存中的公共狀態來隱式進行通訊，典型的共享內存通訊方式就是經過共享對象進行通訊。

例如上圖線程 A 與 線程 B 之間若是要通訊的話，那麼就必須經歷下面兩個步驟：

• 1.首先，線程 A 把本地內存 A 更新過得共享變量刷新到主內存中去
• 2.而後，線程 B 到主內存中去讀取線程 A 以前更新過的共享變量

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

5）內存屏障？

解析：在這以前應該對重排序的問題有所瞭解，這裏我找到一篇很好的文章分享一下：Java內存訪問重排序的研究

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

面試官：內存屏障爲什麼重要？

答：對主存的一次訪問通常花費硬件的數百次時鐘週期。處理器經過緩存（caching）可以從數量級上下降內存延遲的成本這些緩存爲了性能從新排列待定內存操 做的順序。也就是說，程序的讀寫操做不必定會按照它要求處理器的順序執行。當數據是不可變的，同時/或者數據限制在線程範圍內，這些優化是無害的。若是把 這些優化與對稱多處理（symmetric multi-processing）和共享可變狀態（shared mutable state）結合，那麼就是一場噩夢。當基於共享可變狀態的內存操做被從新排序時，程序可能行爲不定。一個線程寫入的數據可能被其餘線程可見，緣由是數據 寫入的順序不一致。適當的放置內存屏障經過強制處理器順序執行待定的內存操做來避免這個問題。

5）相似-Xms、-Xmn這些參數的含義：

答：

堆內存分配：

1. JVM初始分配的內存由-Xms指定，默認是物理內存的1/64
2. JVM最大分配的內存由-Xmx指定，默認是物理內存的1/4
3. 默認空餘堆內存小於40%時，JVM就會增大堆直到-Xmx的最大限制；空餘堆內存大於70%時，JVM會減小堆直到 -Xms的最小限制。
4. 所以服務器通常設置-Xms、-Xmx相等以免在每次GC 後調整堆的大小。對象的堆內存由稱爲垃圾回收器的自動內存管理系統回收。

非堆內存分配：

1. JVM使用-XX:PermSize設置非堆內存初始值，默認是物理內存的1/64；
2. 由XX:MaxPermSize設置最大非堆內存的大小，默認是物理內存的1/4。
3. -Xmn2G：設置年輕代大小爲2G。
4. -XX:SurvivorRatio，設置年輕代中Eden區與Survivor區的比值。

6）內存泄漏和內存溢出

答：

概念：

1. 內存溢出指的是內存不夠用了。
2. 內存泄漏是指對象可達，可是沒用了。即本該被GC回收的對象並無被回收
3. 內存泄露是致使內存溢出的緣由之一；內存泄露積累起來將致使內存溢出。

內存泄漏的緣由分析：

1. 長生命週期的對象引用短生命週期的對象
2. 沒有將無用對象置爲null

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

7）簡述一下 Java 中建立一個對象的過程？

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

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

Java中對象的建立就是在堆上分配內存空間的過程，此處說的對象建立僅限於new關鍵字建立的普通Java對象，不包括數組對象的建立。

大體過程以下：

1.檢測類是否被加載：

當虛擬機執行到new時，會先去常量池中查找這個類的符號引用。若是能找到符號引用，說明此類已經被加載到方法區（方法區存儲虛擬機已經加載的類的信息），能夠繼續執行；若是找不到符號引用，就會使用類加載器執行類的加載過程，類加載完成後繼續執行。

2.爲對象分配內存：

類加載完成之後，虛擬機就開始爲對象分配內存，此時所需內存的大小就已經肯定了。只須要在堆上分配所須要的內存便可。

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

• 對於內存絕對規整的狀況相對簡單一些，虛擬機只須要在被佔用的內存和可用空間之間移動指針便可，這種方式被稱爲指針碰撞。
• 對於內存不規整的狀況稍微複雜一點，這時候虛擬機須要維護一個列表，來記錄哪些內存是可用的。分配內存的時候須要找到一個可用的內存空間，而後在列表上記錄下已被分配，這種方式成爲空閒列表。

分配內存的時候也須要考慮線程安全問題，有兩種解決方案：

• 第一種是採用同步的辦法，使用CAS來保證操做的原子性。
• 另外一種是每一個線程分配內存都在本身的空間內進行，便是每一個線程都在堆中預先分配一小塊內存，稱爲本地線程分配緩衝（TLAB），分配內存的時候再TLAB上分配，互不干擾。

3.爲分配的內存空間初始化零值：

對象的內存分配完成後，還須要將對象的內存空間都初始化爲零值，這樣能保證對象即便沒有賦初值，也能夠直接使用。

4.對對象進行其餘設置：

分配完內存空間，初始化零值以後，虛擬機還須要對對象進行其餘必要的設置，設置的地方都在對象頭中，包括這個對象所屬的類，類的元數據信息，對象的hashcode，GC分代年齡等信息。

5.執行 init 方法：

執行完上面的步驟以後，在虛擬機裏這個對象就算建立成功了，可是對於Java程序來講還須要執行init方法纔算真正的建立完成，由於這個時候對象只是被初始化零值了，尚未真正的去根據程序中的代碼分配初始值，調用了init方法以後，這個對象才真正能使用。

到此爲止一個對象就產生了，這就是new關鍵字建立對象的過程。過程以下：

參考文章：Java建立對象的過程簡介

面試官：對象的內存佈局是怎樣的？

答：對象的內存佈局包括三個部分：對象頭，實例數據和對齊填充。

• 對象頭：對象頭包括兩部分信息，第一部分是存儲對象自身的運行時數據，如哈希碼，GC分代年齡，鎖狀態標誌，線程持有的鎖等等。第二部分是類型指針，即對象指向類元數據的指針。

• 實例數據：就是數據啦

• 對齊填充：不是必然的存在，就是爲了對齊的嘛

面試官：對象是如何定位訪問的？

答：對象的訪問定位有兩種：句柄定位和直接指針

• 句柄定位：Java 堆會畫出一塊內存來做爲句柄池，reference中存儲的就是對象的句柄地址，而句柄中包含了對象實例數據與類型數據各自的具體地址信息

• 直接指針訪問：java堆對象的不居中就必須考慮如何放置訪問類型數據的相關信息，而reference中存儲的直接就是對象地址

比較：使用直接指針就是速度快，使用句柄reference指向穩定的句柄，對象被移動改變的也只是句柄中實例數據的指針，而reference自己並不須要修改。

參考文章：JAVA對象建立的過程

---

（三）GC 相關

1）如何判斷一個對象是否已經死去？

答：

1. 引用計數：每一個對象有一個引用計數屬性，新增一個引用時計數加1，引用釋放時計數減1，計數爲0時能夠回收。此方法簡單，沒法解決對象相互循環引用的問題。

2. 可達性分析（Reachability Analysis）：從GC Roots開始向下搜索，搜索所走過的路徑稱爲引用鏈。當一個對象到GC Roots沒有任何引用鏈相連時，則證實此對象是不可用的。不可達對象。

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

答：

1. 引用計數：
   原理是此對象有一個引用，即增長一個計數，刪除一個引用則減小一個計數。垃圾回收時，只用收集計數爲0的對象。此算法最致命的是沒法處理循環引用的問題。

2. 標記-清除：
   此算法執行分兩階段。第一階段從引用根節點開始標記全部被引用的對象，第二階段遍歷整個堆，把未標記的對象清除。此算法須要暫停整個應用，同時，會產生內存碎片。

1. 複製算法：
   此算法把內存空間劃爲兩個相等的區域，每次只使用其中一個區域。垃圾回收時，遍歷當前使用區域，把正在使用中的對象複製到另一個區域中。此算法每次只處理正在使用中的對象，所以複製成本比較小，同時複製過去之後還能進行相應的內存整理，不會出現「碎片」問題。固然，此算法的缺點也是很明顯的，就是須要兩倍內存空間。

1. 標記-整理：
   此算法結合了 「標記-清除」 和 「複製」 兩個算法的優勢。也是分兩階段，第一階段從根節點開始標記全部被引用對象，第二階段遍歷整個堆，把清除未標記對象而且把存活對象「壓縮」到堆的其中一塊，按順序排放。此算法避免了 「標記-清除」 的碎片問題，同時也避免了 「複製」 算法的空間問題。

1. 分代收集算法：

• 分代收集算法並無提出新的思想，只是根據對象存活週期的不一樣將內存劃爲幾塊。通常Java堆分爲新生代和老年代，這樣就能夠根據各個年代的特色採用適當的收集算法。
• 在新生袋中每次垃圾手機時都會由大批對象死去，只有少許存活，那就用複製算法，只須要付出少許存活對象的複製成本就能夠。老年代中對象存活率高、沒有額外擔保，因此必須使用「標記-清理」或者「標記整理算法。

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

3）GC何時開始？

答：GC常常發生的區域是堆區，堆區還能夠細分爲新生代、老年代，新生代還分爲一個Eden區和兩個Survivor區。

1. 對象優先在Eden中分配，當Eden中沒有足夠空間時，虛擬機將發生一次Minor GC，由於Java大多數對象都是朝生夕滅，因此Minor GC很是頻繁，並且速度也很快；

2. Full GC，發生在老年代的GC，當老年代沒有足夠的空間時即發生Full GC，發生Full GC通常都會有一次Minor GC。大對象直接進入老年代，如很長的字符串數組，虛擬機提供一個-XX:PretenureSizeThreadhold參數，令大於這個參數值的對象直接在老年代中分配，避免在Eden區和兩個Survivor區發生大量的內存拷貝；

3. 發生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 串行收集器

2.ParNew 收集器

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

參數控制：

-XX:+UseParNewGC ParNew收集器
-XX:ParallelGCThreads 限制線程數量

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數量）

6.G1收集器

G1是目前技術發展的最前沿成果之一，HotSpot開發團隊賦予它的使命是將來能夠替換掉JDK1.5中發佈的CMS收集器。與CMS收集器相比G1收集器有如下特色：

1. 空間整合，G1收集器採用標記整理算法，不會產生內存空間碎片。分配大對象時不會由於沒法找到連續空間而提早觸發下一次GC。

2. 可預測停頓，這是G1的另外一大優點，下降停頓時間是G1和CMS的共同關注點，但G1除了追求低停頓外，還能創建可預測的停頓時間模型，能讓使用者明確指定在一個長度爲N毫秒的時間片斷內，消耗在垃圾收集上的時間不得超過N毫秒，這幾乎已是實時Java（RTSJ）的垃圾收集器的特徵了。

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

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

收集步驟：

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

二、Root Region Scanning，程序運行過程當中會回收survivor區(存活到老年代)，這一過程必須在young GC以前完成。

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

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

五、Copy/Clean up，多線程清除失活對象，會有STW。G1將回收區域的存活對象拷貝到新區域，清除Remember Sets，併發清空回收區域並把它返回到空閒區域鏈表中。

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

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

---

（四）其餘 JVM 相關面試題整理

1）64 位 JVM 中，int 的長度是多數？

答：Java 中，int 類型變量的長度是一個固定值，與平臺無關，都是 32 位或者 4 個字節。意思就是說，在 32 位 和 64 位 的Java 虛擬機中，int 類型的長度是相同的。

2）怎樣經過 Java 程序來判斷 JVM 是 32 位 仍是 64 位？

答：Sun有一個Java System屬性來肯定JVM的位數：32或64：

sun.arch.data.model=32 // 32 bit JVM sun.arch.data.model=64 // 64 bit JVM

我可使用如下語句來肯定 JVM 是 32 位仍是 64 位：

System.getProperty("sun.arch.data.model") 

3）32 位 JVM 和 64 位 JVM 的最大堆內存分別是多數？

答：理論上說上 32 位的 JVM 堆內存能夠到達 2^32，即 4GB，但實際上會比這個小不少。不一樣操做系統之間不一樣，如 Windows 系統大約 1.5 GB，Solaris 大約 3GB。64 位 JVM容許指定最大的堆內存，理論上能夠達到 2^64，這是一個很是大的數字，實際上你能夠指定堆內存大小到 100GB。甚至有的 JVM，如 Azul，堆內存到 1000G 都是可能的。

4）你能保證 GC 執行嗎？

答：不能，雖然你能夠調用 System.gc() 或者 Runtime.gc()，可是沒有辦法保證 GC 的執行。

5）怎麼獲取 Java 程序使用的內存？堆使用的百分比？

答：能夠經過 java.lang.Runtime 類中與內存相關方法來獲取剩餘的內存，總內存及最大堆內存。經過這些方法你也能夠獲取到堆使用的百分比及堆內存的剩餘空間。Runtime.freeMemory() 方法返回剩餘空間的字節數，Runtime.totalMemory() 方法總內存的字節數，Runtime.maxMemory() 返回最大內存的字節數。

6）Java 中堆和棧有什麼區別？

答：JVM 中堆和棧屬於不一樣的內存區域，使用目的也不一樣。棧經常使用於保存方法幀和局部變量，而對象老是在堆上分配。棧一般都比堆小，也不會在多個線程之間共享，而堆被整個 JVM 的全部線程共享。

 轉自：http://www.cnblogs.com/wmyskxz/p/9045972.html