在閱讀本文之前，先向大家強烈推薦一下週志明的《深入理解 Java 虛擬機器》這本書。

前些天面試了阿里的實習生，問到關於 Dalvik 虛擬機器能不能執行 class 檔案，我當時的回答是不能，但是它執行的是 class 轉換的 dex 檔案。當面試官繼續問，為什麼不能執行 class 檔案時，我卻只能回答 Dalvik 虛擬機器內部的優化原因，卻不能正確回答具體的原因。其實周志明的這本書就有回答：Dakvik 並不是一個 Java 虛擬機器，它沒有遵循 Java 虛擬機器規範，不能執行 Java 的 class 檔案，使用的是暫存器架構而不是 JVM 中常見的棧架構，但是它與 Java 又有著千絲萬縷的關係，它執行的 dex 檔案可以通過 class 檔案轉化而來。

其實在本科期間，就有接觸過《深入理解 Java 虛擬機器》，但是一直以來都沒去仔細研讀，現在回頭想想實在是覺得可惜！研一期間花了不少時間研讀，現在準備找工作了，發現好多內容看了又忘。索性寫一篇文章，把這本書的知識點做一個總結。當然了，如果你想看比較詳細的內容，可以翻看《深入理解 Java 虛擬機器》。

JVM 記憶體區域 我們在編寫程式時，經常會遇到 OOM（out of Memory）以及記憶體洩漏等問題。為了避免出現這些問題，我們首先必須對 JVM 的記憶體劃分有個具體的認識。JVM 將記憶體主要劃分為：方法區、虛擬機器棧、本地方法棧、堆、程式計數器。JVM 執行時資料區如下：

程式計數器 程式計數器是執行緒私有的區域，很好理解嘛~，每個執行緒當然得有個計數器記錄當前執行到那個指令。佔用的記憶體空間小，可以把它看成是當前執行緒所執行的位元組碼的行號指示器。如果執行緒在執行 Java 方法，這個計數器記錄的是正在執行的虛擬機器位元組碼指令地址；如果執行的是 Native 方法，這個計數器的值為空（Undefined）。此記憶體區域是唯一一個在 Java 虛擬機器規範中沒有規定任何 OutOfMemoryError 情況的區域。

Java 虛擬機器棧 與程式計數器一樣，Java 虛擬機器棧也是執行緒私有的。其生命週期與執行緒相同。如何理解虛擬機器棧呢？本質上來講，就是個棧。裡面存放的元素叫棧幀，棧幀好像很複雜的樣子，其實它很簡單！它裡面存放的是一個函式的上下文，具體存放的是執行的函式的一些資料。執行的函式需要的資料無非就是區域性變量表（儲存函式內部的變數）、運算元棧（執行引擎計算時需要），方法出口等等。

執行引擎每呼叫一個函式時，就為這個函式建立一個棧幀，並加入虛擬機器棧。換個角度理解，每個函式從呼叫到執行結束，其實是對應一個棧幀的入棧和出棧。

注意這個區域可能出現的兩種異常：一種是 StackOverflowError，當前執行緒請求的棧深度大於虛擬機器所允許的深度時，會丟擲這個異常。製造這種異常很簡單：將一個函式反覆遞迴自己，最終會出現棧溢位錯誤（StackOverflowError）。另一種異常是 OutOfMemoryError 異常，當虛擬機器棧可以動態擴充套件時（當前大部分虛擬機器都可以），如果無法申請足夠多的記憶體就會丟擲 OutOfMemoryError，如何製作虛擬機器棧 OOM 呢，參考一下程式碼：

本地方法棧 本地方法棧與虛擬機器棧所發揮的作用很相似，他們的區別在於虛擬機器棧為執行 Java 程式碼方法服務，而本地方法棧是為 Native 方法服務。與虛擬機器棧一樣，本地方法棧也會丟擲 StackOverflowError 和 OutOfMemoryError 異常。

Java 堆 Java 堆可以說是虛擬機器中最大一塊記憶體了。它是所有執行緒所共享的記憶體區域，幾乎所有的例項物件都是在這塊區域中存放。當然，睡著 JIT 編譯器的發展，所有物件在堆上分配漸漸變得不那麼 “絕對” 了。

Java 堆是垃圾收集器管理的主要區域。由於現在的收集器基本上採用的都是分代收集演算法，所有 Java 堆可以細分為：新生代和老年代。在細緻分就是把新生代分為：Eden 空間、From Survivor 空間、To Survivor 空間。當堆無法再擴充套件時，會丟擲 OutOfMemoryError 異常。

方法區 方法區存放的是類資訊、常量、靜態變數等。方法區是各個執行緒共享區域，很容易理解，我們在寫 Java 程式碼時，每個執行緒度可以訪問同一個類的靜態變數物件。由於使用反射機制的原因，虛擬機器很難推測那個類資訊不再使用，因此這塊區域的回收很難。另外，對這塊區域主要是針對常量池回收，值得注意的是 JDK1.7 已經把常量池轉移到堆裡面了。同樣，當方法區無法滿足記憶體分配需求時，會丟擲 OutOfMemoryError。 製造方法區記憶體溢位，注意，必須在 JDK1.6 及之前版本才會導致方法區溢位，原因後面解釋, 執行之前，可以把虛擬機器的引數 - XXpermSize 和 - XX：MaxPermSize 限制方法區大小。

執行後會丟擲java.lang.OutOfMemoryError:PermGen space異常。

解釋一下，String的intern()函式作用是如果當前的字串在常量池中不存在，則放入到常量池中。上面的程式碼不斷將字串新增到常量池，最終肯定會導致記憶體不足，丟擲方法區的 OOM。

下面解釋一下，為什麼必須將上面的程式碼在 JDK1.6 之前執行。我們前面提到，JDK1.7 後，把常量池放入到堆空間中，這導致intern()函式的功能不同，具體怎麼個不同法，且看看下面程式碼：

這段程式碼在 JDK1.6 和 JDK1.7 執行的結果不同。JDK1.6 結果是：false,false ，JDK1.7 結果是true, false。原因是：JDK1.6 中，intern()方法會吧首次遇到的字串例項複製到常量池中，返回的也是常量池中的字串的引用，而StringBuilder建立的字串例項是在堆上面，所以必然不是同一個引用，返回false。在 JDK1.7 中，intern不再複製例項，常量池中只儲存首次出現的例項的引用，因此intern()返回的引用和由StringBuilder建立的字串例項是同一個。為什麼對 str2 比較返回的是 false 呢？這是因為，JVM 中內部在載入類的時候，就已經有"java"這個字串，不符合 “首次出現” 的原則，因此返回false。

垃圾回收（GC JVM 的垃圾回收機制中，判斷一個物件是否死亡，並不是根據是否還有物件對其有引用，而是通過可達性分析。物件之間的引用可以抽象成樹形結構，通過樹根（GC Roots）作為起點，從這些樹根往下搜尋，搜尋走過的鏈稱為引用鏈，當一個物件到 GC Roots 沒有任何引用鏈相連時，則證明這個物件是不可用的，該物件會被判定為可回收的物件。

那麼那些物件可作為 GC Roots 呢？主要有以下幾種：

1. 虛擬機器棧（棧幀中的本地變量表）中引用的物件。 2. 方法區中類靜態屬性引用的物件。 3. 方法區中常量引用的物件 4. 本地方法棧中 JNI（即一般說的 Native 方法）引用的物件。

另外，Java 還提供了軟引用和弱引用，這兩個引用是可以隨時被虛擬機器回收的物件，我們將一些比較佔記憶體但是又可能後面用的物件，比如 Bitmap 物件，可以宣告為軟引用貨弱引用。但是注意一點，每次使用這個物件時候，需要顯示判斷一下是否為null，以免出錯。

三種常見的垃圾收集演算法

第一

標記 - 清除演算法 首先，通過可達性分析將可回收的物件進行標記，標記後再統一回收所有被標記的物件，標記過程其實就是可達性分析的過程。這種方法有 2 個不足點：效率問題，標記和清除兩個過程的效率都不高；另一個是空間問題，標記清除之後會產生大量的不連續的記憶體碎片。

第二

複製演算法 為了解決效率問題，複製演算法是將記憶體分為大小相同的兩塊，每次只使用其中一塊。當這塊記憶體用完了，就將還存活的物件複製到另一塊記憶體上面。然後再把已經使用過的記憶體一次清理掉。這使得每次只對半個區域進行垃圾回收，記憶體分配時也不用考慮記憶體碎片情況。

但是，這代價實在是讓人無法接受，需要犧牲一般的記憶體空間。研究發現，大部分物件都是 “朝生夕死”，所以不需要安裝 1:1 比例劃分記憶體空間，而是將記憶體分為一塊較大的 Eden 空間和兩塊較小的 Survivor 空間，每次使用 Eden 空間和一塊 Survivor 空間，預設比例為 Eden：Survivor=8:1. 新生代區域就是這麼劃分，每次例項在 Eden 和一塊 Survivor 中分配，回收時，將存活的物件複製到剩下的另一塊 Survivor。這樣只有 10% 的記憶體會被浪費，但是帶來的效率卻很高。當剩下的 Survivor 記憶體不足時，可以去老年代記憶體進行分配擔保。如何理解分配擔保呢，其實就是，記憶體不足時，去老年代記憶體空間分配，然後等新生代記憶體緩過來了之後，把記憶體歸還給老年代，保持新生代中的 Eden：Survivor=8:1. 另外，兩個 Survivor 分別有自己的名稱：From Survivor、To Survivor。二者身份經常調換，即有時這塊記憶體與 Eden 一起參與分配，有時是另一塊。因為他們之間經常相互複製。

第三

標記 - 整理演算法 標記整理演算法很簡單，就是先標記需要回收的物件，然後把所有存活的物件移動到記憶體的一端。這樣的好處是避免了記憶體碎片。

類載入機制 類從被載入到虛擬機器記憶體開始，到卸載出記憶體為止，整個生命週期包括：載入、驗證、準備、解析、初始化、使用和解除安裝七個階段。

其中載入、驗證、準備、初始化、和解除安裝這 5 個階段的順序是確定的。而解析階段不一定：它在某些情況下可以在初始化階段之後再開始，這是為了支援 Java 的執行時繫結。

關於初始化：JVM 規範明確規定，有且只有 5 中情況必須執行對類的初始化（載入、驗證、準備自然再此之前要發生）： 1. 遇到 new、getstatic、putstatic、invokestatic，如果類沒有初始化，則必須初始化，這幾條指令分別是指：new 新物件、讀取靜態變數、設定靜態變數，呼叫靜態函式。 2. 使用 java.lang.reflect 包的方法對類進行反射呼叫時，如果類沒初始化，則需要初始化 3. 當初始化一個類時，如果發現父類沒有初始化，則需要先觸發父類初始化。 4. 當虛擬機器啟動時，使用者需要制定一個執行的主類（包含 main 函式的類），虛擬機器會先初始化這個類。 5. 但是用 JDK1.7 啟的動態語言支援時，如果一個 MethodHandle 例項最後解析的結果是REF_getStatic、REF_putStatic、Ref_invokeStatic的方法控制代碼時，並且這個方法控制代碼所對應的類沒有進行初始化，則要先觸發其初始化。

另外要注意的是：通過子類來引用父類的靜態欄位，不會導致子類初始化：

最後只會列印：SuperClass init! 對應靜態變數，只有直接定義這個欄位的類才會被初始化，因此通過子類類引用父類中定義的靜態變數只會觸發父類初始化而不會觸發子類初始化。

通過陣列定義來引用類，不會觸發此類的初始化：

常量會在編譯階段存入呼叫者的常量池，本質上並沒有直接引用到定義常量的類，因此不會觸發定義常量的類初始化，示例程式碼如下：

上面程式碼不會出現 ConstClass init!

載入 載入過程主要做以下 3 件事 1. 通過一個類的全限定名稱來獲取此類的二進位制流 2. 強這個位元組流所代表的靜態儲存結構轉化為方法區的執行時資料結構 3. 在記憶體中生成一個代表這個類的 java.lang.Class 物件, 作為方法區這個類的各種資料訪問入口。

驗證 這個階段主要是為了確保 Class 檔案位元組流中包含資訊符合當前虛擬機器的要求，並且不會出現危害虛擬機器自身的安全。

準備 準備階段是正式為類變數分配記憶體並設定類變數初始值的階段，這些變數所使用的記憶體都在方法區中分配。首先，這個時候分配記憶體僅僅包括類變數（被 static 修飾的變數），而不包括例項變數。例項變數會在物件例項化時隨著物件一起分配在 java 堆中。其次這裡所說的初始值 “通常情況下” 是資料型別的零值，假設一個類變數定義為

public static int value=123;

那變數 value 在準備階段後的初始值是 0，而不是 123，因為還沒有執行任何 Java 方法，而把 value 賦值為 123 是在程式編譯後，存放在類建構函式<clinit>()方法中。

解析 解析階段是把虛擬機器中常量池的符號引用替換為直接引用的過程。

初始化 類初始化時類載入的最後一步，前面類載入過程中，除了載入階段使用者可以通過自定義類載入器參與以外，其餘動作都是虛擬機器主導和控制。到了初始化階段，才是真正執行類中定義 Java 程式程式碼。

準備階段中，變數已經賦過一次系統要求的初始值，而在初始化階段，根據程式設計師通過程式制定的主觀計劃初始化類變數。初始化過程其實是執行類構造器<clinit>()方法的過程。

<clinit>()方法是由編譯器自動收集類中所有類變數的賦值動作和靜態語句塊中的語句合併產生的。收集的順序是按照語句在原始檔中出現的順序。靜態語句塊中只能訪問定義在靜態語句塊之前的變數，定義在它之後的變數可以賦值，但不能訪問。如下所示：

<clinit>()方法與類建構函式（或者說例項構造器<init>()）不同，他不需要顯式地呼叫父類構造器，虛擬機器會保證子類的<clinit>()方法執行之前，父類的<clinit>()已經執行完畢。

類載入器 關於自定義類載入器，和雙親委派模型，這裡不再提，寫了幾個小時了，該洗洗睡了~

• 作者：huachao1001 連結：https://www.jianshu.com/p/864fc0a49bbb