本地方法栈不执行JNI调用本身，而是为每次调用在本地线程C栈上分配独立原生栈帧，该帧与Java栈物理隔离、生命周期独立，专用于参数转换、JNIEnv*上下文、本地逻辑执行及结果回传。
Java 中本地方法栈不执行 JNI 调用本身，而是为每次 JNI 调用在当前线程的本地 C/C++ 栈上分配一个独立的原生栈帧——这个栈帧与 Java 虚拟机栈物理隔离、生命周期独立，专用于承载参数转换、JNIEnv* 上下文、本地逻辑执行和结果回传。
本地方法栈与 Java 虚拟机栈完全分离
Java 线程调用 native 方法时，JVM 并不会复用已有的 Java 栈帧。它会暂停 Java 栈执行流，转而在操作系统管理的本地线程栈（即 C 运行时栈）中开辟一块新内存，构建一个标准 C 函数栈帧。该栈帧里没有字节码、没有局部变量表结构，只包含：
- C 函数所需的寄存器上下文（如返回地址、调用者保存寄存器）
- 从 Java 层转换而来的参数（如 jint 替代 int，jobject 引用替代 Java 对象）
- 隐式绑定的 JNIEnv* 指针（指向当前线程的 JNI 接口表）
- 局部引用表（每个栈帧独享，用于管理 jobject/jstring 等本地引用）
JNI 调用实际走的是“栈帧切换”流程
一次 Java_com_example_Foo_bar() 调用背后，发生四步底层动作：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- Java 栈帧现场保存：PC 寄存器、操作数栈顶、局部变量表快照被暂存
- 本地栈帧压入：在当前线程的 C 栈上分配空间，填入 JNIEnv*、jclass/jobject、转换后参数
- C 函数执行：CPU 直接跳转到 native 函数入口，所有计算（含循环、指针运算、malloc/free）都在该 C 栈帧内完成
- 结果写回并弹出：返回值存入约定寄存器（如 x86-64 的 RAX），C 栈帧自动销毁，JVM 恢复 Java 栈继续执行
关键约束和常见误用点
这个机制带来几个硬性限制，直接影响代码正确性和性能：
立即学习“Java免费学习笔记（深入）”；
- JNIEnv* 不可跨栈帧使用：它绑定当前本地栈帧上下文，若在异步回调、子线程或缓存后重复使用，会引发段错误或静默崩溃
- 局部引用生命周期 = 栈帧生命周期：未显式调用 Push/PopLocalFrame 或 DeleteLocalRef，会导致引用堆积，最终触发 OOM 或异常
- 高频小调用开销主要来自切换本身：每次进出都触发 CPU 流水线冲刷、TLB 刷新、L1/L2 缓存失效，而非 C 函数体执行
- 无 Java 栈帧的“动态链接”或“字节码解释”环节：native 方法不参与 JIT 编译、不走解释器，纯靠 C 运行时调度
开发中要盯住的实质问题
写 JNI 时真正该关注的，不是“怎么配本地方法栈”，而是：
- 确保 System.loadLibrary() 加载的库名与平台一致（Windows → .dll，Linux → libxxx.so）
- 在 C/C++ 实现中严格遵守 JNIEnv* 使用边界，避免跨调用传递
- 对 byte[]、String、Object 数组等大数据，优先用 GetPrimitiveArrayCritical + ReleasePrimitiveArrayCritical 降低拷贝开销
- 避免在 hot path 上频繁调用 GetObjectClass、GetMethodID 等反射类 API，应缓存 jclass/jmethodID
