---

---

JVM底層原理

前言

已經(jīng)找到工作了，分享秋招時的筆記。祝大家都能順利找到自己心儀的工作。

---

面試題

Java 對象的創(chuàng)建過程？

1. 類加載檢查：
   • 當(dāng)虛擬機(jī)遇到 new 指令時，首先檢查這個指令的參數(shù)，也就是要創(chuàng)建的對象的類是否已經(jīng)加載過
   • 如果沒有加載過，虛擬機(jī)會執(zhí)行類加載過程
2. 分配內(nèi)存：
   • 類加載檢查通過后，虛擬機(jī)會為新對象分配內(nèi)存空間
3. 對象內(nèi)存初始化：
   • 分配內(nèi)存完成后，虛擬機(jī)會將分配到的內(nèi)存空間初始化為零值
4. 設(shè)置對象頭：
   • 虛擬機(jī)會在對象的內(nèi)存空間中設(shè)置對象頭，用于存儲關(guān)于對象的元數(shù)據(jù)信息
5. 執(zhí)行初始化方法（構(gòu)造函數(shù)）：
   • 經(jīng)過上述步驟，一個新的對象已經(jīng)產(chǎn)生，但是從 Java 程序的角度來看，對象的創(chuàng)建還沒有完成
   • 然后，會根據(jù)程序員定義的構(gòu)造函數(shù)進(jìn)行初始化

什么是指針碰撞？什么是空閑列表？/ 內(nèi)存分配的兩種方式？

指針碰撞：

• 指針碰撞假定 Java 堆中的內(nèi)存是絕對規(guī)整的
• 內(nèi)存的分界點(diǎn)由一個指針作為指示器來標(biāo)示，指向已分配內(nèi)存的末尾
• 在分配對象內(nèi)存時，只需要將指針向空閑空間方向移動對象內(nèi)存大小的位置
• 適用于基于壓縮策略的收集器，例如 Serial 和 ParNew 收集器

空閑列表：

• 空閑列表假設(shè) Java 堆內(nèi)存并不規(guī)整，已分配內(nèi)存和空閑內(nèi)存交錯分布
• 虛擬機(jī)維護(hù)一個空閑列表，記錄哪些內(nèi)存塊是可用的，即未被分配的
• 在分配對象內(nèi)存時，虛擬機(jī)會在空閑列表中找到一塊足夠大的空間來分配給對象。分配后，虛擬機(jī)需要更新空閑列表上的記錄，標(biāo)記分配的區(qū)域為已用
• 適用于基于清除算法的收集器，例如 CMS 收集器

JVM 里 new 對象時，堆會發(fā)生搶占嗎？JVM 是怎么設(shè)計來保證線程安全的？/ 內(nèi)存分配并發(fā)問題？

• CAS：使用 CAS 操作來保證更新操作的原子性
• 本地線程分配緩沖 (TLAB)：
  每個線程在 Java 堆中預(yù)先分配一小塊內(nèi)存，稱為本地線程分配緩沖
  要分配內(nèi)存的線程，先在本地緩沖區(qū)中分配，只有本地緩沖區(qū)用完，分配新的緩沖區(qū)才需要同步鎖定

對象的內(nèi)存布局？

對象在堆內(nèi)存中的布局可以劃分為三個部分：對象頭、實例數(shù)據(jù)和對齊填充

• 對象頭：包括兩部分信息：存儲對象自身的運(yùn)行時數(shù)據(jù)；類型指針
• 實例數(shù)據(jù)：用來存儲對象真正的有效信息
• 對齊填充：起占位符的作用

對象怎么訪問定位？

使用句柄：

• Java 堆中劃分內(nèi)存來作為句柄池
• 句柄中包含對象實例數(shù)據(jù)的指針和對象類型數(shù)據(jù)的指針
  

直接指針：

• 對象的實例數(shù)據(jù)直接存放在堆內(nèi)存中
  

對比：

• 使用句柄：在對象被移動的時候，不需要更新引用地址
• 直接指針：效率高，節(jié)省了一次指針定位的時間開銷（HotSpot 使用）

內(nèi)存溢出和內(nèi)存泄漏？

• 內(nèi)存溢出：申請的內(nèi)存超過可用內(nèi)存，內(nèi)存不足
• 內(nèi)存泄漏：申請的內(nèi)存空間沒有被正確釋放，導(dǎo)致內(nèi)存空間被浪費(fèi)

能手寫內(nèi)存溢出的例子嗎？

• Java 堆溢出：Java 堆用于存儲對象實例，只要不斷創(chuàng)建不可回收的對象，比如靜態(tài)變量，隨著對象數(shù)量的增加，總?cè)萘砍^最大堆的限制就會產(chǎn)生 OOM

    public static void main(String[] args) {List<OOMObject> list = new ArrayList<>();while (true) {list.add(new OOMObject());}}

• 虛擬機(jī)棧溢出：不停創(chuàng)建線程，也會出現(xiàn) OOM 異常

    public static void recursiveMethod() {recursiveMethod();}public static void main(String[] args) {try {recursiveMethod();} catch (Throwable e) {System.out.println("Stack depth: " + e.getStackTrace().length);e.printStackTrace();}}

內(nèi)存泄漏可能由哪些原因?qū)е履?#xff1f;

• 靜態(tài)集合： 靜態(tài)集合生命周期與 JVM 相同,如果將對象添加到靜態(tài)集合中并且忘記刪除，這些對象將一直存在于內(nèi)存中，無法被垃圾回收
• 單例模式： 單例模式中的實例會被以靜態(tài)變量的方式存儲在內(nèi)存中，一旦創(chuàng)建，會在整個 JVM 生命周期中存在。如果單例對象占用內(nèi)存過多或者被誤用，就可能導(dǎo)致內(nèi)存泄漏
• 連接未釋放： 如果在使用完數(shù)據(jù)庫連接、網(wǎng)絡(luò)連接等資源后沒有正確關(guān)閉，這些資源可能不會被釋放，導(dǎo)致內(nèi)存泄漏
• 變量作用域過大： 如果變量的作用域超出了實際需要的范圍，導(dǎo)致對象不能被及時釋放，就會引起內(nèi)存泄漏
• hash 值發(fā)生改變： 如果對象的 hashCode 值在存入哈希容器后被修改，那么在嘗試從哈希容器中獲取該對象時，哈希容器會根據(jù) hashCode 去查找，但實際上已經(jīng)找不到這個對象了
• ThreadLocal 使用不當(dāng)： ThreadLocal 中的 key 是弱引用，但 value 是強(qiáng)引用。如果 ThreadLocal 的使用不當(dāng)，導(dǎo)致 key 無法被垃圾回收，而 value 卻一直存在，就會造成內(nèi)存泄漏

如何判斷對象仍然存活？/ 如何判斷對象是否死亡？

引用計數(shù)算法:

• 在對象中添加一個引用計數(shù)器
• 每當(dāng)有一個地方引用它時，計數(shù)器值就 +1
• 引用失效時，計數(shù)器值 -1
• 任何時刻計數(shù)器為零的對象就是不可能再被使用的
• 不使用該方法，因為很難解決對象之間相互循環(huán)引用的問題

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

• 通過一系列 GC Roots 的對象作為起點(diǎn)
• 從這些節(jié)點(diǎn)開始向下搜索，節(jié)點(diǎn)走過的路徑就是引用鏈
• 當(dāng)一個對象到 GC Roots 沒有任何引用鏈相連，證明此對象是不可能再被使用的
  

Java 中可作為 GC Roots 的對象有哪幾種？

• 虛擬機(jī)棧中引用的對象
• 本地方法棧中引用的對象
• 方法區(qū)中類靜態(tài)屬性引用的對象
• 方法區(qū)中常量引用的對象

說一下對象有哪幾種引用？/ 強(qiáng)引用、軟引用、弱引用、虛引用？

強(qiáng)引用：

• 使用最普遍的引用
• 無論任何情況，只要具有強(qiáng)引用，垃圾收集器就永遠(yuǎn)不會回收被引用的對象

軟引用：

• 用來描述還有用，但非必須的對象
• 只被軟引用關(guān)聯(lián)著的對象，在系統(tǒng)將要發(fā)生內(nèi)存溢出異常前，會把這些對象列進(jìn)回收范圍之中進(jìn)行第二次回收

弱引用：

• 用來描述那些非必須的對象，強(qiáng)度比軟引用還弱一些
• 被弱引用關(guān)聯(lián)的對象只能生存到下一次垃圾收集發(fā)生為止
• 無論當(dāng)前內(nèi)容是否足夠，都會回收掉只被弱引用關(guān)聯(lián)的對象

虛引用：

• 不會決定對象的生命周期
• 唯一目的是為了能在這個對象被收集器回收時收到一個系統(tǒng)通知

什么是 Stop The World？

• 在垃圾回收的過程中，會涉及到對象的移動。為了保證對象引用更新的正確性，必須暫停所有的用戶線程，即 Stop The World

什么是 OopMap？

• 類加載完成后，記錄對象偏移量和數(shù)據(jù)類型的映射表

對象一定分配在堆中嗎？有沒有了解逃逸分析技術(shù)？

• 對象不一定分配在堆中
• 逃逸分析是一種編譯器技術(shù)，用于確定對象創(chuàng)建后從方法逃逸到哪些位置，并確定將對象存放在堆上還是棧
• 如果對象沒有逃逸到方法的外部，可以將其存放在棧上，避免頻繁的堆內(nèi)存分配和垃圾回收，從而提高程序的性能

線上服務(wù) CPU 占用過高怎么排查？

• 首先找出哪個進(jìn)程占用 CPU 過高
• 然后找到進(jìn)程中的哪個線程占用 CPU 過高
• 找到線程 ID 后，打印出對應(yīng)線程的堆棧信息
• 根據(jù)線程的堆棧信息定位到具體代碼

內(nèi)存飆高問題怎么排查？

如果內(nèi)存飆高發(fā)生在 Java 進(jìn)程上，一般是因為創(chuàng)建了大量的對象，垃圾回收的速度跟不上對象創(chuàng)建的速度，或者是內(nèi)存泄露導(dǎo)致對象無法回收

舉例棧溢出的情況？

• 棧溢出就是方法執(zhí)行時，創(chuàng)建的棧幀超過了棧的深度，出現(xiàn) StackOverflowError
• 解決方法：使用參數(shù) -Xss 調(diào)整 JVM 棧的大小
• 具體例子：
  • 局部數(shù)組過大
  • 遞歸調(diào)用的層次太多。遞歸函數(shù)在運(yùn)行時會執(zhí)行壓棧操作
  • 指針或數(shù)組越界。例如字符串拷貝，處理用戶輸入

調(diào)整棧大小，就能保證不出現(xiàn)溢出嗎？

• 不能
• 如果程序是死遞歸的情況，調(diào)整棧的大小只是說異常出現(xiàn)的時間會晚一些

分配的棧內(nèi)存越大越好嗎？

• 不是
• 如果程序是死遞歸的情況，分配大內(nèi)存的棧只是說異常出現(xiàn)的時間會晚一些
• 會導(dǎo)致可執(zhí)行的線程數(shù)減少，影響其他內(nèi)存結(jié)構(gòu)

垃圾回收是否會涉及到虛擬機(jī)棧

• 不會，因為只有入棧出棧操作，出棧的過程就相當(dāng)于 GC

方法中定義的局部變量是否線程安全？

• 如果只有一個線程才可以操作此數(shù)據(jù)，則必然線程安全
• 如果有多個線程操作此數(shù)據(jù)，則此數(shù)據(jù)是共享數(shù)據(jù)。如果不考慮同步機(jī)制，會存在線程安全問題
• 如果變量是在方法內(nèi)部產(chǎn)生，內(nèi)部消亡的就是安全的,不是內(nèi)存產(chǎn)生，或者作為返回值返回的（生命周期沒有結(jié)束）就不是安全的

靜態(tài)變量和局部變量？

• 參數(shù)表分配完畢之后，再根據(jù)方法體內(nèi)的變量順序和作用域分配
• 類變量表有兩次初始化的機(jī)會
  • 第一次是在準(zhǔn)備階段，執(zhí)行系統(tǒng)初始化，對類變量設(shè)置零值
  • 第二次是在初始化階段，賦予程序員在代碼中定義的初始值
• 局部變量不存在系統(tǒng)初始化的過程，即定義了局部變量必須人為的初始化

如何判斷一個常量是廢棄常量？

• 假設(shè)在字符串常量池中存在字符串 “abc”
• 如果當(dāng)前沒有任何 String 對象引用該字符串常量的話，就說明常量 “abc” 就是廢棄常量

秋招后端開發(fā)面試題系列目錄
一、Java
1.1 Java基礎(chǔ)上
1.2 Java基礎(chǔ)下
1.3 Java集合
1.4 JavaIO
1.5 Java多線程上
1.6Java多線程下
二、JVM
2.1 JVM底層原理
2.2 垃圾回收器
2.3 垃圾回收算法
2.4 類加載機(jī)制
2.5 運(yùn)行時數(shù)據(jù)區(qū)
三、MySQL
3.1 MySQL基礎(chǔ)
3.2 事務(wù)
3.3 索引
3.4 鎖機(jī)制
3.5 MVCC
四、Redis
4.1 Redis基礎(chǔ)
4.2 緩存原理
五、中間件
5.1 RabbitMQ
六、Spring開源框架
6.1 Spring
6.2 Spring MVC
6.3 Spring Boot
6.4 MyBatis
七、操作系統(tǒng)
八、計算機(jī)網(wǎng)絡(luò)
九、設(shè)計模式
十、微服務(wù)架構(gòu)
十一、Spring Cloud分布式
11.1 分布式基礎(chǔ)
11.2 Spring Cloud
11.3 GateWay
11.4 Nacos
11.5 OpenFeign
11.6 Ribbon
十二、算法
十三、項目