hotspot虚拟机中本地方法栈与虚拟机栈物理合一，共用同一栈空间，通过栈帧标记区分java与native方法，统一由-xss控制大小、触发stackoverflowerror。
OpenJDK 的本地方法栈只服务于 JNI 调用
OpenJDK（HotSpot VM）中，本地方法栈不单独存在——它和虚拟机栈共享同一块内存区域。也就是说，当你调用一个 native 方法（比如 Object.getClass() 或 Thread.start0()），JVM 并不会切到另一个栈，而是直接在当前线程的虚拟机栈上分配一个特殊结构的栈帧，这个栈帧就是“本地方法栈帧”。它的唯一用途就是支撑 JNI 调用链：从 Java 层进入 C/C++ 层、传递参数、保存返回地址、处理异常跳转。
为什么 HotSpot 不单独实现本地方法栈
因为没必要。本地方法调用频率远低于 Java 方法，且多数 native 方法执行时间短、栈深度浅。HotSpot 选择复用虚拟机栈，省去维护两套栈管理逻辑的开销。这带来几个实际影响：
-
-Xss参数同时控制 Java 方法和 native 方法的栈空间上限； - 触发
StackOverflowError时，无法区分是 Java 递归过深，还是 native 层回调嵌套太深； - 调试时看到的线程栈 dump 中，
native方法会显示为Native Method，但帧结构仍归属虚拟机栈； - 没有独立的栈扩容策略，也不支持像虚拟机栈那样配置
-XX:InitialStackPages等细粒度参数。
哪些情况真会用到本地方法栈帧
不是所有 native 方法都会真正“入栈”。只有那些需要完整执行上下文的才会生成栈帧，典型场景包括：
- 通过
JNIEnv*调用 JVM 提供的 JNI 函数（如NewStringUTF、CallObjectMethod）； - native 方法内部再回调 Java 方法（即“反向调用”，必须有栈帧承载 Java 调用上下文）；
- 使用
RegisterNatives注册的函数，在首次被 Java 层调用时； - 涉及线程状态切换的 JNI 调用（如
MonitorEnter/MonitorExit）。
而纯计算型、无 JVM 交互的 native 方法（比如某些数学库封装），HotSpot 可能直接 inline 或跳过栈帧创建——但这属于 JIT 优化范畴，不可依赖。
容易被忽略的关键点
本地方法栈帧虽然由 JVM 自动管理，但它持有的资源可能不会自动释放：比如 native 方法里 malloc 的内存、打开的文件描述符、或 JNI GlobalRef 引用。这些不在 GC 范围内，也不会随栈帧出栈而清理。一旦忘记在 native 代码里显式释放，就会造成内存泄漏或句柄耗尽——这类问题在线程频繁创建/销毁的场景（如 Web 容器）中尤为隐蔽。
