jvm调用jni时无传统栈切换，而是控制权移交、java栈帧挂起、原生栈接管执行；c函数运行于os原生栈，共享线程总栈空间，上下文切换仅由os在阻塞或信号时触发。
Java 栈帧依然存在，只是被挂起
当调用一个 native 方法（如 System.currentTimeMillis() 或自定义 JNI 函数）时：
- JVM 先在当前线程的 Java 虚拟机栈中，为该 native 方法压入一个标准栈帧（含参数、返回地址、局部变量槽等）
- 字节码执行引擎暂停，把控制权交给 JNI 接口层
- 这个 Java 栈帧并未销毁，也未弹出，而是处于“等待返回”状态
- 后续所有 C 函数调用、递归、malloc 分配、甚至新建 pthread 线程，都发生在 OS 层面的原生栈（如 Linux 的
pthread栈）上，与 JVM 管理的栈内存完全无关
C 函数运行在操作系统原生栈，不受 JVM 栈大小限制
HotSpot JVM 中并没有物理隔离的“本地方法栈”，-Xss 参数只控制线程总栈内存上限，Java 栈帧和 native 调用所用的原生栈共享同一块地址空间：
- C 函数内部深度递归或大栈帧不会触发 JVM 的 StackOverflowError（那是 Java 栈帧自己的事）
- 但可能直接导致 OS 层面的段错误（SIGSEGV），因为耗尽了线程栈空间
- 可通过
ulimit -s查看/调整系统级线程栈大小，它和-Xss共同约束实际可用栈容量
真正的上下文切换只在 OS 层触发，且仅当 native 代码阻塞时
JVM 不参与 C 函数内部的任何调度；所谓“切换”仅在以下情况由操作系统完成：
- native 代码调用了阻塞系统调用（如
read()、accept()、pthread_cond_wait()） - 触发了信号（如
SIGUSR1）并进入信号处理函数 - 显式让出 CPU（如
sched_yield()）
此时线程状态会变为 WAITING / BLOCKED（in Native method），jstack 输出可见 java.lang.Thread.State: RUNNABLE (in native) 或类似标识；vmstat 中的 cs（context switch）值会上升——这才是性能分析需关注的真实开销点。
没有寄存器保存/恢复，也没有 JVM 级别的栈切换逻辑
很多人误以为 JVM 会像协程那样保存/恢复 C 函数的寄存器上下文，其实：
- JNI 调用是同步、直接的函数跳转（类似 call 指令），无中间状态封装
- 寄存器现场由 CPU 和 OS 自动管理，JVM 不介入也不感知 C 函数内部执行细节
- 返回时，JVM 只需从挂起的 Java 栈帧中取出返回地址，继续执行下一条字节码
- 整个过程不涉及 Java 线程状态变更（比如不会变成 TIMED_WAITING），除非 native 代码主动调用了
Object.wait()等 Java 同步原语
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
