03.3 - 本地方法栈
定位: JNI（Java Native Interface）调用时，为 Native 方法提供执行栈 面试高频度: ⭐⭐ 考查方式: HotSpot 的栈合并、JNI 调用流程、本地方法栈是否 OOM
一、这是什么？为什么需要它？
Java 虚拟机栈管理 Java 方法的调用，但它有一条边界——非 Java 语言编写的方法（通常是用 C/C++ 实现的 Native 方法）。
Java 方法的局部变量存储在 JVM 的栈帧中，使用 JVM 定义的 slot 机制。但 C 代码的局部变量、函数调用栈、参数传递遵循 C 的运行时期约（System V ABI / Windows x64 calling convention）。JVM 需要一个专门为 Native 代码准备的栈——这就是本地方法栈。
Java 世界 C 世界
┌─────────────────┐ ┌─────────────────┐
│ Java 虚拟机栈 │ │ 本地方法栈 │
│ │ │ │
│ main() │ │ Java_xxx_hashCode │
│ └→ hash() │ │ └→ 系统调用 │
│ └→ JNI ──┼────────────────┼─→ native实现 │
│ │ │ │
│ 遵守 JVM 规范 │ │ 遵守 C ABI 规范 │
│ (slot/操作数栈) │ │ (rbp/rsp/栈帧) │
└─────────────────┘ └─────────────────┘两个栈使用完全不同的运行期规范。如果用 Java 虚拟机栈来执行 C 代码，C 函数的局部变量布局、寄存器保存恢复、栈帧展开等机制都无法正常工作。
二、原理拆解
2.1 HotSpot 的实现：两个栈合并为一个
HotSpot 虚拟机将本地方法栈和 Java 虚拟机栈合并为同一个栈。
HotSpot 单栈结构:
┌─ 低地址 ─────────────────────────────────────────┐
│ │
│ Java 栈帧: main() │
│ Java 栈帧: hash() │
│ Java→Native 过渡帧 (transition frame) │
│ Native 栈帧: Java_Object_hashCode (C函数帧) │
│ Native 栈帧: 系统调用 │
│ │
└─ 高地址 ─────────────────────────────────────────┘为什么可以合并？
Native 方法执行在同一个线程中。Java 调用 C 函数时，本质上只是线程执行状态的切换——从"执行字节码"切换到"执行机器码"。栈指针（RSP/ESP）在同一个内存区域中移动，不需要在物理上隔开两个不同的栈。
合并的好处：实现更简单，不需要维护两套独立的栈内存分配/回收逻辑。在 -Xss 限制的总栈空间内，Java 帧和 Native 帧共享空间。
并非所有 JVM 实现都如此。例如 Classic VM（第一代 Sun JVM）是物理分离的。HotSpot 选择了合并作为实现策略。
2.2 JNI 调用全流程
Java 代码调用 Object.hashCode() →
↓
JVM 解析符号引用 → hashCode() 是 native 方法 →
↓
查找 JNI 函数表 (Java_java_lang_Object_hashCode) →
↓
┌────────────────────────────────────────────────────┐
│ JNI 过渡 (Transition) │
│ │
│ ① 从 Java 状态切换到 Native 状态 │
│ - 线程状态: _thread_in_Java → _thread_in_native │
│ - 如果 GC 处于安全点, 线程在此处阻塞 │
│ │
│ ② 参数转换 │
│ - JNI 规范: JNIEnv* (环境指针) + this/参数 │
│ - JVM 将 Java 引用转为 native 指针 │
│ │
│ ③ 调用 C 函数 │
│ - C 代码在本地方法栈帧中执行 │
│ - 此时 PC = undefined (非字节码) │
│ │
│ ④ 返回值转换 │
│ - int/boolean 直接返回 │
│ - 对象引用转为 Java 端的 opaque reference │
│ │
│ ⑤ 切回 Java 状态 │
│ - 线程状态: _thread_in_native → _thread_in_Java │
│ - 检查是否有 pending exception │
│ - 检查是否需要在安全点阻塞 │
└────────────────────────────────────────────────────┘
↓
Java 代码继续执行 (收到 hashCode 返回值)关键点：参数转换。Java 的 Object 引用在 C 代码中是 jobject 类型，这是一个不透明的指针（opaque pointer）。C 代码不能直接解引用这个指针，必须通过 JNIEnv 提供的函数（如 GetStringUTFChars）来操作 Java 对象。这是 JNI 安全性的基础——C 代码无法随意破坏 JVM 的内部数据结构。
2.3 异常情况
本地方法栈也会发生 StackOverflowError 和 OOM：
| 异常 | 发生条件 |
|---|---|
| StackOverflowError | Native 方法递归深度超过栈限制（C 代码的无限递归） |
| OOM | 无法分配新的栈空间（与 Java 虚拟机栈共享空间） |
由于 HotSpot 是单栈结构，-Xss 参数同时影响 Java 栈帧和 Native 栈帧的可用空间。
三、图解全景
┌────────────────────────────────────────────────────────────────┐
│ JNI 调用栈过渡 (HotSpot 合并栈) │
│ │
│ 内存地址 (栈向下增长) │
│ 低地址 │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Java 栈帧: Object.hashCode() 的调用者 │ │
│ │ (还在等待 hashCode 返回值) │ │
│ └────────────────────────────────────────────────────────────┘ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ JNI 过渡帧 (Transition Frame) │ │
│ │ - 保存 Java 侧的寄存器/状态 │ │
│ │ - 包含指向 JNI 函数表的指针 │ │
│ └────────────────────────────────────────────────────────────┘ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Native 栈帧: Java_java_lang_Object_hashCode │ │
│ │ - JNIEnv* (第一个参数, 指向 JNI 函数表的指针) │ │
│ │ - jobject this (第二个参数) │ │
│ │ - C 局部变量 (int rv) │ │
│ └────────────────────────────────────────────────────────────┘ │
│ ┌────────────────────────────────────────────────────────────┐ │
│ │ Native 栈帧: 底层系统调用 (如 OS 的 hash 函数) │ │
│ └────────────────────────────────────────────────────────────┘ │
│ 高地址 │
│ │
│ ── 线程栈边界 (由 -Xss 控制, 超出→StackOverflowError) ──── │
└────────────────────────────────────────────────────────────────┘四、实战验证
public class NativeStackDemo {
// 一个递归的 native 方法 (会导致 C 栈溢出)
public static native void nativeRecurse(int depth);
static {
System.loadLibrary("NativeStackDemo");
}
public static void main(String[] args) {
try {
nativeRecurse(0);
} catch (StackOverflowError e) {
System.out.println("Native 栈溢出: " + e);
}
}
}// NativeStackDemo.c
#include <jni.h>
#include "NativeStackDemo.h"
JNIEXPORT void JNICALL Java_NativeStackDemo_nativeRecurse
(JNIEnv *env, jclass cls, jint depth) {
char dummy[1024]; // 每次递归占用 1KB C 栈空间
printf("depth: %d\n", depth);
Java_NativeStackDemo_nativeRecurse(env, cls, depth + 1); // C 级递归
}# 编译 C 代码
gcc -shared -I"$JAVA_HOME/include" -I"$JAVA_HOME/include/win32" \
-o NativeStackDemo.dll NativeStackDemo.c
# 运行 (观察 C 栈溢出和 Java StackOverflowError 的对应关系)
java -Xss256k NativeStackDemo当 Java 代码调用 nativeRecurse 时，C 函数的每次递归都在本地方法栈上分配 dummy[1024]，最终超过 -Xss 限制，抛出 StackOverflowError。这个异常由 JVM 在 C 代码返回控制权后抛出（JNI 过渡帧检测到信号/异常），而不是由 C 运行时直接抛出。
五、面试视角
| 追问 | 答案要点 |
|---|---|
| HotSpot 中虚拟机栈和本地方法栈的关系？ | HotSpot 将两个栈合并为同一个。不需要物理隔离，只要维护好 Java/Native 的状态切换和栈帧布局即可。好处是实现简单，-Xss 统一限制 |
| JNI 调用的完整流程？ | Java 状态→JNI 过渡（线程状态切换、参数转换）→C 函数执行→返回值转换→切回 Java 状态。关键在过渡帧，它保存了 Java 侧的上下文 |
| 本地方法栈会 OOM 吗？ | 会。OS 无法分配新的栈空间时抛出 OOM（与虚拟机栈共享空间）。递归过深则抛出 StackOverflowError |
| 为什么需要本地方法栈而不是直接用虚拟机栈？ | Java 方法和 C 函数的运行期规范不同：JVM 用 slot/操作数栈，C 遵循系统 ABI（rbp/rsp/calling convention）。两套机制无法共用同一个栈帧结构 |
📚 相关链接
- **程序计数器** — Native 方法执行时 PC = undefined
- **Java虚拟机栈** — HotSpot 中两个栈合并，共享 -Xss 限制
- ← 返回 **运行时数据区索引**