JVM调用JNI执行底层I/O时不发生Java栈与本地方法栈的上下文切换，而是共享同一-Xss内存区域、挂起Java执行流，由OS原生线程栈运行C代码；native栈帧保留在原位置，仅控制权移交至JNI层，真正上下文切换仅在阻塞系统调用时由OS触发。
JVM调用JNI执行底层文件I/O（如open、read、write）时，并不发生传统意义上的“Java栈 ↔ 本地方法栈”上下文切换，而是共享栈空间、挂起Java执行流、交由OS原生线程栈运行本地代码。
Java栈与本地方法栈在HotSpot中实际是同一块内存
HotSpot JVM未物理分离虚拟机栈和本地方法栈，二者共用 -Xss 指定的内存区域。当Java方法调用 native 方法（如FileInputStream.read0()），JVM只是在当前线程的栈上压入一个特殊栈帧——它结构类似Java栈帧，但标记为“native”，用于保存参数、返回地址和JNI环境指针（JNIEnv*）。这个栈帧始终保留在原位置，不会被弹出或迁移。
控制权转移发生在执行引擎层，而非栈切换
- JVM解释器或JIT编译器执行到 invokestatic 指令后，查找到对应JNI函数指针（如Java_java_io_FileInputStream_read0）
- 执行引擎暂停字节码执行，将控制权移交JNI接口层
- C函数真正运行在操作系统线程的原生栈（如Linux下pthread创建的用户态栈）上，不受JVM栈内存管理约束
- 此时Java栈帧处于“挂起等待返回”状态：局部变量表中引用的对象仍为GC Root，但CPU指令流已不在JVM控制范围内
真正的上下文切换只在OS层面触发
只有当本地C代码执行阻塞式系统调用（例如阻塞read()、poll()、pthread_cond_wait()）时，操作系统才会将该线程挂起，发生CPU寄存器保存/恢复、内核栈切换等真实上下文切换。这种切换与Java线程状态直接对应——jstack中会显示线程停留在 in Native method，且状态为BLOCKED或WAITING。频繁此类调用会导致vmstat中cs（context switch）值升高，成为隐蔽性能瓶颈。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
栈帧生命周期清晰，但无跨栈数据拷贝
整个I/O调用过程中的栈帧管理是线性的：
立即学习“Java免费学习笔记（深入）”；
- Java方法调用native read → 压入native栈帧
- JNI函数执行 → 可能使用Direct Buffer地址直接读入，或通过GetPrimitiveArrayCritical获取堆数组底层数组指针
- read系统调用返回 → C函数结束 → JVM恢复执行引擎 → 弹出该native栈帧 → 继续执行后续Java字节码
全程没有栈内容复制或映射操作；所谓“切换”，本质是执行流从JVM托管环境临时让渡给OS调度器管理。
