Java進階開發面試，騰訊java社招面試流程

一、Java 虛拟機架構 (JVM Architecture)

在我看來，不管學習什麼樣的知識或技術，首先要做的就是從全局上去認識它，這樣才能避免盲人摸象，事倍功半的情況發生。既然要學習 JVM，就要先了解它的整體架構，于是我畫了個 JVM 架構圖來幫助大家認識它。

Java 虛拟機架構圖

對 JVM 還不太了解的同學第一次看到這張花裡胡哨的圖肯定會一臉懵逼，不用怕，其實我們隻需要重點了解并掌握其中一部分 (同時也是面試重點) 就好了，比如運作時資料區、垃圾收集器、記憶體配置設定政策和類加載機制等，類檔案結構也可以學習一下，其他的稍作了解即可。既然本篇文章是要帶領大家認識 JVM 架構的，那就先把圖中各個部分都介紹一下吧 (注：本文隻做介紹，讓各位先對 JVM 有個整體的認識，後續會做深入探讨)。

1.1 Class 檔案 (位元組碼檔案)

Java 之是以号稱“一次編寫，處處運作”，就是得益于虛拟機和 Class 檔案 (注：CLass 檔案、位元組碼檔案和類檔案是一個意思) 的組合機制。程式員并不需要自己去适配不同的作業系統，大家都知道我們平時編寫的 java 代碼在編譯成 Class 檔案後才能執行，而 Class 檔案可以在任何作業系統上的 JVM 上執行，這樣就做到了“平台無關性”。下面是一個最簡單的 HelloWorld 程式及其對應的 Class 檔案。

HelloWorld 程式及其編譯後的 Class 檔案

得益于 Class 檔案，JVM 還可以做到“語言無關性”，也就是說不隻有 Java 程式可以運作于 JVM 之上，很多其他語言例如最近在安卓開發者中大火的 Kotlin 語言，還有 Scala、Groovy 等語言也都是基于 JVM 平台的，這些語言的代碼都可以編譯成 Class 檔案，然後在 JVM 上運作。

JVM提供的平台無關性和語言無關性

1.2 類加載器子系統 (ClassLoader Subsystem)

要執行 Class 檔案就需要先将其加載進記憶體，這一工作正是由類加載器 (ClassLoader) 完成的，系統為我們提供了三種類加載器，分别是啟動類加載器 (Bootstrap ClassLoader)、擴充類加載器 (Extension ClassLoader) 和應用程式類加載器 (Application ClassLoader)，如果有必要，我們也可以加入自定義的類加載器。類加載過程如下：

類加載過程

類加載過程分為加載、連接配接和初始化三個階段，其中的連接配接階段又分為驗證、準備和解析三個階段 (詳細的類加載機制在後續文章中進行介紹)。

1.3 Java 虛拟機運作時資料區 (JVM Runtime Data Area)

這部分内容較多，放在本文第二部分單獨進行介紹。

1.4 執行引擎 (Execution Engine)

位元組碼被加載進運作時資料區後，執行引擎會進行讀取并執行，執行引擎主要包含以下子產品：

• 解釋器 (Interpreter)：相信大家很久以前就聽過“計算機隻認識0和1”這句話，時至今日，計算機依然隻認識0和1，是以任何程式設計語言的代碼最終都要轉化成機器碼 (二進制代碼)才能執行，Java 也不例外，而解釋器的工作正是将編譯得到的位元組碼再轉化成機器碼，然後才能執行。正因為如此，Java 才被稱為解釋型語言，也正是因為邊解釋邊執行的特點，Java 程式在執行時才會慢于 C++ 之類的編譯型語言。
• 即時編譯器 ，為了彌補解釋執行帶來的速度劣勢，JVM 引入了即時編譯器，它的作用就是把熱點代碼，比如重複調用的方法和循環代碼等，編譯成機器碼并存放在 code cache 中，這樣之後再用到這些代碼就不用重新解釋執行了，可以提高程式運作效率。
• 垃圾收集器 (Garbage Collector)：Java 程式員可以不用手動釋放記憶體，全是垃圾收集器的功勞，這也是 JVM 中尤其重要的内容，後續會有多篇文章對其進行介紹。

1.5 本地庫接口 (JNI，Java Native Interface)

如果你經常看 JDK 源碼的話，一定會注意到 native 這個關鍵詞，被它修飾的方法是沒有方法體的，是因為它調用了計算機本地的方法庫 (通常是 C 或 C++ 代碼)。JDK 源碼中有很多類的方法，特别是一些需要操作計算機硬體的方法，都調用了本地方法庫，畢竟與硬體打交道還是用 C 和 C++ 更友善，比如下面這些方法：

// 例一：這是 Thread 類中的 currentThread 方法，用于擷取目前正在執行的線程
public static native Thread currentThread();

// 例二：這是 FileInputStream 類中 open0 方法，用于打開指定檔案
private native void open0(String name) throws FileNotFoundException;
           

1.6 本地方法庫 (Native Method Library)

本地庫接口所調用的對象正是位于這個庫中，一般是位于計算機本地的 C 或 C++ 語言代碼。

二、Java 虛拟機運作時資料區

Java 虛拟機運作時資料區是我們需要重點了解并熟悉的部分，因為這與我們寫的程式息息相關，平時常見的 StackOverflowError 和 OutOfMemoryError 也幾乎都是來自這個區域。說“幾乎”是因為當本機直接記憶體不夠用時也會抛出 OutOfMemoryError。如下圖所示，程式計數器、Java 虛拟機棧和本地方法棧是線程私有的，堆和方法區是線程共享的，其中方法區又包含了運作時常量池。下面就對這個部分做個詳細的介紹吧 (注：本部分引用内容來自《深入了解Java虛拟機》)。

Java 虛拟機運作時資料區

2.1 程式計數器 (Program Counter Register)

怕有些小夥伴不清楚，提示一下：下面這樣的段落格式就是 Markdown 裡的引用格式，，一般用于引用他人的文章或别處的内容。

程式計數器(Program Counter Register)是一塊較小的記憶體空間，它可以看作是目前線程所執行的位元組碼的行号訓示器。在Java虛拟機的概念裡，位元組碼解釋器工作時就是通過改變這個計數器 的值來選取下一條需要執行的位元組碼指令，它是程式控制流的訓示器，分支、循環、跳轉、異常處理、線程恢複等基礎功能都需要依賴這個計數器來完成。

由于Java虛拟機的多線程是通過線程輪流切換、配置設定處理器執行時間的方式來實作的，在任何一個确定的時刻，一個處理器(對于多核處理器來說是一個核心)都隻會執行一條線程中的指令。是以，為了線程切換後能恢複到正确的執行位置，每條線程都需要有一個獨立的程式計數器，各條線程之間計數器互不影響，獨立存儲，我們稱這類記憶體區域為“線程私有”的記憶體。

如果線程正在執行的是一個Java方法，這個計數器記錄的是正在執行的虛拟機位元組碼指令的位址；如果正在執行的是本地 (Native) 方法，這個計數器值則應為空 (Undefined)。此記憶體區域是唯一一個在《Java虛拟機規範》中沒有規定任何 OutOfMemoryError 情況的區域。

這裡引用了《深入了解Java虛拟機》書中的内容，其實不難了解，程式計數器的作用就是儲存線程的執行狀态，引用部分的第三段中說“如果線程正在執行的是一個Java方法，這個計數器記錄的是正在執行的虛拟機位元組碼指令的位址”，這個位址就是位元組碼執行到的位置。我們平時說的 Java 多線程上下文切換就需要程式計數器的輔助，當 CPU 從一個線程切換到另一個線程時，要從程式計數器中讀取線程執行狀态進而恢複現場。後面又說“如果執行的是本地 (Native)方法，這個計數器值為空(Undefined)”，這是為何呢？是因為本地方法執行的是 C / C++ 代碼，在原生平台直接運作，也就不存在 Java 虛拟機的概念，自然也無法儲存位元組碼指令位址，此時要想記錄代碼運作狀态的話，隻能使用原生 CPU 的 PC 寄存器。

2.2 Java 虛拟機棧 (JVM Stacks)

與程式計數器一樣，Java虛拟機棧(Java Virtual Machine Stack)也是線程私有的，它的生命周期與線程相同。虛拟機棧描述的是 Java 方法執行的線程記憶體模型:每個方法被執行的時候，Java 虛拟機都 會同步建立一個棧幀(Stack Frame)用于存儲局部變量表、操作數棧、動态連接配接、方法出口等資訊。每一個方法被調用直至執行完畢的過程，就對應着一個棧幀在虛拟機棧中從入棧到出棧的過程。

局部變量表存放了編譯期可知的各種Java虛拟機基本資料類型(boolean、byte、char、short、int、 float、long、double)、對象引用 (reference 類型，它并不等同于對象本身，可能是一個指向對象起始位址的引用指針，也可能是指向一個代表對象的句柄或者其他與此對象相關的位置) 和 returnAddress 類型(指向了一條位元組碼指令的位址)。

這些資料類型在局部變量表中的存儲空間以局部變量槽 (Slot) 來表示，其中64位長度的 long 和 double 類型的資料會占用兩個變量槽，其餘的資料類型隻占用一個。局部變量表所需的記憶體空間在編譯期間完成配置設定，當進入一個方法時，這個方法需要在棧幀中配置設定多大的局部變量空間是完全确定的，在方法運作期間不會改變局部變量表的大小。請讀者注意，這裡說的“大小”是指變量槽的數量，虛拟機真正使用多大的記憶體空間 (譬如按照1個變量槽占用32個比特、64個比特，或者更多)來實作一個變量槽，這是完全由具體的虛拟機實作自行決定的事情。

在《Java虛拟機規範》中，對這個記憶體區域規定了兩類異常狀況：如果線程請求的棧深度大于虛拟機所允許的深度，将抛出 StackOverflowError 異常；如果 Java 虛拟機棧容量可以動态擴充，當棧擴充時無法申請到足夠的記憶體會抛出 OutOfMemoryError 異常。

Java 虛拟機棧的内部結構如下圖所示：

Java 虛拟機棧

2.2.1 局部變量表

局部變量表是存放方法參數和局部變量的區域。 局部變量沒有準備階段， 必須顯式初始化。如果是非靜态方法，則在 index[0] 位置上存儲的是方法所屬對象的執行個體引用，一個引用變量占 4 個位元組，随後存儲的是參數和局部變量。

2.2.2 操作數棧

操作數棧是個初始狀态為空的桶式結構棧。在方法執行過程中， 會有各種指令往棧中寫入和提取資訊。JVM 的執行引擎是基于棧的執行引擎，其中的棧指的就是操作數棧。位元組碼指令集的定義都是基于棧類型的，棧的深度在方法元資訊的 stack 屬性中。下面使用 i++ 和 ++i 的差別來幫助了解操作數棧：

i++ 和 ++i 的差別：

1. i++：從局部變量表取出 i 并壓入操作棧，然後對局部變量表中的 i 自增 1，将操作棧棧頂值取出使用，最後，使用棧頂值更新局部變量表，如此線程從操作棧讀到的是自增之前的值。
2. ++i：先對局部變量表的 i 自增 1，然後取出并壓入操作棧，再将操作棧棧頂值取出使用，最後，使用棧頂值更新局部變量表，線程從操作棧讀到的是自增之後的值。

之是以說 i++ 不是原子操作，即使使用 volatile 修飾也不是線程安全，就是因為，可能 i 被從局部變量表（記憶體）取出，壓入操作棧（寄存器），操作棧中自增，使用棧頂值更新局部變量表（寄存器更新寫入記憶體），其中分為 3 步，volatile 保證可見性，保證每次從局部變量表讀取的都是最新的值，但可能這 3 步可能被另一個線程的 3 步打斷，産生資料互相覆寫問題，進而導緻 i 的值比預期的小。

2.2.3 動态連接配接

每個棧幀中包含一個在常量池中對目前方法的引用， 目的是支援方法調用過程的動态連接配接。

2.2.4 方法出口

方法執行時有兩種退出情況：

1. 正常退出，即正常執行到任何方法的傳回位元組碼指令，如 RETURN、IRETURN、ARETURN 等；
2. 異常退出。

無論何種退出情況，都将傳回至方法目前被調用的位置。方法退出的過程相當于彈出目前棧幀，退出可能有三種方式：

1. 傳回值壓入上層調用棧幀。
2. 異常資訊抛給能夠處理的棧幀。
3. 程式計數器指向方法調用後的下一條指令。

2.3 本地方法棧 (Native Method Stacks)

本地方法棧與虛拟機棧所發揮的作用是非常相似的，其差別隻是虛拟機棧為虛拟機執行 Java 方法 (也就是位元組碼)服務，而本地方法棧則是為虛拟機使用到的本地 (Native) 方法服務。

《Java虛拟機規範》對本地方法棧中方法使用的語言、使用方式與資料結構并沒有任何強制規定，是以具體的虛拟機可以根據需要自由實作它，甚至有的Java虛拟機 (譬如Hot-Spot虛拟機)直接就把本地方法棧和虛拟機棧合二為一。與虛拟機棧一樣，本地方法棧也會在棧深度溢出或者棧擴充失 敗時分别抛出 StackOverflowError 和OutOfMemoryError 異常。

這部分比較好了解，就不做解析了。

2.4 Java 堆 (Heap)

對于Java應用程式來說，Java 堆 (Java Heap)是虛拟機所管理的記憶體中最大的一塊。Java 堆是被所有線程共享的一塊記憶體區域，在虛拟機啟動時建立。此記憶體區域的唯一目的就是存放對象執行個體，Java 世界裡“幾乎”所有的對象執行個體都在這裡配置設定記憶體。Java 堆是垃圾收集器管理的記憶體區域，是以也常被稱為“GC 堆”。

根據《Java虛拟機規範》的規定，Java堆可以處于實體上不連續的記憶體空間中，但在邏輯上它應該被視為連續的，這點就像我們用磁盤空間去存儲檔案一樣，并不要求每個檔案都連續存放。但對于大 對象(典型的如數組對象)，多數虛拟機實作出于實作簡單、存儲高效的考慮，很可能會要求連續的記憶體空間。

Java 堆既可以被實作成固定大小的，也可以是可擴充的，不過目前主流的Java虛拟機都是按照可擴充來實作的(通過參數-Xmx和-Xms設定)。如果在 Java 堆中沒有記憶體完成執行個體配置設定，并且堆也無法再擴充時，Java 虛拟機将會抛出 OutOfMemoryError 異常。

Java 堆的唯一作用就是存放對象執行個體，這也是垃圾收集器最關注的記憶體區域，因為大多數對象執行個體的存活時間都很短，比如在方法内部建立的執行個體在方法執行完之後就沒有存在價值了，是以這個區域的垃圾回收成本效益最高。關于垃圾回收的詳細内容，見後續文章。

2.5 方法區 (Method Area)

方法區 (Method Area)與 Java 堆一樣，是各個線程共享的記憶體區域，它用于存儲已被虛拟機加載 的類型資訊、常量、靜态變量、即時編譯器編譯後的代碼緩存等資料。雖然《Java虛拟機規範》中把方法區描述為堆的一個邏輯部分，但是它卻有一個别名叫作“非堆”(Non-Heap)，目的是與 Java 堆區分開來。

說到方法區，不得不提一下“永久代”這個概念，尤其是在JDK 8以前，許多 Java 程式員都習慣在 HotSpot 虛拟機上開發、部署程式，很多人都更願意把方法區稱呼為“永久代”(Permanent Generation)，或将兩者混為一談。本質上這兩者并不是等價的，因為僅僅是當時的 HotSpot 虛拟機設計團隊選擇把收集器的分代設計擴充至方法區，或者說使用永久代來實作方法區而已，這樣使得 HotSpot的垃圾收集器能夠像管理Java堆一樣管理這部分記憶體，省去專門為方法區編寫記憶體管理代碼的工作。但是對于其他虛拟機實作，譬如 BEA JRockit、IBM J9 等來說，是不存在永久代的概念的。原則上如何實作方法區屬于虛拟機實作細節，不受《Java虛拟機規範》管束，并不要求統一。但現在回頭來看，當年使用永久代來實作方法區的決定并不是一個好主意，這種設計導緻了 Java 應用更容易遇到 記憶體溢出的問題(永久代有-XX:M axPermSize 的上限，即使不設定也有預設大小，而 J9 和 JRockit 隻要沒有觸碰到程序可用記憶體的上限，例如32位系統中的4GB限制，就不會出問題 )，而且有極少數方法 (例如 String :: intern() ) 會因永久代的原因而導緻不同虛拟機下有不同的表現。當 Oracle 收購 BEA 獲得了 JRockit 的所有權後，準備把 JRockit 中的優秀功能，譬如 Java Mission Control 管理工具，移植到 HotSpot 虛拟機時，但因為兩者對方法區實作的差異而面臨諸多困難。考慮到 HotSpot 未來的發展，在 JDK 6 的 時候 HotSpot 開發團隊就有放棄永久代，逐漸改為采用本地記憶體 (Native Memory) 來實作方法區的計劃了，到了JDK 7 的 HotSpot，已經把原本放在永久代的字元串常量池、靜态變量等移出，而到了 JDK 8，終于完全廢棄了永久代的概念，改用與 JRockit、J9 一樣在本地記憶體中實作的元空間(Metaspace)來代替，把JDK 7中永久代還剩餘的内容(主要是類型資訊)全部移到元空間中。

《Java虛拟機規範》對方法區的限制是非常寬松的，除了和 Java 堆一樣不需要連續的記憶體和可以選擇固定大小或者可擴充外，甚至還可以選擇不實作垃圾收集。相對而言，垃圾收集行為在這個區域的确是比較少出現的，但并非資料進入了方法區就如永久代的名字一樣“永久”存在了。這區域的記憶體回收目标主要是針對常量池的回收和對類型的解除安裝，一般來說這個區域的回收效果比較難令人滿意，尤其是類型的解除安裝，條件相當苛刻，但是這部分區域的回收有時又确實是必要的。

根據《Java虛拟機規範》的規定，如果方法區無法滿足新的記憶體配置設定需求時，将抛出 OutOfMemoryError 異常。

這部分引用内容對方法區的介紹十分全面，切記不要将方法區和永久代混為一談，從JDK 8 以後已經沒有永久代的概念了。

2.6 運作時常量池 (Runtime Constant Pool)

運作時常量池 (Runtime Constant Pool) 是方法區的一部分。Class 檔案中除了有類的版本、字段、方法、接口等描述資訊外，還有一項資訊是常量池表 (Constant Pool Table)，用于存放編譯期生成的各種字面量與符号引用，這部分内容将在類加載後存放到方法區的運作時常量池中。

既然運作時常量池是方法區的一部分，自然受到方法區記憶體的限制，當常量池無法再申請到記憶體 時會抛出OutOfMemoryError異常。

常量池是為了避免頻繁的建立和銷毀對象而影響系統性能，其實作了對象的共享。

最後

如果大家需要這份清華大牛整理的進大廠必備的redis視訊、面試題和技術文檔的話，可以戳這裡即可免費擷取！

祝大家早日進入大廠，拿到滿意的薪資和職級~~~加油！！

感謝大家的支援！！

家需要這份清華大牛整理的進大廠必備的redis視訊、面試題和技術文檔的話，可以戳這裡即可免費擷取！**

祝大家早日進入大廠，拿到滿意的薪資和職級~~~加油！！

感謝大家的支援！！

[外鍊圖檔轉存中…(img-DNTCkdpk-1626928362988)]