本地方法栈是jvm为线程调用native方法提供的逻辑栈空间，实际与java虚拟机栈共享-xss内存区域；native代码执行在os原生栈，其内存与栈行为由操作系统管理，jvm仅监控并触发stackoverflowerror或outofmemoryerror异常。
JNI 调用本身不直接“分配”本地方法栈内存，而是触发 JVM 在已有线程栈结构中完成控制权移交——关键影响在于栈帧生命周期、内存归属和异常风险的转变。
本地方法栈在 JNI 调用中并不独立存在
HotSpot JVM 中，本地方法栈与 Java 虚拟机栈共享同一块内存区域（由 -Xss 参数统一控制），并非两个物理隔离的栈。所谓“本地方法栈”是逻辑概念：当 Java 方法声明为 native 并被调用时，JVM 会在当前线程的虚拟机栈上压入一个特殊栈帧，该帧记录参数、返回地址等，但不包含本地代码的执行逻辑。
- 这个栈帧始终驻留在 JVM 管理的内存中，受 GC root 保护（例如其中引用的 Java 对象不会被回收）
- C/C++ 函数实际运行在操作系统原生线程栈（如 pthread 栈）上，其局部变量、递归调用、malloc 分配等完全脱离 JVM 栈空间管理
- JVM 不为 native 代码额外申请栈内存，也不干预其栈使用行为
JNI 调用引发的栈相关异常仍源于 Java 栈配置
虽然 native 代码运行在 OS 栈，但触发 StackOverflowError 或 OutOfMemoryError 的判断依据仍是 JVM 层面对“当前线程栈”的监控范围：
-
StackOverflowError：发生在 Java 栈帧嵌套过深时，例如 native 方法反复回调 Java 方法（
env->CallVoidMethod()），导致 Java 栈持续压入新帧 -
OutOfMemoryError (unable to create new native thread)：本质是 OS 无法为新线程分配原生栈空间（如默认 8MB），此时即使
-Xss设置较小，也可能因系统级线程数/内存限制失败 - 注意：C 代码中栈溢出（如大数组局部变量、深度递归）通常导致 JVM 进程崩溃（SIGSEGV），而非 Java 异常
JNI 回调会延长 Java 栈帧生命周期并增加嵌套深度
当 native 代码通过 JNI 接口主动调用 Java 方法（如 env->CallObjectMethod()），JVM 会在同一线程的虚拟机栈上继续压入新的 Java 栈帧，形成 Java → native → Java 的嵌套调用链：
- 原始 native 栈帧保持“挂起等待返回”状态，不释放
- 每次回调都新增 Java 栈帧，可能快速耗尽
-Xss配置的栈空间 - 若回调链中存在循环或未设终止条件，极易触发 StackOverflowError
内存泄漏风险主要来自 native 侧，而非栈本身
本地方法栈帧随方法返回自动销毁，不涉及 GC；但 JNI 使用中常见的内存问题集中在：
- C 代码中
malloc分配的内存未free，造成 native heap 泄漏 - JNIEnv 缓存全局引用（
NewGlobalRef）后未及时DeleteGlobalRef，导致 Java 堆对象无法回收 - 直接字节缓冲区（DirectByteBuffer）背后 native 内存未释放，引发
OutOfMemoryError: Direct buffer memory
