當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

【2022】JVM常见面试真题详解

發(fā)布時間：2023/12/19 编程问答 31 豆豆

生活随笔收集整理的這篇文章主要介紹了【2022】JVM常见面试真题详解小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

文章目錄

- 5. JVM
- - - 5.1 JVM包含哪幾部分？
    - 5.2 JVM是如何運(yùn)行的？
    - 5.3 Java程序是怎么運(yùn)行的？
    - 5.4 本地方法棧有什么用？
    - 5.5 沒有程序計(jì)數(shù)器會怎么樣？
    - 5.6 說一說Java的內(nèi)存分布情況
    - 5.7 類存放在哪里？
    - 5.8 局部變量存放在哪里？
    - 5.9 介紹一下Java代碼的編譯過程
    - 5.10 介紹一下類加載的過程
    - 5.11 介紹一下對象的實(shí)例化過程
    - 5.12 元空間在棧內(nèi)還是棧外？
    - 5.13 談?wù)凧VM的類加載器，以及雙親委派模型
    - 5.14 雙親委派機(jī)制會被破壞嗎？
    - 5.15 介紹一下Java的垃圾回收機(jī)制
    - 5.16 請介紹一下分代回收機(jī)制
    - 5.17 JVM中一次完整的GC流程是怎樣的？
    - 5.18 Full GC會導(dǎo)致什么？
    - 5.19 JVM什么時候觸發(fā)GC，如何減少FullGC的次數(shù)？
    - 5.20 如何確定對象是可回收的？
    - 5.21 對象如何晉升到老年代？
    - 5.22 為什么老年代不能使用標(biāo)記復(fù)制？
    - 5.23 新生代為什么要分為Eden和Survivor，它們的比例是多少？
    - 5.24 為什么要設(shè)置兩個Survivor區(qū)域？
    - 5.25 說一說你對GC算法的了解。
    - 5.26 為什么新生代和老年代要采用不同的回收算法？
    - 5.27 請介紹G1垃圾收集器
    - 5.28 請介紹CMS垃圾收集器
    - 5.29 內(nèi)存泄漏和內(nèi)存溢出有什么區(qū)別？
    - 5.30 什么是內(nèi)存泄漏，怎么解決？
    - 5.31 什么是內(nèi)存溢出，怎么解決？
    - 5.32 哪些區(qū)域會OOM，怎么觸發(fā)OOM？
    - 5.32 哪些區(qū)域會OOM，怎么觸發(fā)OOM？

5. JVM

5.1 JVM包含哪幾部分？

參考答案

JVM 主要由四大部分組成：ClassLoader（類加載器），Runtime Data Area（運(yùn)行時數(shù)據(jù)區(qū)，內(nèi)存分區(qū)），Execution Engine（執(zhí)行引擎），Native Interface（本地庫接口），下圖可以大致描述 JVM 的結(jié)構(gòu)。

JVM 是執(zhí)行 Java 程序的虛擬計(jì)算機(jī)系統(tǒng)，那我們來看看執(zhí)行過程：首先需要準(zhǔn)備好編譯好的 Java 字節(jié)碼文件（即class文件），計(jì)算機(jī)要運(yùn)行程序需要先通過一定方式（類加載器）將 class 文件加載到內(nèi)存中（運(yùn)行時數(shù)據(jù)區(qū)），但是字節(jié)碼文件是JVM定義的一套指令集規(guī)范，并不能直接交給底層操作系統(tǒng)去執(zhí)行，因此需要特定的命令解釋器（執(zhí)行引擎）將字節(jié)碼翻譯成特定的操作系統(tǒng)指令集交給 CPU 去執(zhí)行，這個過程中會需要調(diào)用到一些不同語言為 Java 提供的接口（例如驅(qū)動、地圖制作等），這就用到了本地 Native 接口（本地庫接口）。

ClassLoader：負(fù)責(zé)加載字節(jié)碼文件即 class 文件，class 文件在文件開頭有特定的文件標(biāo)示，并且 ClassLoader 只負(fù)責(zé)class 文件的加載，至于它是否可以運(yùn)行，則由 Execution Engine 決定。
Runtime Data Area：是存放數(shù)據(jù)的，分為五部分：Stack（虛擬機(jī)棧），Heap（堆），Method Area（方法區(qū)），PC Register（程序計(jì)數(shù)器），Native Method Stack（本地方法棧）。幾乎所有的關(guān)于 Java 內(nèi)存方面的問題，都是集中在這塊。
Execution Engine：執(zhí)行引擎，也叫 Interpreter。Class 文件被加載后，會把指令和數(shù)據(jù)信息放入內(nèi)存中，Execution Engine 則負(fù)責(zé)把這些命令解釋給操作系統(tǒng)，即將 JVM 指令集翻譯為操作系統(tǒng)指令集。
Native Interface：負(fù)責(zé)調(diào)用本地接口的。他的作用是調(diào)用不同語言的接口給 JAVA 用，他會在 Native Method Stack 中記錄對應(yīng)的本地方法，然后調(diào)用該方法時就通過 Execution Engine 加載對應(yīng)的本地 lib。原本多用于一些專業(yè)領(lǐng)域，如JAVA驅(qū)動，地圖制作引擎等，現(xiàn)在關(guān)于這種本地方法接口的調(diào)用已經(jīng)被類似于Socket通信，WebService等方式取代。

5.2 JVM是如何運(yùn)行的？

參考答案

JVM的啟動過程分為如下四個步驟：

JVM的裝入環(huán)境和配置

java.exe負(fù)責(zé)查找JRE，并且它會按照如下的順序來選擇JRE：

自己目錄下的JRE；
父級目錄下的JRE；
查注冊中注冊的JRE。

裝載JVM

通過第一步找到JVM的路徑后，Java.exe通過LoadJavaVM來裝入JVM文件。LoadLibrary裝載JVM動態(tài)連接庫，然后把JVM中的到處函數(shù)JNI_CreateJavaVM和JNI_GetDefaultJavaVMIntArgs 掛接到InvocationFunction 變量的CreateJavaVM和GetDafaultJavaVMInitArgs 函數(shù)指針變量上。JVM的裝載工作完成。

初始化JVM，獲得本地調(diào)用接口

調(diào)用InvocationFunction -> CreateJavaVM，也就是JVM中JNI_CreateJavaVM方法獲得JNIEnv結(jié)構(gòu)的實(shí)例。

運(yùn)行Java程序

JVM運(yùn)行Java程序的方式有兩種：jar包與 class。

運(yùn)行jar 的時候，java.exe調(diào)用GetMainClassName函數(shù)，該函數(shù)先獲得JNIEnv實(shí)例然后調(diào)用JarFileJNIEnv類中g(shù)etManifest()，從其返回的Manifest對象中取getAttrebutes(“Main-Class”)的值，即jar 包中文件：META-INF/MANIFEST.MF指定的Main-Class的主類名作為運(yùn)行的主類。之后main函數(shù)會調(diào)用Java.c中LoadClass方法裝載該主類（使用JNIEnv實(shí)例的FindClass）。

運(yùn)行Class的時候，main函數(shù)直接調(diào)用Java.c中的LoadClass方法裝載該類。

5.3 Java程序是怎么運(yùn)行的？

參考答案

概括來說，寫好的 Java 源代碼文件經(jīng)過 Java 編譯器編譯成字節(jié)碼文件后，通過類加載器加載到內(nèi)存中，才能被實(shí)例化，然后到 Java 虛擬機(jī)中解釋執(zhí)行，最后通過操作系統(tǒng)操作 CPU 執(zhí)行獲取結(jié)果。如下圖：

5.4 本地方法棧有什么用？

參考答案

本地方法棧（Native Method Stacks）與虛擬機(jī)棧所發(fā)揮的作用是非常相似的，其區(qū)別只是虛擬機(jī)棧為虛擬機(jī)執(zhí)行Java方法（也就是字節(jié)碼）服務(wù)，而本地方法棧則是為虛擬機(jī)使用到的本地（Native）方法服務(wù)。

《Java虛擬機(jī)規(guī)范》對本地方法棧中方法使用的語言、使用方式與數(shù)據(jù)結(jié)構(gòu)并沒有任何強(qiáng)制規(guī)定，因此具體的虛擬機(jī)可以根據(jù)需要自由實(shí)現(xiàn)它，甚至有的Java虛擬機(jī)（譬如Hot-Spot虛擬機(jī)）直接就把本地方法棧和虛擬機(jī)棧合二為一。與虛擬機(jī)棧一樣，本地方法棧也會在棧深度溢出或者棧擴(kuò)展失敗時分別拋出StackOverflowError和OutOfMemoryError異常。

5.5 沒有程序計(jì)數(shù)器會怎么樣？

參考答案

沒有程序計(jì)數(shù)器，Java程序中的流程控制將無法得到正確的控制，多線程也無法正確的輪換。

擴(kuò)展閱讀

程序計(jì)數(shù)器（Program Counter Register）是一塊較小的內(nèi)存空間，它可以看作是當(dāng)前線程所執(zhí)行的字節(jié)碼的行號指示器。在Java虛擬機(jī)的概念模型里，字節(jié)碼解釋器工作時就是通過改變這個計(jì)數(shù)器的值來選取下一條需要執(zhí)行的字節(jié)碼指令，它是程序控制流的指示器，分支、循環(huán)、跳轉(zhuǎn)、異常處理、線程恢復(fù)等基礎(chǔ)功能都需要依賴這個計(jì)數(shù)器來完成。

由于Java虛擬機(jī)的多線程是通過線程輪流切換、分配處理器執(zhí)行時間的方式來實(shí)現(xiàn)的，在任何一個確定的時刻，一個處理器（對于多核處理器來說是一個內(nèi)核）都只會執(zhí)行一條線程中的指令。因此，為了線程切換后能恢復(fù)到正確的執(zhí)行位置，每條線程都需要有一個獨(dú)立的程序計(jì)數(shù)器，各條線程之間計(jì)數(shù)器互不影響，獨(dú)立存儲，我們稱這類內(nèi)存區(qū)域?yàn)椤熬€程私有”的內(nèi)存。

如果線程正在執(zhí)行的是一個Java方法，這個計(jì)數(shù)器記錄的是正在執(zhí)行的虛擬機(jī)字節(jié)碼指令的地址；如果正在執(zhí)行的是本地（Native）方法，這個計(jì)數(shù)器值則應(yīng)為空（Undefined）。此內(nèi)存區(qū)域是唯一一個在《Java虛擬機(jī)規(guī)范》中沒有規(guī)定任何OutOfMemoryError情況的區(qū)域。

5.6 說一說Java的內(nèi)存分布情況

參考答案

Java虛擬機(jī)在執(zhí)行Java程序的過程中會把它所管理的內(nèi)存劃分為若干個不同的數(shù)據(jù)區(qū)域。這些區(qū)域有各自的用途，以及創(chuàng)建和銷毀的時間，有的區(qū)域隨著虛擬機(jī)進(jìn)程的啟動而一直存在，有些區(qū)域則是依賴用戶線程的啟動和結(jié)束而建立和銷毀。根據(jù)《Java虛擬機(jī)規(guī)范》的規(guī)定，Java虛擬機(jī)所管理的內(nèi)存將會包括以下幾個運(yùn)行時數(shù)據(jù)區(qū)域。

程序計(jì)數(shù)器

Java虛擬機(jī)棧

與程序計(jì)數(shù)器一樣，Java虛擬機(jī)棧（Java Virtual Machine Stack）也是線程私有的，它的生命周期與線程相同。虛擬機(jī)棧描述的是Java方法執(zhí)行的線程內(nèi)存模型：每個方法被執(zhí)行的時候，Java虛擬機(jī)都會同步創(chuàng)建一個棧幀[插圖]（Stack Frame）用于存儲局部變量表、操作數(shù)棧、動態(tài)連接、方法出口等信息。每一個方法被調(diào)用直至執(zhí)行完畢的過程，就對應(yīng)著一個棧幀在虛擬機(jī)棧中從入棧到出棧的過程。

在《Java虛擬機(jī)規(guī)范》中，對這個內(nèi)存區(qū)域規(guī)定了兩類異常狀況：如果線程請求的棧深度大于虛擬機(jī)所允許的深度，將拋出StackOverflowError異常；如果Java虛擬機(jī)棧容量可以動態(tài)擴(kuò)展，當(dāng)棧擴(kuò)展時無法申請到足夠的內(nèi)存會拋出OutOfMemoryError異常。

本地方法棧

Java堆

對于Java應(yīng)用程序來說，Java堆（Java Heap）是虛擬機(jī)所管理的內(nèi)存中最大的一塊。Java堆是被所有線程共享的一塊內(nèi)存區(qū)域，在虛擬機(jī)啟動時創(chuàng)建。此內(nèi)存區(qū)域的唯一目的就是存放對象實(shí)例，Java世界里“幾乎”所有的對象實(shí)例都在這里分配內(nèi)存。在《Java虛擬機(jī)規(guī)范》中對Java堆的描述是：“所有的對象實(shí)例以及數(shù)組都應(yīng)當(dāng)在堆上分配”，而這里筆者寫的“幾乎”是指從實(shí)現(xiàn)角度來看，隨著Java語言的發(fā)展，現(xiàn)在已經(jīng)能看到些許跡象表明日后可能出現(xiàn)值類型的支持，即使只考慮現(xiàn)在，由于即時編譯技術(shù)的進(jìn)步，尤其是逃逸分析技術(shù)的日漸強(qiáng)大，棧上分配、標(biāo)量替換優(yōu)化手段已經(jīng)導(dǎo)致一些微妙的變化悄然發(fā)生，所以說Java對象實(shí)例都分配在堆上也漸漸變得不是那么絕對了。

根據(jù)《Java虛擬機(jī)規(guī)范》的規(guī)定，Java堆可以處于物理上不連續(xù)的內(nèi)存空間中，但在邏輯上它應(yīng)該被視為連續(xù)的，這點(diǎn)就像我們用磁盤空間去存儲文件一樣，并不要求每個文件都連續(xù)存放。但對于大對象（典型的如數(shù)組對象），多數(shù)虛擬機(jī)實(shí)現(xiàn)出于實(shí)現(xiàn)簡單、存儲高效的考慮，很可能會要求連續(xù)的內(nèi)存空間。

Java堆既可以被實(shí)現(xiàn)成固定大小的，也可以是可擴(kuò)展的，不過當(dāng)前主流的Java虛擬機(jī)都是按照可擴(kuò)展來實(shí)現(xiàn)的（通過參數(shù)-Xmx和-Xms設(shè)定）。如果在Java堆中沒有內(nèi)存完成實(shí)例分配，并且堆也無法再擴(kuò)展時，Java虛擬機(jī)將會拋出OutOfMemoryError異常。

方法區(qū)

方法區(qū)（Method Area）與Java堆一樣，是各個線程共享的內(nèi)存區(qū)域，它用于存儲已被虛擬機(jī)加載的類型信息、常量、靜態(tài)變量、即時編譯器編譯后的代碼緩存等數(shù)據(jù)。雖然《Java虛擬機(jī)規(guī)范》中把方法區(qū)描述為堆的一個邏輯部分，但是它卻有一個別名叫作“非堆”（Non-Heap），目的是與Java堆區(qū)分開來。

根據(jù)《Java虛擬機(jī)規(guī)范》的規(guī)定，如果方法區(qū)無法滿足新的內(nèi)存分配需求時，將拋出OutOfMemoryError異常。

運(yùn)行時常量池

運(yùn)行時常量池（Runtime Constant Pool）是方法區(qū)的一部分。Class文件中除了有類的版本、字段、方法、接口等描述信息外，還有一項(xiàng)信息是常量池表（Constant Pool Table），用于存放編譯期生成的各種字面量與符號引用，這部分內(nèi)容將在類加載后存放到方法區(qū)的運(yùn)行時常量池中。

既然運(yùn)行時常量池是方法區(qū)的一部分，自然受到方法區(qū)內(nèi)存的限制，當(dāng)常量池?zé)o法再申請到內(nèi)存時會拋出OutOfMemoryError異常。

直接內(nèi)存

直接內(nèi)存（Direct Memory）并不是虛擬機(jī)運(yùn)行時數(shù)據(jù)區(qū)的一部分，也不是《Java虛擬機(jī)規(guī)范》中定義的內(nèi)存區(qū)域。但是這部分內(nèi)存也被頻繁地使用，而且也可能導(dǎo)致OutOfMemoryError異常出現(xiàn)。

顯然，本機(jī)直接內(nèi)存的分配不會受到Java堆大小的限制，但是，既然是內(nèi)存，則肯定還是會受到本機(jī)總內(nèi)存（包括物理內(nèi)存、SWAP分區(qū)或者分頁文件）大小以及處理器尋址空間的限制，一般服務(wù)器管理員配置虛擬機(jī)參數(shù)時，會根據(jù)實(shí)際內(nèi)存去設(shè)置-Xmx等參數(shù)信息，但經(jīng)常忽略掉直接內(nèi)存，使得各個內(nèi)存區(qū)域總和大于物理內(nèi)存限制（包括物理的和操作系統(tǒng)級的限制），從而導(dǎo)致動態(tài)擴(kuò)展時出現(xiàn)OutOfMemoryError異常。

5.7 類存放在哪里？

參考答案

方法區(qū)（Method Area）與Java堆一樣，是各個線程共享的內(nèi)存區(qū)域，它用于存儲已被虛擬機(jī)加載的類型信息、常量、靜態(tài)變量、即時編譯器編譯后的代碼緩存等數(shù)據(jù)。雖然《Java虛擬機(jī)規(guī)范》中把方法區(qū)描述為堆的一個邏輯部分，但是它卻有一個別名叫作“非堆”（Non-Heap），目的是與Java堆區(qū)分開來。

5.8 局部變量存放在哪里？

參考答案

與程序計(jì)數(shù)器一樣，Java虛擬機(jī)棧（Java Virtual Machine Stack）也是線程私有的，它的生命周期與線程相同。虛擬機(jī)棧描述的是Java方法執(zhí)行的線程內(nèi)存模型：每個方法被執(zhí)行的時候，Java虛擬機(jī)都會同步創(chuàng)建一個棧幀（Stack Frame）用于存儲局部變量表、操作數(shù)棧、動態(tài)連接、方法出口等信息。每一個方法被調(diào)用直至執(zhí)行完畢的過程，就對應(yīng)著一個棧幀在虛擬機(jī)棧中從入棧到出棧的過程。

局部變量表存放了編譯期可知的各種Java虛擬機(jī)基本數(shù)據(jù)類型（boolean、byte、char、short、int、float、long、double）、對象引用（reference類型，它并不等同于對象本身，可能是一個指向?qū)ο笃鹗嫉刂返囊弥羔?#xff0c;也可能是指向一個代表對象的句柄或者其他與此對象相關(guān)的位置）和returnAddress類型（指向了一條字節(jié)碼指令的地址）。

5.9 介紹一下Java代碼的編譯過程

參考答案

從Javac代碼的總體結(jié)構(gòu)來看，編譯過程大致可以分為1個準(zhǔn)備過程和3個處理過程，它們分別如下所示。

準(zhǔn)備過程：初始化插入式注解處理器。

解析與填充符號表過程，包括：

詞法、語法分析，將源代碼的字符流轉(zhuǎn)變?yōu)闃?biāo)記集合，構(gòu)造出抽象語法樹。
填充符號表，產(chǎn)生符號地址和符號信息。

插入式注解處理器的注解處理過程：

在Javac源碼中，插入式注解處理器的初始化過程是在initPorcessAnnotations()方法中完成的，而它的執(zhí)行過程則是在processAnnotations()方法中完成。這個方法會判斷是否還有新的注解處理器需要執(zhí)行，如果有的話，通過JavacProcessing-Environment類的doProcessing()方法來生成一個新的JavaCompiler對象，對編譯的后續(xù)步驟進(jìn)行處理。

分析與字節(jié)碼生成過程，包括：

標(biāo)注檢查，對語法的靜態(tài)信息進(jìn)行檢查。
數(shù)據(jù)流及控制流分析，對程序動態(tài)運(yùn)行過程進(jìn)行檢查。
解語法糖，將簡化代碼編寫的語法糖還原為原有的形式。
字節(jié)碼生成，將前面各個步驟所生成的信息轉(zhuǎn)化成字節(jié)碼。

上述3個處理過程里，執(zhí)行插入式注解時又可能會產(chǎn)生新的符號，如果有新的符號產(chǎn)生，就必須轉(zhuǎn)回到之前的解析、填充符號表的過程中重新處理這些新符號，從總體來看，三者之間的關(guān)系與交互順序如圖所示。

5.10 介紹一下類加載的過程

參考答案

一個類型從被加載到虛擬機(jī)內(nèi)存中開始，到卸載出內(nèi)存為止，它的整個生命周期將會經(jīng)歷加載（Loading）、驗(yàn)證（Verification）、準(zhǔn)備（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸載（Unloading）七個階段，其中驗(yàn)證、準(zhǔn)備、解析三個部分統(tǒng)稱為連接（Linking）。這七個階段的發(fā)生順序如下圖所示。

在上述七個階段中，包括了類加載的全過程，即加載、驗(yàn)證、準(zhǔn)備、解析和初始化這五個階段。

一、加載

“加載”（Loading）階段是整個“類加載”（Class Loading）過程中的一個階段，在加載階段，Java虛擬機(jī)需要完成以下三件事情：

通過一個類的全限定名來獲取定義此類的二進(jìn)制字節(jié)流。

將這個字節(jié)流所代表的靜態(tài)存儲結(jié)構(gòu)轉(zhuǎn)化為方法區(qū)的運(yùn)行時數(shù)據(jù)結(jié)構(gòu)。

在內(nèi)存中生成一個代表這個類的java.lang.Class對象，作為方法區(qū)這個類的各種數(shù)據(jù)的訪問入口。

加載階段結(jié)束后，Java虛擬機(jī)外部的二進(jìn)制字節(jié)流就按照虛擬機(jī)所設(shè)定的格式存儲在方法區(qū)之中了，方法區(qū)中的數(shù)據(jù)存儲格式完全由虛擬機(jī)實(shí)現(xiàn)自行定義，《Java虛擬機(jī)規(guī)范》未規(guī)定此區(qū)域的具體數(shù)據(jù)結(jié)構(gòu)。類型數(shù)據(jù)妥善安置在方法區(qū)之后，會在Java堆內(nèi)存中實(shí)例化一個java.lang.Class類的對象，這個對象將作為程序訪問方法區(qū)中的類型數(shù)據(jù)的外部接口。

二、驗(yàn)證

驗(yàn)證是連接階段的第一步，這一階段的目的是確保Class文件的字節(jié)流中包含的信息符合《Java虛擬機(jī)規(guī)范》的全部約束要求，保證這些信息被當(dāng)作代碼運(yùn)行后不會危害虛擬機(jī)自身的安全。驗(yàn)證階段大致上會完成下面四個階段的檢驗(yàn)動作：文件格式驗(yàn)證、元數(shù)據(jù)驗(yàn)證、字節(jié)碼驗(yàn)證和符號引用驗(yàn)證。

文件格式驗(yàn)證：

第一階段要驗(yàn)證字節(jié)流是否符合Class文件格式的規(guī)范，并且能被當(dāng)前版本的虛擬機(jī)處理。

元數(shù)據(jù)驗(yàn)證：

第二階段是對字節(jié)碼描述的信息進(jìn)行語義分析，以保證其描述的信息符合《Java語言規(guī)范》的要求。

字節(jié)碼驗(yàn)證：

第三階段是通過數(shù)據(jù)流分析和控制流分析，確定程序語義是合法的、符合邏輯的。

符號引用驗(yàn)證：

符號引用驗(yàn)證可以看作是對類自身以外（常量池中的各種符號引用）的各類信息進(jìn)行匹配性校驗(yàn)，通俗來說就是，該類是否缺少或者被禁止訪問它依賴的某些外部類、方法、字段等資源。

三、準(zhǔn)備

準(zhǔn)備階段是正式為類中定義的變量（即靜態(tài)變量，被static修飾的變量）分配內(nèi)存并設(shè)置類變量初始值的階段。從概念上講，這些變量所使用的內(nèi)存都應(yīng)當(dāng)在方法區(qū)中進(jìn)行分配，但必須注意到方法區(qū)本身是一個邏輯上的區(qū)域，在JDK7及之前，HotSpot使用永久代來實(shí)現(xiàn)方法區(qū)時，實(shí)現(xiàn)是完全符合這種邏輯概念的。而在JDK 8及之后，類變量則會隨著Class對象一起存放在Java堆中，這時候“類變量在方法區(qū)”就完全是一種對邏輯概念的表述了。

四、解析

解析階段是Java虛擬機(jī)將常量池內(nèi)的符號引用替換為直接引用的過程，符號引用在Class文件中以CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等類型的常量出現(xiàn)，那解析階段中所說的直接引用與符號引用又有什么關(guān)聯(lián)呢？

符號引用（Symbolic References）：符號引用以一組符號來描述所引用的目標(biāo)，符號可以是任何形式的字面量，只要使用時能無歧義地定位到目標(biāo)即可。符號引用與虛擬機(jī)實(shí)現(xiàn)的內(nèi)存布局無關(guān)，引用的目標(biāo)并不一定是已經(jīng)加載到虛擬機(jī)內(nèi)存當(dāng)中的內(nèi)容。各種虛擬機(jī)實(shí)現(xiàn)的內(nèi)存布局可以各不相同，但是它們能接受的符號引用必須都是一致的，因?yàn)榉栆玫淖置媪啃问矫鞔_定義在《Java虛擬機(jī)規(guī)范》的Class文件格式中。

直接引用（Direct References）：直接引用是可以直接指向目標(biāo)的指針、相對偏移量或者是一個能間接定位到目標(biāo)的句柄。直接引用是和虛擬機(jī)實(shí)現(xiàn)的內(nèi)存布局直接相關(guān)的，同一個符號引用在不同虛擬機(jī)實(shí)例上翻譯出來的直接引用一般不會相同。如果有了直接引用，那引用的目標(biāo)必定已經(jīng)在虛擬機(jī)的內(nèi)存中存在。

五、初始化

類的初始化階段是類加載過程的最后一個步驟，之前介紹的幾個類加載的動作里，除了在加載階段用戶應(yīng)用程序可以通過自定義類加載器的方式局部參與外，其余動作都完全由Java虛擬機(jī)來主導(dǎo)控制。直到初始化階段，Java虛擬機(jī)才真正開始執(zhí)行類中編寫的Java程序代碼，將主導(dǎo)權(quán)移交給應(yīng)用程序。

進(jìn)行準(zhǔn)備階段時，變量已經(jīng)賦過一次系統(tǒng)要求的初始零值，而在初始化階段，則會根據(jù)程序員通過程序編碼制定的主觀計(jì)劃去初始化類變量和其他資源。我們也可以從另外一種更直接的形式來表達(dá)：初始化階段就是執(zhí)行類構(gòu)造器<clinit>()方法的過程。<clinit>()并不是程序員在Java代碼中直接編寫的方法，它是Javac編譯器的自動生成物。

5.11 介紹一下對象的實(shí)例化過程

參考答案

對象實(shí)例化過程，就是執(zhí)行類構(gòu)造函數(shù)對應(yīng)在字節(jié)碼文件中的<init>()方法(實(shí)例構(gòu)造器)，<init>()方法由非靜態(tài)變量、非靜態(tài)代碼塊以及對應(yīng)的構(gòu)造器組成。

<init>()方法可以重載多個，類有幾個構(gòu)造器就有幾個<init>()方法；
<init>()方法中的代碼執(zhí)行順序?yàn)?#xff1a;父類變量初始化、父類代碼塊、父類構(gòu)造器、子類變量初始化、子類代碼塊、子類構(gòu)造器。

靜態(tài)變量、靜態(tài)代碼塊、普通變量、普通代碼塊、構(gòu)造器的執(zhí)行順序如下圖：

具有父類的子類的實(shí)例化順序如下：

擴(kuò)展閱讀

Java是一門面向?qū)ο蟮木幊陶Z言，Java程序運(yùn)行過程中無時無刻都有對象被創(chuàng)建出來。在語言層面上，創(chuàng)建對象通常（例外：復(fù)制、反序列化）僅僅是一個new關(guān)鍵字而已，而在虛擬機(jī)中，對象（文中討論的對象限于普通Java對象，不包括數(shù)組和Class對象等）的創(chuàng)建又是怎樣一個過程呢？

當(dāng)Java虛擬機(jī)遇到一條字節(jié)碼new指令時，首先將去檢查這個指令的參數(shù)是否能在常量池中定位到一個類的符號引用，并且檢查這個符號引用代表的類是否已被加載、解析和初始化過。如果沒有，那必須先執(zhí)行相應(yīng)的類加載過程。

在類加載檢查通過后，接下來虛擬機(jī)將為新生對象分配內(nèi)存。對象所需內(nèi)存的大小在類加載完成后便可完全確定，為對象分配空間的任務(wù)實(shí)際上便等同于把一塊確定大小的內(nèi)存塊從Java堆中劃分出來。假設(shè)Java堆中內(nèi)存是絕對規(guī)整的，所有被使用過的內(nèi)存都被放在一邊，空閑的內(nèi)存被放在另一邊，中間放著一個指針作為分界點(diǎn)的指示器，那所分配內(nèi)存就僅僅是把那個指針向空閑空間方向挪動一段與對象大小相等的距離，這種分配方式稱為“指針碰撞”（Bump The Pointer）。但如果Java堆中的內(nèi)存并不是規(guī)整的，已被使用的內(nèi)存和空閑的內(nèi)存相互交錯在一起，那就沒有辦法簡單地進(jìn)行指針碰撞了，虛擬機(jī)就必須維護(hù)一個列表，記錄上哪些內(nèi)存塊是可用的，在分配的時候從列表中找到一塊足夠大的空間劃分給對象實(shí)例，并更新列表上的記錄，這種分配方式稱為“空閑列表”（Free List）。選擇哪種分配方式由Java堆是否規(guī)整決定，而Java堆是否規(guī)整又由所采用的垃圾收集器是否帶有空間壓縮整理（Compact）的能力決定。因此，當(dāng)使用Serial、ParNew等帶壓縮整理過程的收集器時，系統(tǒng)采用的分配算法是指針碰撞，既簡單又高效；而當(dāng)使用CMS這種基于清除（Sweep）算法的收集器時，理論上就只能采用較為復(fù)雜的空閑列表來分配內(nèi)存。

除如何劃分可用空間之外，還有另外一個需要考慮的問題：對象創(chuàng)建在虛擬機(jī)中是非常頻繁的行為，即使僅僅修改一個指針?biāo)赶虻奈恢?#xff0c;在并發(fā)情況下也并不是線程安全的，可能出現(xiàn)正在給對象A分配內(nèi)存，指針還沒來得及修改，對象B又同時使用了原來的指針來分配內(nèi)存的情況。解決這個問題有兩種可選方案：一種是對分配內(nèi)存空間的動作進(jìn)行同步處理——實(shí)際上虛擬機(jī)是采用CAS配上失敗重試的方式保證更新操作的原子性；另外一種是把內(nèi)存分配的動作按照線程劃分在不同的空間之中進(jìn)行，即每個線程在Java堆中預(yù)先分配一小塊內(nèi)存，稱為本地線程分配緩沖（Thread Local Allocation Buffer，TLAB），哪個線程要分配內(nèi)存，就在哪個線程的本地緩沖區(qū)中分配，只有本地緩沖區(qū)用完了，分配新的緩存區(qū)時才需要同步鎖定。虛擬機(jī)是否使用TLAB，可以通過-XX：+/-UseTLAB參數(shù)來設(shè)定。

內(nèi)存分配完成之后，虛擬機(jī)必須將分配到的內(nèi)存空間（但不包括對象頭）都初始化為零值，如果使用了TLAB的話，這一項(xiàng)工作也可以提前至TLAB分配時順便進(jìn)行。這步操作保證了對象的實(shí)例字段在Java代碼中可以不賦初始值就直接使用，使程序能訪問到這些字段的數(shù)據(jù)類型所對應(yīng)的零值。

接下來，Java虛擬機(jī)還要對對象進(jìn)行必要的設(shè)置，例如這個對象是哪個類的實(shí)例、如何才能找到類的元數(shù)據(jù)信息、對象的哈希碼（實(shí)際上對象的哈希碼會延后到真正調(diào)用Object::hashCode()方法時才計(jì)算）、對象的GC分代年齡等信息。這些信息存放在對象的對象頭（Object Header）之中。根據(jù)虛擬機(jī)當(dāng)前運(yùn)行狀態(tài)的不同，如是否啟用偏向鎖等，對象頭會有不同的設(shè)置方式。

在上面工作都完成之后，從虛擬機(jī)的視角來看，一個新的對象已經(jīng)產(chǎn)生了。但是從Java程序的視角看來，對象創(chuàng)建才剛剛開始——構(gòu)造函數(shù)，即Class文件中的<init>()方法還沒有執(zhí)行，所有的字段都為默認(rèn)的零值，對象需要的其他資源和狀態(tài)信息也還沒有按照預(yù)定的意圖構(gòu)造好。一般來說（由字節(jié)碼流中new指令后面是否跟隨invokespecial指令所決定，Java編譯器會在遇到new關(guān)鍵字的地方同時生成這兩條字節(jié)碼指令，但如果直接通過其他方式產(chǎn)生的則不一定如此），new指令之后會接著執(zhí)行<init>()方法，按照程序員的意愿對對象進(jìn)行初始化，這樣一個真正可用的對象才算完全被構(gòu)造出來。

5.12 元空間在棧內(nèi)還是棧外？

參考答案

在棧外，元空間占用的是本地內(nèi)存。

擴(kuò)展閱讀

許多Java程序員都習(xí)慣在HotSpot虛擬機(jī)上開發(fā)、部署程序，很多人都更愿意把方法區(qū)稱呼為“永久代“，或?qū)烧呋鞛橐徽劇１举|(zhì)上這兩者并不是等價的，因?yàn)閮H僅是當(dāng)時的HotSpot虛擬機(jī)設(shè)計(jì)團(tuán)隊(duì)選擇把收集器的分代設(shè)計(jì)擴(kuò)展至方法區(qū)，或者說使用永久代來實(shí)現(xiàn)方法區(qū)而已，這樣使得HotSpot的垃圾收集器能夠像管理Java堆一樣管理這部分內(nèi)存，省去專門為方法區(qū)編寫內(nèi)存管理代碼的工作。但是對于其他虛擬機(jī)實(shí)現(xiàn)，譬如BEAJRockit、IBM J9等來說，是不存在永久代的概念的。原則上如何實(shí)現(xiàn)方法區(qū)屬于虛擬機(jī)實(shí)現(xiàn)細(xì)節(jié)，不受《Java虛擬機(jī)規(guī)范》管束，并不要求統(tǒng)一。

現(xiàn)在回頭來看，當(dāng)年使用永久代來實(shí)現(xiàn)方法區(qū)的決定并不是一個好主意，這種設(shè)計(jì)導(dǎo)致了Java應(yīng)用更容易遇到內(nèi)存溢出的問題（永久代有-XX：MaxPermSize的上限，即使不設(shè)置也有默認(rèn)大小，而J9和JRockit只要沒有觸碰到進(jìn)程可用內(nèi)存的上限，例如32位系統(tǒng)中的4GB限制，就不會出問題），而且有極少數(shù)方法（例如String::intern()）會因永久代的原因而導(dǎo)致不同虛擬機(jī)下有不同的表現(xiàn)。

當(dāng)Oracle收購BEA獲得了JRockit的所有權(quán)后，準(zhǔn)備把JRockit中的優(yōu)秀功能，譬如Java Mission Control管理工具，移植到HotSpot虛擬機(jī)時，但因?yàn)閮烧邔Ψ椒▍^(qū)實(shí)現(xiàn)的差異而面臨諸多困難。考慮到HotSpot未來的發(fā)展，在JDK 6的時候HotSpot開發(fā)團(tuán)隊(duì)就有放棄永久代，逐步改為采用本地內(nèi)存（Native Memory）來實(shí)現(xiàn)方法區(qū)的計(jì)劃了，到了JDK 7的HotSpot，已經(jīng)把原本放在永久代的字符串常量池、靜態(tài)變量等移出，而到了JDK 8，終于完全廢棄了永久代的概念，改用與JRockit、J9一樣在本地內(nèi)存中實(shí)現(xiàn)的元空間（Meta-space）來代替，把JDK 7中永久代還剩余的內(nèi)容（主要是類型信息）全部移到元空間中。

5.13 談?wù)凧VM的類加載器，以及雙親委派模型

參考答案

一、類加載器

Java虛擬機(jī)設(shè)計(jì)團(tuán)隊(duì)有意把類加載階段中的“通過一個類的全限定名來獲取描述該類的二進(jìn)制字節(jié)流”這個動作放到Java虛擬機(jī)外部去實(shí)現(xiàn)，以便讓應(yīng)用程序自己決定如何去獲取所需的類。實(shí)現(xiàn)這個動作的代碼被稱為“類加載器”（Class Loader）。

類加載器雖然只用于實(shí)現(xiàn)類的加載動作，但它在Java程序中起到的作用卻遠(yuǎn)超類加載階段。對于任意一個類，都必須由加載它的類加載器和這個類本身一起共同確立其在Java虛擬機(jī)中的唯一性，每一個類加載器，都擁有一個獨(dú)立的類名稱空間。這句話可以表達(dá)得更通俗一些：比較兩個類是否“相等”，只有在這兩個類是由同一個類加載器加載的前提下才有意義，否則，即使這兩個類來源于同一個Class文件，被同一個Java虛擬機(jī)加載，只要加載它們的類加載器不同，那這兩個類就必定不相等。

二、雙親委派模型

自JDK1.2以來，Java一直保持著三層類加載器、雙親委派的類加載架構(gòu)。對于這個時期的Java應(yīng)用，絕大多數(shù)Java程序都會使用到以下3個系統(tǒng)提供的類加載器來進(jìn)行加載。

啟動類加載器（Bootstrap Class Loader）：這個類加載器負(fù)責(zé)加載存放在\lib目錄，或者被-Xbootclasspath參數(shù)所指定的路徑中存放的，而且是Java虛擬機(jī)能夠識別的（按照文件名識別，如rt.jar、tools.jar，名字不符合的類庫即使放在lib目錄中也不會被加載）類庫加載到虛擬機(jī)的內(nèi)存中。啟動類加載器無法被Java程序直接引用，用戶在編寫自定義類加載器時，如果需要把加載請求委派給引導(dǎo)類加載器去處理，那直接使用null代替即可。
擴(kuò)展類加載器（Extension Class Loader）：這個類加載器是在類sun.misc.Launcher$ExtClassLoader中以Java代碼的形式實(shí)現(xiàn)的。它負(fù)責(zé)加載\lib\ext目錄中，或者被java.ext.dirs系統(tǒng)變量所指定的路徑中所有的類庫。根據(jù)“擴(kuò)展類加載器”這個名稱，就可以推斷出這是一種Java系統(tǒng)類庫的擴(kuò)展機(jī)制，JDK的開發(fā)團(tuán)隊(duì)允許用戶將具有通用性的類庫放置在ext目錄里以擴(kuò)展Java SE的功能，在JDK 9之后，這種擴(kuò)展機(jī)制被模塊化帶來的天然的擴(kuò)展能力所取代。由于擴(kuò)展類加載器是由Java代碼實(shí)現(xiàn)的，開發(fā)者可以直接在程序中使用擴(kuò)展類加載器來加載Class文件。
應(yīng)用程序類加載器（Application Class Loader）：這個類加載器由sun.misc.Launcher$AppClassLoader來實(shí)現(xiàn)。由于應(yīng)用程序類加載器是ClassLoader類中的getSystem-ClassLoader()方法的返回值，所以有些場合中也稱它為“系統(tǒng)類加載器”。它負(fù)責(zé)加載用戶類路徑（ClassPath）上所有的類庫，開發(fā)者同樣可以直接在代碼中使用這個類加載器。如果應(yīng)用程序中沒有自定義過自己的類加載器，一般情況下這個就是程序中默認(rèn)的類加載器。

這些類加載器之間的協(xié)作關(guān)系“通常”會如下圖所示，圖中展示的各種類加載器之間的層次關(guān)系被稱為類加載器的“雙親委派模型（Parents Delegation Model）”。雙親委派模型要求除了頂層的啟動類加載器外，其余的類加載器都應(yīng)有自己的父類加載器。不過這里類加載器之間的父子關(guān)系一般不是以繼承（Inheritance）的關(guān)系來實(shí)現(xiàn)的，而是通常使用組合（Composition）關(guān)系來復(fù)用父加載器的代碼。

雙親委派模型的工作過程是：如果一個類加載器收到了類加載的請求，它首先不會自己去嘗試加載這個類，而是把這個請求委派給父類加載器去完成，每一個層次的類加載器都是如此，因此所有的加載請求最終都應(yīng)該傳送到最頂層的啟動類加載器中，只有當(dāng)父加載器反饋?zhàn)约簾o法完成這個加載請求（它的搜索范圍中沒有找到所需的類）時，子加載器才會嘗試自己去完成加載。

使用雙親委派模型來組織類加載器之間的關(guān)系，一個顯而易見的好處就是Java中的類隨著它的類加載器一起具備了一種帶有優(yōu)先級的層次關(guān)系。例如類java.lang.Object，它存放在rt.jar之中，無論哪一個類加載器要加載這個類，最終都是委派給處于模型最頂端的啟動類加載器進(jìn)行加載，因此Object類在程序的各種類加載器環(huán)境中都能夠保證是同一個類。反之，如果沒有使用雙親委派模型，都由各個類加載器自行去加載的話，如果用戶自己也編寫了一個名為java.lang.Object的類，并放在程序的ClassPath中，那系統(tǒng)中就會出現(xiàn)多個不同的Object類，Java類型體系中最基礎(chǔ)的行為也就無從保證，應(yīng)用程序?qū)兊靡黄靵y。

擴(kuò)展閱讀

雙親委派模型對于保證Java程序的穩(wěn)定運(yùn)作極為重要，但它的實(shí)現(xiàn)卻異常簡單，用以實(shí)現(xiàn)雙親委派的代碼只有短短十余行，全部集中在java.lang.ClassLoader的loadClass()方法之中。

protected Class<?> loadClass(String name, boolean resolve)throws ClassNotFoundException {synchronized (getClassLoadingLock(name)) {// First, check if the class has already been loadedClass<?> c = findLoadedClass(name);if (c == null) {long t0 = System.nanoTime();try {if (parent != null) {c = parent.loadClass(name, false);} else {c = findBootstrapClassOrNull(name);}} catch (ClassNotFoundException e) {// ClassNotFoundException thrown if class not found// from the non-null parent class loader}if (c == null) {// If still not found, then invoke findClass in order// to find the class.long t1 = System.nanoTime();c = findClass(name);// this is the defining class loader; record the statsPerfCounter.getParentDelegationTime().addTime(t1 - t0);PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);PerfCounter.getFindClasses().increment();}}if (resolve) {resolveClass(c);}return c;} }

這段代碼的邏輯清晰易懂：先檢查請求加載的類型是否已經(jīng)被加載過，若沒有則調(diào)用父加載器的loadClass()方法，若父加載器為空則默認(rèn)使用啟動類加載器作為父加載器。假如父類加載器加載失敗，拋出ClassNotFoundException異常的話，才調(diào)用自己的findClass()方法嘗試進(jìn)行加載。

5.14 雙親委派機(jī)制會被破壞嗎？

參考答案

雙親委派模型并不是一個具有強(qiáng)制性約束的模型，而是Java設(shè)計(jì)者推薦給開發(fā)者們的類加載器實(shí)現(xiàn)方式。在Java的世界中大部分的類加載器都遵循這個模型，但也有例外的情況，直到Java模塊化出現(xiàn)為止，雙親委派模型主要出現(xiàn)過3次較大規(guī)模“被破壞”的情況。

雙親委派模型的第一次“被破壞”其實(shí)發(fā)生在雙親委派模型出現(xiàn)之前——即JDK 1.2面世以前的“遠(yuǎn)古”時代。由于雙親委派模型在JDK 1.2之后才被引入，但是類加載器的概念和抽象類java.lang.ClassLoader則在Java的第一個版本中就已經(jīng)存在，面對已經(jīng)存在的用戶自定義類加載器的代碼，Java設(shè)計(jì)者們引入雙親委派模型時不得不做出一些妥協(xié)，為了兼容這些已有代碼，無法再以技術(shù)手段避免loadClass()被子類覆蓋的可能性，只能在JDK 1.2之后的java.lang.ClassLoader中添加一個新的protected方法findClass()，并引導(dǎo)用戶編寫的類加載邏輯時盡可能去重寫這個方法，而不是在loadClass()中編寫代碼。雙親委派的具體邏輯就實(shí)現(xiàn)在這里面，按照loadClass()方法的邏輯，如果父類加載失敗，會自動調(diào)用自己的findClass()方法來完成加載，這樣既不影響用戶按照自己的意愿去加載類，又可以保證新寫出來的類加載器是符合雙親委派規(guī)則的。

雙親委派模型的第二次“被破壞”是由這個模型自身的缺陷導(dǎo)致的，雙親委派很好地解決了各個類加載器協(xié)作時基礎(chǔ)類型的一致性問題（越基礎(chǔ)的類由越上層的加載器進(jìn)行加載），基礎(chǔ)類型之所以被稱為“基礎(chǔ)”，是因?yàn)樗鼈兛偸亲鳛楸挥脩舸a繼承、調(diào)用的API存在，但程序設(shè)計(jì)往往沒有絕對不變的完美規(guī)則，如果有基礎(chǔ)類型又要調(diào)用回用戶的代碼，那該怎么辦呢？

這并非是不可能出現(xiàn)的事情，一個典型的例子便是JNDI服務(wù)，JNDI現(xiàn)在已經(jīng)是Java的標(biāo)準(zhǔn)服務(wù)，它的代碼由啟動類加載器來完成加載（在JDK 1.3時加入到rt.jar的），肯定屬于Java中很基礎(chǔ)的類型了。但JNDI存在的目的就是對資源進(jìn)行查找和集中管理，它需要調(diào)用由其他廠商實(shí)現(xiàn)并部署在應(yīng)用程序的ClassPath下的JNDI服務(wù)提供者接口（Service Provider Interface，SPI）的代碼，現(xiàn)在問題來了，啟動類加載器是絕不可能認(rèn)識、加載這些代碼的，那該怎么辦？

為了解決這個困境，Java的設(shè)計(jì)團(tuán)隊(duì)只好引入了一個不太優(yōu)雅的設(shè)計(jì)：線程上下文類加載器（Thread Context ClassLoader）。這個類加載器可以通過java.lang.Thread類的setContext-ClassLoader()方法進(jìn)行設(shè)置，如果創(chuàng)建線程時還未設(shè)置，它將會從父線程中繼承一個，如果在應(yīng)用程序的全局范圍內(nèi)都沒有設(shè)置過的話，那這個類加載器默認(rèn)就是應(yīng)用程序類加載器。

有了線程上下文類加載器，程序就可以做一些“舞弊”的事情了。JNDI服務(wù)使用這個線程上下文類加載器去加載所需的SPI服務(wù)代碼，這是一種父類加載器去請求子類加載器完成類加載的行為，這種行為實(shí)際上是打通了雙親委派模型的層次結(jié)構(gòu)來逆向使用類加載器，已經(jīng)違背了雙親委派模型的一般性原則，但也是無可奈何的事情。Java中涉及SPI的加載基本上都采用這種方式來完成，例如JNDI、JDBC、JCE、JAXB和JBI等。不過，當(dāng)SPI的服務(wù)提供者多于一個的時候，代碼就只能根據(jù)具體提供者的類型來硬編碼判斷，為了消除這種極不優(yōu)雅的實(shí)現(xiàn)方式，在JDK 6時，JDK提供了java.util.ServiceLoader類，以META-INF/services中的配置信息，輔以責(zé)任鏈模式，這才算是給SPI的加載提供了一種相對合理的解決方案。

雙親委派模型的第三次“被破壞”是由于用戶對程序動態(tài)性的追求而導(dǎo)致的，這里所說的“動態(tài)性”指的是一些非常“熱”門的名詞：代碼熱替換（HotSwap）、模塊熱部署（Hot Deployment）等。說白了就是希望Java應(yīng)用程序能像我們的電腦外設(shè)那樣，接上鼠標(biāo)、U盤，不用重啟機(jī)器就能立即使用，鼠標(biāo)有問題或要升級就換個鼠標(biāo)，不用關(guān)機(jī)也不用重啟。對于個人電腦來說，重啟一次其實(shí)沒有什么大不了的，但對于一些生產(chǎn)系統(tǒng)來說，關(guān)機(jī)重啟一次可能就要被列為生產(chǎn)事故，這種情況下熱部署就對軟件開發(fā)者，尤其是大型系統(tǒng)或企業(yè)級軟件開發(fā)者具有很大的吸引力。

早在2008年，在Java社區(qū)關(guān)于模塊化規(guī)范的第一場戰(zhàn)役里，由Sun/Oracle公司所提出的JSR-294、JSR-277規(guī)范提案就曾敗給以IBM公司主導(dǎo)的JSR-291（即OSGi R4.2）提案。盡管Sun/Oracle并不甘心就此失去Java模塊化的主導(dǎo)權(quán)，隨即又再拿出Jigsaw項(xiàng)目迎戰(zhàn)，但此時OSGi已經(jīng)站穩(wěn)腳跟，成為業(yè)界“事實(shí)上”的Java模塊化標(biāo)準(zhǔn)。曾經(jīng)在很長一段時間內(nèi)，IBM憑借著OSGi廣泛應(yīng)用基礎(chǔ)讓Jigsaw吃盡苦頭，其影響一直持續(xù)到Jigsaw隨JDK 9面世才算告一段落。而且即使Jigsaw現(xiàn)在已經(jīng)是Java的標(biāo)準(zhǔn)功能了，它仍需小心翼翼地避開OSGi運(yùn)行期動態(tài)熱部署上的優(yōu)勢，僅局限于靜態(tài)地解決模塊間封裝隔離和訪問控制的問題，現(xiàn)在我們先來簡單看一看OSGi是如何通過類加載器實(shí)現(xiàn)熱部署的。

OSGi實(shí)現(xiàn)模塊化熱部署的關(guān)鍵是它自定義的類加載器機(jī)制的實(shí)現(xiàn)，每一個程序模塊（OSGi中稱為Bundle）都有一個自己的類加載器，當(dāng)需要更換一個Bundle時，就把Bundle連同類加載器一起換掉以實(shí)現(xiàn)代碼的熱替換。在OSGi環(huán)境下，類加載器不再雙親委派模型推薦的樹狀結(jié)構(gòu)，而是進(jìn)一步發(fā)展為更加復(fù)雜的網(wǎng)狀結(jié)構(gòu)，當(dāng)收到類加載請求時，OSGi將按照下面的順序進(jìn)行類搜索：

將以java.*開頭的類，委派給父類加載器加載。

否則，將委派列表名單內(nèi)的類，委派給父類加載器加載。

否則，將Import列表中的類，委派給Export這個類的Bundle的類加載器加載。

否則，查找當(dāng)前Bundle的ClassPath，使用自己的類加載器加載。

否則，查找類是否在自己的Fragment Bundle中，如果在，則委派給Fragment Bundle的類加載器加載。

否則，查找Dynamic Import列表的Bundle，委派給對應(yīng)Bundle的類加載器加載。

否則，類查找失敗。

上面的查找順序中只有開頭兩點(diǎn)仍然符合雙親委派模型的原則，其余的類查找都是在平級的類加載器中進(jìn)行的。

5.15 介紹一下Java的垃圾回收機(jī)制

參考答案

一、哪些內(nèi)存需要回收

在Java內(nèi)存運(yùn)行時區(qū)域的各個部分中，堆和方法區(qū)這兩個區(qū)域則有著很顯著的不確定性：一個接口的多個實(shí)現(xiàn)類需要的內(nèi)存可能會不一樣，一個方法所執(zhí)行的不同條件分支所需要的內(nèi)存也可能不一樣，只有處于運(yùn)行期間，我們才能知道程序究竟會創(chuàng)建哪些對象，創(chuàng)建多少個對象，這部分內(nèi)存的分配和回收是動態(tài)的。垃圾收集器所關(guān)注的正是這部分內(nèi)存該如何管理，我們平時所說的內(nèi)存分配與回收也僅僅特指這一部分內(nèi)存。

二、怎么定義垃圾

引用計(jì)數(shù)算法：

在對象中添加一個引用計(jì)數(shù)器，每當(dāng)有一個地方引用它時，計(jì)數(shù)器值就加一；當(dāng)引用失效時，計(jì)數(shù)器值就減一；任何時刻計(jì)數(shù)器為零的對象就是不可能再被使用的。

但是，在Java領(lǐng)域，至少主流的Java虛擬機(jī)里面都沒有選用引用計(jì)數(shù)算法來管理內(nèi)存，主要原因是，這個看似簡單的算法有很多例外情況要考慮，必須要配合大量額外處理才能保證正確地工作，譬如單純的引用計(jì)數(shù)就很難解決對象之間相互循環(huán)引用的問題。

舉個簡單的例子：對象objA和objB都有字段instance，賦值令objA.instance=objB及objB.instance=objA，除此之外，這兩個對象再無任何引用，實(shí)際上這兩個對象已經(jīng)不可能再被訪問，但是它們因?yàn)榛ハ嘁弥鴮Ψ?#xff0c;導(dǎo)致它們的引用計(jì)數(shù)都不為零，引用計(jì)數(shù)算法也就無法回收它們。

可達(dá)性分析算法：

當(dāng)前主流的商用程序語言的內(nèi)存管理子系統(tǒng)，都是通過可達(dá)性分析（Reachability Analysis）算法來判定對象是否存活的。這個算法的基本思路就是通過一系列稱為“GC Roots”的根對象作為起始節(jié)點(diǎn)集，從這些節(jié)點(diǎn)開始，根據(jù)引用關(guān)系向下搜索，搜索過程所走過的路徑稱為“引用鏈”（Reference Chain），如果某個對象到GC Roots間沒有任何引用鏈相連，或者用圖論的話來說就是從GC Roots到這個對象不可達(dá)時，則證明此對象是不可能再被使用的。

如下圖所示，對象object 5、object 6、object 7雖然互有關(guān)聯(lián)，但是它們到GC Roots是不可達(dá)的，因此它們將會被判定為可回收的對象。

在Java技術(shù)體系里面，固定可作為GC Roots的對象包括以下幾種：

在虛擬機(jī)棧（棧幀中的本地變量表）中引用的對象，譬如各個線程被調(diào)用的方法堆棧中使用到的參數(shù)、局部變量、臨時變量等。
在方法區(qū)中類靜態(tài)屬性引用的對象，譬如Java類的引用類型靜態(tài)變量。
在方法區(qū)中常量引用的對象，譬如字符串常量池（String Table）里的引用。
在本地方法棧中JNI（即通常所說的Native方法）引用的對象。
Java虛擬機(jī)內(nèi)部的引用，如基本數(shù)據(jù)類型對應(yīng)的Class對象，一些常駐的異常對象（比如NullPointExcepiton、OutOfMemoryError）等，還有系統(tǒng)類加載器。
所有被同步鎖（synchronized關(guān)鍵字）持有的對象。
反映Java虛擬機(jī)內(nèi)部情況的JMXBean、JVMTI中注冊的回調(diào)、本地代碼緩存等。

回收方法區(qū)：

方法區(qū)的垃圾收集主要回收兩部分內(nèi)容：廢棄的常量和不再使用的類型。回收廢棄常量與回收J(rèn)ava堆中的對象非常類似。舉個常量池中字面量回收的例子，假如一個字符串“java”曾經(jīng)進(jìn)入常量池中，但是當(dāng)前系統(tǒng)又沒有任何一個字符串對象的值是“java”，換句話說，已經(jīng)沒有任何字符串對象引用常量池中的“java”常量，且虛擬機(jī)中也沒有其他地方引用這個字面量。如果在這時發(fā)生內(nèi)存回收，而且垃圾收集器判斷確有必要的話，這個“java”常量就將會被系統(tǒng)清理出常量池。常量池中其他類（接口）、方法、字段的符號引用也與此類似。

判定一個常量是否“廢棄”還是相對簡單，而要判定一個類型是否屬于“不再被使用的類”的條件就比較苛刻了。需要同時滿足下面三個條件：

該類所有的實(shí)例都已經(jīng)被回收，也就是Java堆中不存在該類及其任何派生子類的實(shí)例。
加載該類的類加載器已經(jīng)被回收，這個條件除非是經(jīng)過精心設(shè)計(jì)的可替換類加載器的場景，如OSGi、JSP的重加載等，否則通常是很難達(dá)成的。
該類對應(yīng)的java.lang.Class對象沒有在任何地方被引用，無法在任何地方通過反射訪問該類的方法。

三、怎么回收垃圾

分代收集理論：

當(dāng)前商業(yè)虛擬機(jī)的垃圾收集器，大多數(shù)都遵循了“分代收集”（GenerationalCollection）的理論進(jìn)行設(shè)計(jì)，分代收集名為理論，實(shí)質(zhì)是一套符合大多數(shù)程序運(yùn)行實(shí)際情況的經(jīng)驗(yàn)法則，它建立在兩個分代假說之上：

弱分代假說（Weak Generational Hypothesis）：絕大多數(shù)對象都是朝生夕滅的。

強(qiáng)分代假說（Strong Generational Hypothesis）：熬過越多次垃圾收集過程的對象就越難以消亡。

這兩個分代假說共同奠定了多款常用的垃圾收集器的一致的設(shè)計(jì)原則：收集器應(yīng)該將Java堆劃分出不同的區(qū)域，然后將回收對象依據(jù)其年齡（年齡即對象熬過垃圾收集過程的次數(shù)）分配到不同的區(qū)域之中存儲。顯而易見，如果一個區(qū)域中大多數(shù)對象都是朝生夕滅，難以熬過垃圾收集過程的話，那么把它們集中放在一起，每次回收時只關(guān)注如何保留少量存活而不是去標(biāo)記那些大量將要被回收的對象，就能以較低代價回收到大量的空間；如果剩下的都是難以消亡的對象，那把它們集中放在一塊，虛擬機(jī)便可以使用較低的頻率來回收這個區(qū)域，這就同時兼顧了垃圾收集的時間開銷和內(nèi)存的空間有效利用。

標(biāo)記-清除算法：

最早出現(xiàn)也是最基礎(chǔ)的垃圾收集算法是“標(biāo)記-清除”（Mark-Sweep）算法，如它的名字一樣，算法分為“標(biāo)記”和“清除”兩個階段：首先標(biāo)記出所有需要回收的對象，在標(biāo)記完成后，統(tǒng)一回收掉所有被標(biāo)記的對象，也可以反過來，標(biāo)記存活的對象，統(tǒng)一回收所有未被標(biāo)記的對象。

它的主要缺點(diǎn)有兩個：第一個是執(zhí)行效率不穩(wěn)定，如果Java堆中包含大量對象，而且其中大部分是需要被回收的，這時必須進(jìn)行大量標(biāo)記和清除的動作，導(dǎo)致標(biāo)記和清除兩個過程的執(zhí)行效率都隨對象數(shù)量增長而降低；第二個是內(nèi)存空間的碎片化問題，標(biāo)記、清除之后會產(chǎn)生大量不連續(xù)的內(nèi)存碎片，空間碎片太多可能會導(dǎo)致當(dāng)以后在程序運(yùn)行過程中需要分配較大對象時無法找到足夠的連續(xù)內(nèi)存而不得不提前觸發(fā)另一次垃圾收集動作。標(biāo)記-清除算法的執(zhí)行過程如下圖所示。

標(biāo)記-復(fù)制算法：

為了解決標(biāo)記-清除算法面對大量可回收對象時執(zhí)行效率低的問題，1969年Fenichel提出了一種稱為“半?yún)^(qū)復(fù)制”（Semispace Copying）的垃圾收集算法，它將可用內(nèi)存按容量劃分為大小相等的兩塊，每次只使用其中的一塊。當(dāng)這一塊的內(nèi)存用完了，就將還存活著的對象復(fù)制到另外一塊上面，然后再把已使用過的內(nèi)存空間一次清理掉。如果內(nèi)存中多數(shù)對象都是存活的，這種算法將會產(chǎn)生大量的內(nèi)存間復(fù)制的開銷，但對于多數(shù)對象都是可回收的情況，算法需要復(fù)制的就是占少數(shù)的存活對象，而且每次都是針對整個半?yún)^(qū)進(jìn)行內(nèi)存回收，分配內(nèi)存時也就不用考慮有空間碎片的復(fù)雜情況，只要移動堆頂指針，按順序分配即可。這樣實(shí)現(xiàn)簡單，運(yùn)行高效，不過其缺陷也顯而易見，這種復(fù)制回收算法的代價是將可用內(nèi)存縮小為了原來的一半，空間浪費(fèi)未免太多了一點(diǎn)。標(biāo)記-復(fù)制算法的執(zhí)行過程如下圖所示。

在1989年，Andrew Appel針對具備“朝生夕滅”特點(diǎn)的對象，提出了一種更優(yōu)化的半?yún)^(qū)復(fù)制分代策略，現(xiàn)在稱為“Appel式回收”。Appel式回收的具體做法是把新生代分為一塊較大的Eden空間和兩塊較小的Survivor空間，每次分配內(nèi)存只使用Eden和其中一塊Survivor。發(fā)生垃圾搜集時，將Eden和Survivor中仍然存活的對象一次性復(fù)制到另外一塊Survivor空間上，然后直接清理掉Eden和已用過的那塊Survivor空間。HotSpot虛擬機(jī)默認(rèn)Eden和Survivor的大小比例是8∶1，也即每次新生代中可用內(nèi)存空間為整個新生代容量的90%（Eden的80%加上一個Survivor的10%），只有一個Survivor空間，即10%的新生代是會被“浪費(fèi)”的。當(dāng)然，98%的對象可被回收僅僅是“普通場景”下測得的數(shù)據(jù)，任何人都沒有辦法百分百保證每次回收都只有不多于10%的對象存活，因此Appel式回收還有一個充當(dāng)罕見情況的“逃生門”的安全設(shè)計(jì)，當(dāng)Survivor空間不足以容納一次Minor GC之后存活的對象時，就需要依賴其他內(nèi)存區(qū)域（實(shí)際上大多就是老年代）進(jìn)行分配擔(dān)保（Handle Promotion）。

標(biāo)記-整理算法：

標(biāo)記-復(fù)制算法在對象存活率較高時就要進(jìn)行較多的復(fù)制操作，效率將會降低。更關(guān)鍵的是，如果不想浪費(fèi)50%的空間，就需要有額外的空間進(jìn)行分配擔(dān)保，以應(yīng)對被使用的內(nèi)存中所有對象都100%存活的極端情況，所以在老年代一般不能直接選用這種算法。

針對老年代對象的存亡特征，1974年Edward Lueders提出了另外一種有針對性的“標(biāo)記-整理”（Mark-Compact）算法，其中的標(biāo)記過程仍然與“標(biāo)記-清除”算法一樣，但后續(xù)步驟不是直接對可回收對象進(jìn)行清理，而是讓所有存活的對象都向內(nèi)存空間一端移動，然后直接清理掉邊界以外的內(nèi)存，“標(biāo)記-整理”算法的示意圖如下圖所示。

5.16 請介紹一下分代回收機(jī)制

參考答案

當(dāng)前商業(yè)虛擬機(jī)的垃圾收集器，大多數(shù)都遵循了“分代收集”（GenerationalCollection）[插圖]的理論進(jìn)行設(shè)計(jì)，分代收集名為理論，實(shí)質(zhì)是一套符合大多數(shù)程序運(yùn)行實(shí)際情況的經(jīng)驗(yàn)法則，它建立在兩個分代假說之上：

弱分代假說（Weak Generational Hypothesis）：絕大多數(shù)對象都是朝生夕滅的。

強(qiáng)分代假說（Strong Generational Hypothesis）：熬過越多次垃圾收集過程的對象就越難以消亡。

這兩個分代假說共同奠定了多款常用的垃圾收集器的一致的設(shè)計(jì)原則：收集器應(yīng)該將Java堆劃分出不同的區(qū)域，然后將回收對象依據(jù)其年齡（年齡即對象熬過垃圾收集過程的次數(shù)）分配到不同的區(qū)域之中存儲。把分代收集理論具體放到現(xiàn)在的商用Java虛擬機(jī)里，設(shè)計(jì)者一般至少會把Java堆劃分為新生代（Young Generation）和老年代（Old Generation）兩個區(qū)域。顧名思義，在新生代中，每次垃圾收集時都發(fā)現(xiàn)有大批對象死去，而每次回收后存活的少量對象，將會逐步晉升到老年代中存放。

分代收集并非只是簡單劃分一下內(nèi)存區(qū)域那么容易，它至少存在一個明顯的困難：對象不是孤立的，對象之間會存在跨代引用。假如要現(xiàn)在進(jìn)行一次只局限于新生代區(qū)域內(nèi)的收集，但新生代中的對象是完全有可能被老年代所引用的，為了找出該區(qū)域中的存活對象，不得不在固定的GC Roots之外，再額外遍歷整個老年代中所有對象來確保可達(dá)性分析結(jié)果的正確性，反過來也是一樣。遍歷整個老年代所有對象的方案雖然理論上可行，但無疑會為內(nèi)存回收帶來很大的性能負(fù)擔(dān)。為了解決這個問題，就需要對分代收集理論添加第三條經(jīng)驗(yàn)法則：

跨代引用假說（Intergenerational Reference Hypothesis）：跨代引用相對于同代引用來說僅占極少數(shù)。

依據(jù)這條假說，我們就不應(yīng)再為了少量的跨代引用去掃描整個老年代，也不必浪費(fèi)空間專門記錄每一個對象是否存在及存在哪些跨代引用，只需在新生代上建立一個全局的數(shù)據(jù)結(jié)構(gòu)（稱為“記憶集”，RememberedSet），這個結(jié)構(gòu)把老年代劃分成若干小塊，標(biāo)識出老年代的哪一塊內(nèi)存會存在跨代引用。此后當(dāng)發(fā)生Minor GC時，只有包含了跨代引用的小塊內(nèi)存里的對象才會被加入到GC Roots進(jìn)行掃描。雖然這種方法需要在對象改變引用關(guān)系（如將自己或者某個屬性賦值）時維護(hù)記錄數(shù)據(jù)的正確性，會增加一些運(yùn)行時的開銷，但比起收集時掃描整個老年代來說仍然是劃算的。

5.17 JVM中一次完整的GC流程是怎樣的？

參考答案

新創(chuàng)建的對象一般會被分配在新生代中，常用的新生代的垃圾回收器是 ParNew 垃圾回收器，它按照 8:1:1 將新生代分成 Eden 區(qū)，以及兩個 Survivor 區(qū)。某一時刻，我們創(chuàng)建的對象將 Eden 區(qū)全部擠滿，這個對象就是擠滿新生代的最后一個對象。此時，Minor GC 就觸發(fā)了。

在正式 Minor GC 前，JVM 會先檢查新生代中對象，是比老年代中剩余空間大還是小。為什么要做這樣的檢查呢？原因很簡單，假如 Minor GC 之后 Survivor 區(qū)放不下剩余對象，這些對象就要進(jìn)入到老年代，所以要提前檢查老年代是不是夠用。這樣就有兩種情況：

老年代剩余空間大于新生代中的對象大小，那就直接Minor GC，GC完survivor不夠放，老年代也絕對夠放；

老年代剩余空間小于新生代中的對象大小，這個時候就要查看是否啟用了“老年代空間分配擔(dān)保規(guī)則”，具體來說就是看 -XX:-HandlePromotionFailure 參數(shù)是否設(shè)置了。

老年代空間分配擔(dān)保規(guī)則是這樣的，如果老年代中剩余空間大小，大于歷次 Minor GC 之后剩余對象的大小，那就允許進(jìn)行 Minor GC。因?yàn)閺母怕噬蟻碚f，以前的放的下，這次的也應(yīng)該放的下。那就有兩種情況：

老年代中剩余空間大小，大于歷次Minor GC之后剩余對象的大小，進(jìn)行 Minor GC；

老年代中剩余空間大小，小于歷次Minor GC之后剩余對象的大小，進(jìn)行Full GC，把老年代空出來再檢查。

開啟老年代空間分配擔(dān)保規(guī)則只能說是大概率上來說，Minor GC 剩余后的對象夠放到老年代，所以當(dāng)然也會有萬一，Minor GC 后會有這樣三種情況：

Minor GC 之后的對象足夠放到 Survivor 區(qū)，皆大歡喜，GC 結(jié)束；

Minor GC 之后的對象不夠放到 Survivor 區(qū)，接著進(jìn)入到老年代，老年代能放下，那也可以，GC 結(jié)束；

Minor GC 之后的對象不夠放到 Survivor 區(qū)，老年代也放不下，那就只能 Full GC。

前面都是成功 GC 的例子，還有 3 中情況，會導(dǎo)致 GC 失敗，報(bào) OOM：

緊接上一節(jié) Full GC 之后，老年代任然放不下剩余對象，就只能 OOM；

未開啟老年代分配擔(dān)保機(jī)制，且一次 Full GC 后，老年代任然放不下剩余對象，也只能 OOM；

開啟老年代分配擔(dān)保機(jī)制，但是擔(dān)保不通過，一次 Full GC 后，老年代任然放不下剩余對象，也是能 OOM。

GC完整流程，參考下圖：

5.18 Full GC會導(dǎo)致什么？

參考答案

Full GC會“Stop The World”，即在GC期間全程暫停用戶的應(yīng)用程序。

5.19 JVM什么時候觸發(fā)GC，如何減少FullGC的次數(shù)？

參考答案

當(dāng) Eden 區(qū)的空間耗盡時 Java 虛擬機(jī)便會觸發(fā)一次 Minor GC 來收集新生代的垃圾，存活下來的對象，則會被送到 Survivor 區(qū)，簡單說就是當(dāng)新生代的Eden區(qū)滿的時候觸發(fā) Minor GC。

serial GC 中，老年代內(nèi)存剩余已經(jīng)小于之前年輕代晉升老年代的平均大小，則進(jìn)行 Full GC。而在 CMS 等并發(fā)收集器中則是每隔一段時間檢查一下老年代內(nèi)存的使用量，超過一定比例時進(jìn)行 Full GC 回收。

可以采用以下措施來減少Full GC的次數(shù)：

增加方法區(qū)的空間；

增加老年代的空間；

減少新生代的空間；

禁止使用System.gc()方法；

使用標(biāo)記-整理算法，盡量保持較大的連續(xù)內(nèi)存空間；

排查代碼中無用的大對象。

5.20 如何確定對象是可回收的？

參考答案

引用計(jì)數(shù)算法：

可達(dá)性分析算法：

如下圖所示，對象object 5、object 6、object 7雖然互有關(guān)聯(lián)，但是它們到GC Roots是不可達(dá)的，因此它們將會被判定為可回收的對象。

在Java技術(shù)體系里面，固定可作為GC Roots的對象包括以下幾種：

在虛擬機(jī)棧（棧幀中的本地變量表）中引用的對象，譬如各個線程被調(diào)用的方法堆棧中使用到的參數(shù)、局部變量、臨時變量等。
在方法區(qū)中類靜態(tài)屬性引用的對象，譬如Java類的引用類型靜態(tài)變量。
在方法區(qū)中常量引用的對象，譬如字符串常量池（String Table）里的引用。
在本地方法棧中JNI（即通常所說的Native方法）引用的對象。
Java虛擬機(jī)內(nèi)部的引用，如基本數(shù)據(jù)類型對應(yīng)的Class對象，一些常駐的異常對象（比如NullPointExcepiton、OutOfMemoryError）等，還有系統(tǒng)類加載器。
所有被同步鎖（synchronized關(guān)鍵字）持有的對象。
反映Java虛擬機(jī)內(nèi)部情況的JMXBean、JVMTI中注冊的回調(diào)、本地代碼緩存等。

5.21 對象如何晉升到老年代？

參考答案

虛擬機(jī)給每個對象定義了一個對象年齡（Age）計(jì)數(shù)器，存儲在對象頭中。對象通常在Eden區(qū)里誕生，如果經(jīng)過第一次MinorGC后仍然存活，并且能被Survivor容納的話，該對象會被移動到Survivor空間中，并且將其對象年齡設(shè)為1歲。對象在Survivor區(qū)中每熬過一次MinorGC，年齡就增加1歲，當(dāng)它的年齡增加到一定程度（默認(rèn)為15），就會被晉升到老年代中。對象晉升老年代的年齡閾值，可以通過參數(shù)-XX：MaxTenuringThreshold設(shè)置。

5.22 為什么老年代不能使用標(biāo)記復(fù)制？

參考答案

因?yàn)槔夏甏Ａ舻膶ο蠖际请y以消亡的，而標(biāo)記復(fù)制算法在對象存活率較高時就要進(jìn)行較多的復(fù)制操作，效率將會降低，所以在老年代一般不能直接選用這種算法。

5.23 新生代為什么要分為Eden和Survivor，它們的比例是多少？

參考答案

現(xiàn)在的商用Java虛擬機(jī)大多都優(yōu)先采用了“標(biāo)記-復(fù)制算法”去回收新生代，該算法早期采用“半?yún)^(qū)復(fù)制”的機(jī)制進(jìn)行垃圾回收。它將可用內(nèi)存按容量劃分為大小相等的兩塊，每次只使用其中的一塊。當(dāng)這一塊的內(nèi)存用完了，就將還存活著的對象復(fù)制到另外一塊上面，然后再把已使用過的內(nèi)存空間一次清理掉。這樣實(shí)現(xiàn)簡單，運(yùn)行高效，不過其缺陷也顯而易見，這種復(fù)制回收算法的代價是將可用內(nèi)存縮小為了原來的一半，空間浪費(fèi)未免太多了一點(diǎn)。

實(shí)際上，新生代中的對象有98%熬不過第一輪收集，因此并不需要按照1∶1的比例來劃分新生代的內(nèi)存空間。在1989年，Andrew Appel提出了一種更優(yōu)化的半?yún)^(qū)復(fù)制分代策略，現(xiàn)在稱為“Appel式回收”。Appel式回收的具體做法是把新生代分為一塊較大的Eden空間和兩塊較小的Survivor空間，每次分配內(nèi)存只使用Eden和其中一塊Survivor。發(fā)生垃圾搜集時，將Eden和Survivor中仍然存活的對象一次性復(fù)制到另外一塊Survivor空間上，然后直接清理掉Eden和已用過的那塊Survivor空間。

HotSpot虛擬機(jī)默認(rèn)Eden和Survivor的大小比例是8∶1，也即每次新生代中可用內(nèi)存空間為整個新生代容量的90%（Eden的80%加上一個Survivor的10%），只有一個Survivor空間，即10%的新生代是會被“浪費(fèi)”的。

5.24 為什么要設(shè)置兩個Survivor區(qū)域？

參考答案

設(shè)置兩個 Survivor 區(qū)最大的好處就是解決內(nèi)存碎片化。

我們先假設(shè)一下，Survivor 只有一個區(qū)域會怎樣。Minor GC 執(zhí)行后，Eden 區(qū)被清空了，存活的對象放到了 Survivor 區(qū)，而之前 Survivor 區(qū)中的對象，可能也有一些是需要被清除的。問題來了，這時候我們怎么清除它們？在這種場景下，我們只能標(biāo)記清除，而我們知道標(biāo)記清除最大的問題就是內(nèi)存碎片，在新生代這種經(jīng)常會消亡的區(qū)域，采用標(biāo)記清除必然會讓內(nèi)存產(chǎn)生嚴(yán)重的碎片化。因?yàn)?Survivor 有 2 個區(qū)域，所以每次 Minor GC，會將之前 Eden 區(qū)和 From 區(qū)中的存活對象復(fù)制到 To 區(qū)域。第二次 Minor GC 時，From 與 To 職責(zé)兌換，這時候會將 Eden 區(qū)和 To 區(qū)中的存活對象再復(fù)制到 From 區(qū)域，以此反復(fù)。

這種機(jī)制最大的好處就是，整個過程中，永遠(yuǎn)有一個 Survivor space 是空的，另一個非空的 Survivor space 是無碎片的。那么，Survivor 為什么不分更多塊呢？比方說分成三個、四個、五個?顯然，如果 Survivor 區(qū)再細(xì)分下去，每一塊的空間就會比較小，容易導(dǎo)致 Survivor 區(qū)滿，兩塊 Survivor 區(qū)可能是經(jīng)過權(quán)衡之后的最佳方案。

5.25 說一說你對GC算法的了解。

參考答案

標(biāo)記-清除算法：

標(biāo)記-復(fù)制算法：

標(biāo)記-整理算法：

5.26 為什么新生代和老年代要采用不同的回收算法？

參考答案

如果一個區(qū)域中大多數(shù)對象都是朝生夕滅，難以熬過垃圾收集過程的話，那么把它們集中放在一起，每次回收時只關(guān)注如何保留少量存活而不是去標(biāo)記那些大量將要被回收的對象，就能以較低代價回收到大量的空間。如果剩下的都是難以消亡的對象，那把它們集中放在一塊，虛擬機(jī)便可以使用較低的頻率來回收這個區(qū)域，這就同時兼顧了垃圾收集的時間開銷和內(nèi)存的空間有效利用。

5.27 請介紹G1垃圾收集器

參考答案

G1（Garbage First）是一款主要面向服務(wù)端應(yīng)用的垃圾收集器，JDK 9發(fā)布之日，G1宣告取代ParallelScavenge加Parallel Old組合，成為服務(wù)端模式下的默認(rèn)垃圾收集器，而CMS則淪落至被聲明為不推薦使用（Deprecate）的收集器。G1收集器是垃圾收集器技術(shù)發(fā)展歷史上的里程碑式的成果，它開創(chuàng)了收集器面向局部收集的設(shè)計(jì)思路和基于Region的內(nèi)存布局形式。

雖然G1也仍是遵循分代收集理論設(shè)計(jì)的，但其堆內(nèi)存的布局與其他收集器有非常明顯的差異：G1不再堅(jiān)持固定大小以及固定數(shù)量的分代區(qū)域劃分，而是把連續(xù)的Java堆劃分為多個大小相等的獨(dú)立區(qū)域（Region），每一個Region都可以根據(jù)需要，扮演新生代的Eden空間、Survivor空間，或者老年代空間。收集器能夠?qū)Π缪莶煌巧腞egion采用不同的策略去處理，這樣無論是新創(chuàng)建的對象還是已經(jīng)存活了一段時間、熬過多次收集的舊對象都能獲取很好的收集效果。

Region中還有一類特殊的Humongous區(qū)域，專門用來存儲大對象。G1認(rèn)為只要大小超過了一個Region容量一半的對象即可判定為大對象。每個Region的大小可以通過參數(shù) -XX：G1HeapRegionSize 設(shè)定，取值范圍為1MB～32MB，且應(yīng)為2的N次冪。而對于那些超過了整個Region容量的超級大對象，將會被存放在N個連續(xù)的Humongous Region 之中，G1的大多數(shù)行為都把 Humongous Region 作為老年代的一部分來進(jìn)行看待，如下圖所示。

雖然G1仍然保留新生代和老年代的概念，但新生代和老年代不再是固定的了，它們都是一系列區(qū)域（不需要連續(xù)）的動態(tài)集合。G1收集器之所以能建立可預(yù)測的停頓時間模型，是因?yàn)樗鼘egion作為單次回收的最小單元，即每次收集到的內(nèi)存空間都是Region大小的整數(shù)倍，這樣可以有計(jì)劃地避免在整個Java堆中進(jìn)行全區(qū)域的垃圾收集。更具體的處理思路是讓G1收集器去跟蹤各個Region里面的垃圾堆積的“價值”大小，價值即回收所獲得的空間大小以及回收所需時間的經(jīng)驗(yàn)值，然后在后臺維護(hù)一個優(yōu)先級列表，每次根據(jù)用戶設(shè)定允許的收集停頓時間（使用參數(shù)-XX：MaxGCPauseMillis指定，默認(rèn)值是200毫秒），優(yōu)先處理回收價值收益最大的那些Region，這也就是“Garbage First”名字的由來。這種使用Region劃分內(nèi)存空間，以及具有優(yōu)先級的區(qū)域回收方式，保證了G1收集器在有限的時間內(nèi)獲取盡可能高的收集效率。

5.28 請介紹CMS垃圾收集器

參考答案

CMS（Concurrent Mark Sweep）收集器是一種以獲取最短回收停頓時間為目標(biāo)的收集器。從名字上就可以看出CMS收集器是基于標(biāo)記-清除算法實(shí)現(xiàn)的，它的運(yùn)作過程分為四個步驟，包括：

初始標(biāo)記（CMS initial mark）；

并發(fā)標(biāo)記（CMS concurrent mark）；

重新標(biāo)記（CMS remark）；

并發(fā)清除（CMS concurrent sweep）。

其中初始標(biāo)記、重新標(biāo)記這兩個步驟仍然需要“Stop The World”。初始標(biāo)記僅僅只是標(biāo)記一下GC Roots能直接關(guān)聯(lián)到的對象，速度很快；并發(fā)標(biāo)記階段就是從GC Roots的直接關(guān)聯(lián)對象開始遍歷整個對象圖的過程，這個過程耗時較長但是不需要停頓用戶線程，可以與垃圾收集線程一起并發(fā)運(yùn)行；而重新標(biāo)記階段則是為了修正并發(fā)標(biāo)記期間，因用戶程序繼續(xù)運(yùn)作而導(dǎo)致標(biāo)記產(chǎn)生變動的那一部分對象的標(biāo)記記錄，這個階段的停頓時間通常會比初始標(biāo)記階段稍長一些，但也遠(yuǎn)比并發(fā)標(biāo)記階段的時間短；最后是并發(fā)清除階段，清理刪除掉標(biāo)記階段判斷的已經(jīng)死亡的對象，由于不需要移動存活對象，所以這個階段也是可以與用戶線程同時并發(fā)的。

由于在整個過程中耗時最長的并發(fā)標(biāo)記和并發(fā)清除階段中，垃圾收集器線程都可以與用戶線程一起工作，所以從總體上來說，CMS收集器的內(nèi)存回收過程是與用戶線程一起并發(fā)執(zhí)行的。通過下圖可以比較清楚地看到CMS收集器的運(yùn)作步驟中并發(fā)和需要停頓的階段。

CMS收集器還遠(yuǎn)達(dá)不到完美的程度，它至少有以下三個明顯的缺點(diǎn)：

首先，CMS收集器對處理器資源非常敏感。在并發(fā)階段，它雖然不會導(dǎo)致用戶線程停頓，但卻會因?yàn)檎加昧艘徊糠志€程（或者說處理器的計(jì)算能力）而導(dǎo)致應(yīng)用程序變慢，降低總吞吐量。

然后，由于CMS收集器無法處理“浮動垃圾”（Floating Garbage），有可能出現(xiàn)“Con-current Mode Failure”失敗進(jìn)而導(dǎo)致另一次完全“Stop TheWorld”的Full GC的產(chǎn)生。

還有最后一個缺點(diǎn)，CMS是一款基于“標(biāo)記-清除”算法實(shí)現(xiàn)的收集器，這意味著收集結(jié)束時會有大量空間碎片產(chǎn)生。空間碎片過多時，將會給大對象分配帶來很大麻煩，往往會出現(xiàn)老年代還有很多剩余空間，但就是無法找到足夠大的連續(xù)空間來分配當(dāng)前對象，而不得不提前觸發(fā)一次Full GC的情況。

5.29 內(nèi)存泄漏和內(nèi)存溢出有什么區(qū)別？

參考答案

內(nèi)存泄漏（memory leak）：內(nèi)存泄漏指程序運(yùn)行過程中分配內(nèi)存給臨時變量，用完之后卻沒有被GC回收，始終占用著內(nèi)存，既不能被使用也不能分配給其他程序，于是就發(fā)生了內(nèi)存泄漏。

內(nèi)存溢出（out of memory）：簡單地說內(nèi)存溢出就是指程序運(yùn)行過程中申請的內(nèi)存大于系統(tǒng)能夠提供的內(nèi)存，導(dǎo)致無法申請到足夠的內(nèi)存，于是就發(fā)生了內(nèi)存溢出。

5.30 什么是內(nèi)存泄漏，怎么解決？

參考答案

內(nèi)存泄漏的根本原因是長生命周期的對象持有短生命周期對象的引用，盡管短生命周期的對象已經(jīng)不再需要，但由于長生命周期對象持有它的引用而導(dǎo)致不能被回收。以發(fā)生的方式來分類，內(nèi)存泄漏可以分為4類：

常發(fā)性內(nèi)存泄漏。發(fā)生內(nèi)存泄漏的代碼會被多次執(zhí)行到，每次被執(zhí)行的時候都會導(dǎo)致一塊內(nèi)存泄漏。

偶發(fā)性內(nèi)存泄漏。發(fā)生內(nèi)存泄漏的代碼只有在某些特定環(huán)境或操作過程下才會發(fā)生。常發(fā)性和偶發(fā)性是相對的。對于特定的環(huán)境，偶發(fā)性的也許就變成了常發(fā)性的。所以測試環(huán)境和測試方法對檢測內(nèi)存泄漏至關(guān)重要。

一次性內(nèi)存泄漏。發(fā)生內(nèi)存泄漏的代碼只會被執(zhí)行一次，或者由于算法上的缺陷，導(dǎo)致總會有一塊僅且一塊內(nèi)存發(fā)生泄漏。

隱式內(nèi)存泄漏。程序在運(yùn)行過程中不停的分配內(nèi)存，但是直到結(jié)束的時候才釋放內(nèi)存。嚴(yán)格的說這里并沒有發(fā)生內(nèi)存泄漏，因?yàn)樽罱K程序釋放了所有申請的內(nèi)存。但是對于一個服務(wù)器程序，需要運(yùn)行幾天，幾周甚至幾個月，不及時釋放內(nèi)存也可能導(dǎo)致最終耗盡系統(tǒng)的所有內(nèi)存。所以，我們稱這類內(nèi)存泄漏為隱式內(nèi)存泄漏。

避免內(nèi)存泄漏的幾點(diǎn)建議：

盡早釋放無用對象的引用。

避免在循環(huán)中創(chuàng)建對象。

使用字符串處理時避免使用String，應(yīng)使用StringBuffer。

盡量少使用靜態(tài)變量，因?yàn)殪o態(tài)變量存放在永久代，基本不參與垃圾回收。

5.31 什么是內(nèi)存溢出，怎么解決？

參考答案

引起內(nèi)存溢出的原因有很多種，常見的有以下幾種：

內(nèi)存中加載的數(shù)據(jù)量過于龐大，如一次從數(shù)據(jù)庫取出過多數(shù)據(jù)；

集合類中有對對象的引用，使用完后未清空，使得JVM不能回收；

代碼中存在死循環(huán)或循環(huán)產(chǎn)生過多重復(fù)的對象實(shí)體；

使用的第三方軟件中的BUG；

啟動參數(shù)內(nèi)存值設(shè)定的過小。

內(nèi)存溢出的解決方案：

第一步，修改JVM啟動參數(shù)，直接增加內(nèi)存。
第二步，檢查錯誤日志，查看“OutOfMemory”錯誤前是否有其它異常或錯誤。
第三步，對代碼進(jìn)行走查和分析，找出可能發(fā)生內(nèi)存溢出的位置。
第四步，使用內(nèi)存查看工具動態(tài)查看內(nèi)存使用情況。

5.32 哪些區(qū)域會OOM，怎么觸發(fā)OOM？

參考答案

除了程序計(jì)數(shù)器外，虛擬機(jī)內(nèi)存的其他幾個運(yùn)行時區(qū)域都有發(fā)生OOM異常的可能。

Java堆溢出

Java堆用于儲存對象實(shí)例，我們只要不斷地創(chuàng)建對象，并且保證GC Roots到對象之間有可達(dá)路徑來避免垃圾回收機(jī)制清除這些對象，那么隨著對象數(shù)量的增加，總?cè)萘坑|及最大堆的容量限制后就會產(chǎn)生內(nèi)存溢出異常。

虛擬機(jī)棧和本地方法棧溢出

HotSpot虛擬機(jī)中并不區(qū)分虛擬機(jī)棧和本地方法棧，如果虛擬機(jī)的棧內(nèi)存允許動態(tài)擴(kuò)展，當(dāng)擴(kuò)展棧容量無法申請到足夠的內(nèi)存時，將拋出OutOfMemoryError異常。

方法區(qū)和運(yùn)行時常量池溢出

方法區(qū)溢出也是一種常見的內(nèi)存溢出異常，在經(jīng)常運(yùn)行時生成大量動態(tài)類的應(yīng)用場景里，就應(yīng)該特別關(guān)注這些類的回收狀況。這類場景常見的包括：程序使用了CGLib字節(jié)碼增強(qiáng)和動態(tài)語言、大量JSP或動態(tài)產(chǎn)生JSP文件的應(yīng)用（JSP第一次運(yùn)行時需要編譯為Java類）、基于OSGi的應(yīng)用（即使是同一個類文件，被不同的加載器加載也會視為不同的類）等。

在JDK 6或更早之前的HotSpot虛擬機(jī)中，常量池都是分配在永久代中，即常量池是方法去的一部分，所以上述問題在常量池中也同樣會出現(xiàn)。而HotSpot從JDK 7開始逐步“去永久代”的計(jì)劃，并在JDK 8中完全使用元空間來代替永久代，所以上述問題在JDK 8中會得到避免。

本地直接內(nèi)存溢出

前是否有其它異常或錯誤。

第三步，對代碼進(jìn)行走查和分析，找出可能發(fā)生內(nèi)存溢出的位置。
第四步，使用內(nèi)存查看工具動態(tài)查看內(nèi)存使用情況。

5.32 哪些區(qū)域會OOM，怎么觸發(fā)OOM？

參考答案

除了程序計(jì)數(shù)器外，虛擬機(jī)內(nèi)存的其他幾個運(yùn)行時區(qū)域都有發(fā)生OOM異常的可能。

Java堆溢出

虛擬機(jī)棧和本地方法棧溢出

方法區(qū)和運(yùn)行時常量池溢出

本地直接內(nèi)存溢出

直接內(nèi)存（Direct Memory）的容量大小可通過-XX：MaxDirectMemorySize參數(shù)來指定，如果不去指定，則默認(rèn)與Java堆最大值（由-Xmx指定）一致。如果直接通過反射獲取Unsafe實(shí)例進(jìn)行內(nèi)存分配，并超出了上述的限制時，將會引發(fā)OOM異常。

總結(jié)

以上是生活随笔為你收集整理的【2022】JVM常见面试真题详解的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。