面試官：說說JVM內存整體結構？線程私有還是共享的？
JVM 整體架構，中間部分就是 Java 虛擬機定義的各種運行時數據區域。
圖片
Java 虛擬機定義了若干種程序運行期間會使用到的運行時數據區，其中有一些會隨著虛擬機啟動而創建，隨著虛擬機退出而銷毀。另外一些則是與線程一一對應的，這些與線程一一對應的數據區域會隨著線程開始和結束而創建和銷毀。
線程私有：程序計數器、虛擬機棧、本地方法區
線程共享：堆、方法區, 堆外內存（Java7的永久代或JDK8的元空間、代碼緩存）
什么是程序計數器（線程私有）？
PC 寄存器用來存儲指向下一條指令的地址，即將要執行的指令代碼。由執行引擎讀取下一條指令。
PC寄存器為什么會被設定為線程私有的？
多線程在一個特定的時間段內只會執行其中某一個線程方法，CPU會不停的做任務切換，這樣必然會導致經常中斷或恢復。為了能夠準確的記錄各個線程正在執行的當前字節碼指令地址，所以為每個線程都分配了一個PC寄存器，每個線程都獨立計算，不會互相影響。
什么是虛擬機棧（線程私有）？
主管 Java 程序的運行，它保存方法的局部變量、部分結果，并參與方法的調用和返回。每個線程在創建的時候都會創建一個虛擬機棧，其內部保存一個個的棧幀(Stack Frame），對應著一次次 Java 方法調用，是線程私有的，生命周期和線程一致。
特點？
- 棧是一種快速有效的分配存儲方式，訪問速度僅次于程序計數器
- JVM 直接對虛擬機棧的操作只有兩個：每個方法執行，伴隨著入棧（進棧/壓棧），方法執行結束出棧
- 棧不存在垃圾回收問題
- 可以通過參數-Xss來設置線程的最大棧空間，棧的大小直接決定了函數調用的最大可達深度
該區域有哪些異常？
- 如果采用固定大小的 Java 虛擬機棧，那每個線程的 Java 虛擬機棧容量可以在線程創建的時候獨立選定。如果線程請求分配的棧容量超過 Java 虛擬機棧允許的最大容量，Java 虛擬機將會拋出一個 StackOverflowError 異常
- 如果 Java 虛擬機棧可以動態擴展，并且在嘗試擴展的時候無法申請到足夠的內存，或者在創建新的線程時沒有足夠的內存去創建對應的虛擬機棧，那 Java 虛擬機將會拋出一個OutOfMemoryError異常
棧幀的內部結構？
- 局部變量表（Local Variables）
- 操作數棧（Operand Stack）(或稱為表達式棧)
- 動態鏈接（Dynamic Linking）：指向運行時常量池的方法引用
- 方法返回地址（Return Address）：方法正常退出或異常退出的地址
- 一些附加信息
圖片
Java虛擬機棧如何進行方法計算的？
以如下代碼為例：
private static int add(int a, int b) {
int c = 0;
c = a + b;
return c;
}可以通過jsclass 等工具查看bytecode
圖片
壓棧的步驟如下：
0: iconst_0 // 0壓棧
1: istore_2 // 彈出int，存放于局部變量2
2: iload_0 // 把局部變量0壓棧
3: iload_1 // 局部變量1壓棧
4: iadd //彈出2個變量，求和，結果壓棧
5: istore_2 //彈出結果，放于局部變量2
6: iload_2 //局部變量2壓棧
7: ireturn //返回如果計算100+98的值，那么操作數棧的變化如下圖：
圖片
什么是本地方法棧（線程私有）？
- 本地方法接口
一個 Native Method 就是一個 Java 調用非 Java 代碼的接口。我們知道的 Unsafe 類就有很多本地方法。
- 本地方法棧(Native Method Stack)
Java 虛擬機棧用于管理 Java 方法的調用，而本地方法棧用于管理本地方法的調用
什么是方法區（線程共享）？
方法區（method area）只是 JVM 規范中定義的一個概念，用于存儲類信息、常量池、靜態變量、JIT編譯后的代碼等數據，并沒有規定如何去實現它，不同的廠商有不同的實現。而永久代（PermGen）**是 **Hotspot** 虛擬機特有的概念， Java8 的時候又被**元空間取代了，永久代和元空間都可以理解為方法區的落地實現。
JDK1.8之前調節方法區大小：
-XX:PermSize=N //方法區（永久代）初始大小
-XX:MaxPermSize=N //方法區（永久代）最大大小，超出這個值將會拋出OutOfMemoryErrorJDK1.8開始方法區（HotSpot的永久代）被徹底刪除了，取而代之的是元空間，元空間直接使用的是本機內存。參數設置：
-XX:MetaspaceSize=N //設置Metaspace的初始（和最小大小）
-XX:MaxMetaspaceSize=N //設置Metaspace的最大大小棧、堆、方法區的交互關系
圖片
永久代和元空間內存使用上的差異?
Java虛擬機規范中只定義了方法區用于存儲已被虛擬機加載的類信息、常量、靜態變量和即時編譯后的代碼等數據
- jdk1.7開始符號引用存儲在native heap中，字符串常量和靜態類型變量存儲在普通的堆區中，但分離的并不徹底,此時永久代中還保存另一些與類的元數據無關的雜項
- jdk8后HotSpot 原永久代中存儲的類的元數據將存儲在metaspace中，而類的靜態變量和字符串常量將放在Java堆中，metaspace是方法區的一種實現，只不過它使用的不是虛擬機內的內存，而是本地內存。在元空間中保存的數據比永久代中純粹很多，就只是類的元數據，這些信息只對編譯期或JVM的運行時有用。
- 永久代有一個JVM本身設置固定大小上線，無法進行調整，而元空間使用的是直接內存，受本機可用內存的限制，并且永遠不會得到java.lang.OutOfMemoryError。
- 符號引用沒有存在元空間中，而是存在native heap中，這是兩個方式和位置，不過都可以算作是本地內存，在虛擬機之外進行劃分，沒有設置限制參數時只受物理內存大小限制，即只有占滿了操作系統可用內存后才OOM。
堆區內存是怎么細分的？
對于大多數應用，Java 堆是 Java 虛擬機管理的內存中最大的一塊，被所有線程共享。此內存區域的唯一目的就是存放對象實例，幾乎所有的對象實例以及數據都在這里分配內存。
為了進行高效的垃圾回收，虛擬機把堆內存邏輯上劃分成三塊區域（分代的唯一理由就是優化 GC 性能）：
- 新生帶（年輕代）：新對象和沒達到一定年齡的對象都在新生代
- 老年代（養老區）：被長時間使用的對象，老年代的內存空間應該要比年輕代更大
Java 虛擬機規范規定，Java 堆可以是處于物理上不連續的內存空間中，只要邏輯上是連續的即可，像磁盤空間一樣。實現時，既可以是固定大小，也可以是可擴展的，主流虛擬機都是可擴展的（通過 -Xmx 和 -Xms 控制），如果堆中沒有完成實例分配，并且堆無法再擴展時，就會拋出 OutOfMemoryError 異常。
- 年輕代 (Young Generation)
年輕代是所有新對象創建的地方。當填充年輕代時，執行垃圾收集。這種垃圾收集稱為 Minor GC。年輕一代被分為三個部分——伊甸園（Eden Memory）和兩個幸存區（Survivor Memory，被稱為from/to或s0/s1），默認比例是8:1:1
- 大多數新創建的對象都位于 Eden 內存空間中
- 當 Eden 空間被對象填充時，執行Minor GC，并將所有幸存者對象移動到一個幸存者空間中
- Minor GC 檢查幸存者對象，并將它們移動到另一個幸存者空間。所以每次，一個幸存者空間總是空的
- 經過多次 GC 循環后存活下來的對象被移動到老年代。通常，這是通過設置年輕一代對象的年齡閾值來實現的，然后他們才有資格提升到老一代
- 老年代(Old Generation)
舊的一代內存包含那些經過許多輪小型 GC 后仍然存活的對象。通常，垃圾收集是在老年代內存滿時執行的。老年代垃圾收集稱為 主GC（Major GC），通常需要更長的時間。
大對象直接進入老年代（大對象是指需要大量連續內存空間的對象）。這樣做的目的是避免在 Eden 區和兩個Survivor 區之間發生大量的內存拷貝
圖片
JVM中對象在堆中的生命周期?
- 在 JVM 內存模型的堆中，堆被劃分為新生代和老年代
新生代又被進一步劃分為 Eden區 和 Survivor區，Survivor 區由 From Survivor 和 To Survivor 組成
- 當創建一個對象時，對象會被優先分配到新生代的 Eden 區
此時 JVM 會給對象定義一個對象年輕計數器（-XX:MaxTenuringThreshold）
- 當 Eden 空間不足時，JVM 將執行新生代的垃圾回收（Minor GC）
JVM 會把存活的對象轉移到 Survivor 中，并且對象年齡 +1
對象在 Survivor 中同樣也會經歷 Minor GC，每經歷一次 Minor GC，對象年齡都會+1
- 如果分配的對象超過了-XX:PetenureSizeThreshold，對象會直接被分配到老年代
JVM中對象的分配過程?
為對象分配內存是一件非常嚴謹和復雜的任務，JVM 的設計者們不僅需要考慮內存如何分配、在哪里分配等問題，并且由于內存分配算法和內存回收算法密切相關，所以還需要考慮 GC 執行完內存回收后是否會在內存空間中產生內存碎片。
- new 的對象先放在伊甸園區，此區有大小限制
- 當伊甸園的空間填滿時，程序又需要創建對象，JVM 的垃圾回收器將對伊甸園區進行垃圾回收（Minor GC），將伊甸園區中的不再被其他對象所引用的對象進行銷毀。再加載新的對象放到伊甸園區
- 然后將伊甸園中的剩余對象移動到幸存者 0 區
- 如果再次觸發垃圾回收，此時上次幸存下來的放到幸存者 0 區，如果沒有回收，就會放到幸存者 1 區
- 如果再次經歷垃圾回收，此時會重新放回幸存者 0 區，接著再去幸存者 1 區
- 什么時候才會去養老區呢？默認是 15 次回收標記
- 在養老區，相對悠閑。當養老區內存不足時，再次觸發 Major GC，進行養老區的內存清理
- 若養老區執行了 Major GC 之后發現依然無法進行對象的保存，就會產生 OOM 異常
什么是 TLAB （Thread Local Allocation Buffer）?
- 從內存模型而不是垃圾回收的角度，對 Eden 區域繼續進行劃分，JVM 為每個線程分配了一個私有緩存區域，它包含在 Eden 空間內
- 多線程同時分配內存時，使用 TLAB 可以避免一系列的非線程安全問題，同時還能提升內存分配的吞吐量，因此我們可以將這種內存分配方式稱為快速分配策略
- OpenJDK 衍生出來的 JVM 大都提供了 TLAB 設計
為什么要有 TLAB ?
- 堆區是線程共享的，任何線程都可以訪問到堆區中的共享數據
- 由于對象實例的創建在 JVM 中非常頻繁，因此在并發環境下從堆區中劃分內存空間是線程不安全的
- 為避免多個線程操作同一地址，需要使用加鎖等機制，進而影響分配速度
盡管不是所有的對象實例都能夠在 TLAB 中成功分配內存，但 JVM 確實是將 TLAB 作為內存分配的首選。
在程序中，可以通過 -XX:UseTLAB 設置是否開啟 TLAB 空間。
默認情況下，TLAB 空間的內存非常小，僅占有整個 Eden 空間的 1%，我們可以通過 -XX:TLABWasteTargetPercent 設置 TLAB 空間所占用 Eden 空間的百分比大小。
一旦對象在 TLAB 空間分配內存失敗時，JVM 就會嘗試著通過使用加鎖機制確保數據操作的原子性，從而直接在 Eden 空間中分配內存。
