上一篇文章我們搭建了JVM內存結構的整體框架，知道程序計數器、虛擬機棧、本地方法棧屬于“線程私有區域”——每個線程啟動時會單獨分配內存，線程結束后內存直接釋放，無需GC參與。這三個區域看似“小眾”，卻是理解線程執行邏輯、排查棧溢出異常的關鍵，也是面試中高頻被問的考點。今天我們就深入拆解這三個區域，從“作用原理”到“異常場景”，再到“實戰配置”，徹底搞懂線程私有區域的底層邏輯。

一、程序計數器：線程的“執行路標”，為何是唯一不會OOM的區域？

在多線程環境中，CPU會在不同線程間頻繁切換——當線程A執行到一半被暫停，切換到線程B執行，等線程A再次獲得CPU時，如何知道自己該從哪行代碼繼續執行？答案就藏在“程序計數器”里。

1. 程序計數器的核心作用：記錄執行位置

程序計數器（Program Counter Register）的本質是一塊“小型內存區域”，它的唯一作用是存儲當前線程正在執行的字節碼指令的地址（或行號） 。具體來說，有兩種執行場景：

• 當線程執行Java方法時，計數器存儲的是“當前字節碼指令的偏移地址”——比如OrderService.createOrder()方法對應的字節碼文件中，第10行指令的地址；
• 當線程執行Native方法時（如System.currentTimeMillis()），計數器的值會被設為“Undefined”——因為Native方法由C/C++實現，不屬于Java字節碼范疇，JVM無法跟蹤其執行位置。

舉個實際例子：假設線程A正在執行calculateSum(100)方法，執行到字節碼的第20行（計算累加的關鍵步驟）時，CPU被切換到線程B。此時線程A的程序計數器會“記住”第20行的地址；當線程A再次獲得CPU時，JVM會讀取程序計數器中的地址，直接跳轉到第20行繼續執行，不會出現“重復執行”或“執行中斷”的問題。

2. 為什么必須是“線程私有”？

這是新手最容易困惑的問題，答案其實和“線程切換”的特性直接相關：每個線程的執行路徑、代碼邏輯都是獨立的——線程A在執行訂單創建方法，線程B在執行支付回調方法，它們的字節碼指令地址完全不同。如果程序計數器是“線程共享”的，那么線程切換時，計數器的值會被覆蓋，導致線程恢復執行時找不到正確位置。

因此，JVM會為每個線程單獨分配一塊程序計數器內存，線程間的計數器值互不干擾——線程啟動時創建，線程結束時銷毀，全程與線程生命周期綁定，這就是“線程隔離”的底層保障之一。

3. 特殊點：唯一不會OOM的JVM內存區域

《Java虛擬機規范》明確規定：程序計數器的內存大小是“固定的”，不會隨著線程執行過程動態擴展。它的內存大小取決于當前線程執行的方法——比如執行簡單的getter方法，需要記錄的指令地址較少，計數器占用內存就小；執行復雜的循環方法，指令地址雖多，但計數器仍能通過固定大小的內存存儲（本質是地址值，占用空間有限）。

正因為內存大小固定，程序計數器永遠不會出現“內存不足”的情況，也就成為了JVM中唯一不會拋出OutOfMemoryError的內存區域。這一點在面試中經常被問到，一定要記牢。

二、虛擬機棧：方法調用的“臨時舞臺”，棧溢出的根源在這里

如果說程序計數器是“執行路標”，那虛擬機棧就是線程執行方法的“臨時舞臺”——每個方法的調用、執行、返回，都對應虛擬機棧中“棧幀”的入棧、執行、出棧過程。理解虛擬機棧，就能搞懂“遞歸為什么會棧溢出”“局部變量存在哪里”這些實際問題。

1. 虛擬機棧的核心結構：棧幀的“四大部分”

虛擬機棧（Java Virtual Machine Stack）的本質是“棧式結構的內存區域”，其中存儲的基本單位是“棧幀”（Stack Frame）。每個Java方法被調用時，JVM會創建一個對應的棧幀，并入棧；當方法執行完成（正常返回或拋出異常），棧幀會出棧并釋放內存。

一個棧幀包含四大部分，我們用“調用UserService.getUserById(100)方法”為例，拆解每部分的作用：

（1）局部變量表：存儲方法的局部變量

局部變量表是棧幀中最核心的部分之一，它存儲方法的參數、局部變量，以及方法執行過程中創建的臨時變量。比如getUserById(int id)方法中，參數id（值為100）、方法內定義的User user = null變量，都會存在局部變量表中。

局部變量表的大小在“編譯期”就已確定——JVM會根據方法的參數和局部變量數量，計算出所需的“變量槽”（Slot）數量，并存入字節碼文件中。比如一個int類型的變量占1個Slot，long、double類型占2個Slot，對象引用（如User user）也占1個Slot（存儲的是對象在堆中的地址）。<