jni调用时本地方法栈并非复用java虚拟机栈，而是由jvm在本地线程栈上为每次调用分配独立c++栈帧，该栈帧与java栈物理隔离、生命周期独立，承担参数转换、上下文切换及本地逻辑执行，其切换引发cpu流水线冲刷、tlb刷新和缓存失效，构成核心性能开销。
JNI调用时，本地方法栈不是简单“复用”Java虚拟机栈，而是由JVM为每次本地方法调用在本地线程栈上分配一个全新的C++栈帧——这个栈帧独立于Java栈帧，承担参数转换、上下文切换和本地逻辑执行的全部职责。
本地方法栈与Java虚拟机栈是分离的
Java线程执行Java方法时，使用的是虚拟机栈（JVM Stack），每个Java方法对应一个栈帧，含局部变量表、操作数栈等；而一旦进入JNI本地方法（如Java_com_example_MyClass_nativeMethod），JVM会暂停Java栈的执行流，将控制权移交至本地线程栈（即C/C++运行时栈），并在其上构建一个原生栈帧。这个栈帧由操作系统直接管理，不遵循JVM规范，也不包含字节码或动态链接信息，只承载C函数调用所需的寄存器上下文、局部变量和返回地址。
关键点：
- 两个栈物理隔离：Java栈在堆外内存中由JVM维护；本地栈由OS分配，通常位于线程默认栈空间内
- 线程仍为同一个：Java线程进入native后并未创建新线程，但执行上下文从JVM切换到了本地运行时
- 栈帧生命周期不同：Java栈帧随方法退出自动出栈；本地栈帧随C函数返回自然销毁，无需JVM干预
JNI调用触发的栈帧切换流程
一次典型JNI调用（如Java层调用native int add(int a, int b)）背后发生四阶段栈行为：
- Java栈暂挂：当前Java栈帧暂停执行，JVM保存PC寄存器、局部变量等现场
-
本地栈帧构建：在当前线程的本地栈上分配连续内存块，压入参数（a、b转为
jint）、JNIEnv*指针、jobject引用等 - 本地函数执行：CPU跳转至C函数入口，所有运算（包括循环、内存访问）均在此栈帧内完成
- 结果回传与栈恢复：返回值写入约定寄存器（如RAX），本地栈帧弹出，JVM恢复Java栈帧并继续执行
这个过程涉及CPU模式切换（用户态→内核态可能间接触发）、TLB刷新及缓存行失效，是JNI开销的核心来源之一。
栈帧切换带来的典型性能陷阱
开发者常忽略栈帧切换本身隐含的成本，尤其在高频小调用场景下：
- 频繁进出导致流水线冲刷：每次切换都打断CPU指令流水线，现代处理器需数十周期重建预测路径
- JNIEnv*不可跨栈复用：该指针绑定当前栈帧上下文，若在回调或异步线程中误用，会引发段错误或静默崩溃
-
局部引用表与栈帧强耦合：每个本地栈帧隐式关联一个局部引用表，未及时
PopLocalFrame会导致引用堆积，最终触发JNIEnv::ExceptionCheck失败或OOM -
临界区阻塞GC：调用
GetPrimitiveArrayCritical时，JVM会暂停GC，此时若本地栈帧执行过长（如IO等待），将拖慢整个应用GC周期
优化方向：减少栈帧切换频次与开销
不靠消灭JNI，而靠让每次切换更“值得”：
- 用批处理替代逐元素调用：把100次
GetIntField合并为一次GetIntArrayRegion - 缓存
jclass、jmethodID等元数据，避免每次调用都触发字符串哈希查找 - 对长耗时本地操作，改用
AttachCurrentThread+ 独立线程，避免阻塞Java主线程栈帧 - 优先使用Direct ByteBuffer而非
jarray，绕过栈帧内数组拷贝，实现零拷贝共享内存
本质上，JNI性能优化不是消除栈帧，而是让栈帧承载更多有效工作，摊薄切换成本。
