本地方法栈处理 Native I/O（如 SocketRead0）时不执行字节码，由 OS 线程直接管理栈帧，阻塞时线程状态为 RUNNABLE；HotSpot 中其与虚拟机栈共享内存，-Xss 同时限制两者深度；异常处理绕过 Java 栈展开，资源释放不可靠。
本地方法栈在处理 Native I/O 操作（如 SocketRead0）时，并不执行 Java 字节码逻辑，而是将控制权完全交由底层 C/C++ 实现，此时线程进入“脱离 JVM 管控”的状态。
Native I/O 调用触发本地方法栈压栈
当 Java 层调用类似 SocketInputStream.socketRead0() 这类被 native 修饰的方法时，JVM 不会在 Java 虚拟机栈中创建新栈帧，而是在本地方法栈中分配一个栈帧，用于保存：
- C 函数所需的参数（如文件描述符、缓冲区地址、长度等）
- 本地线程的寄存器上下文（如
rbp、rsp、rdi等 x86-64 寄存器状态） - 调用链中可能需要的本地局部变量和临时存储空间
这个栈帧由操作系统原生线程直接管理，与 JVM 的 GC 和字节码解释器无直接关联。
阻塞型 Native I/O 会导致本地方法栈长期驻留
以 SocketRead0 为例，若底层 socket 处于阻塞模式且远端未发数据，对应的 C 函数（如 Linux 上的 read() 或 recv()）会挂起当前 OS 线程。此时：
- 本地方法栈帧保持压栈状态，不弹出
- JVM 线程状态显示为
RUNNABLE（注意：不是WAITING或BLOCKED），因为 OS 线程仍在运行（只是被内核调度器挂起） - 该栈帧占用的内存不会被 JVM 回收，也不会参与任何 Java 堆或元空间的 GC
这种行为容易被误判为“线程卡死”，实则是 OS 层面的 I/O 阻塞，JVM 无法干预或超时中断（除非使用 NIO 的非阻塞通道 + Selector）。
HotSpot 中本地方法栈与虚拟机栈实际合一
在主流 HotSpot JVM 中，本地方法栈并未物理独立实现，而是复用虚拟机栈的同一块内存区域（即共享栈空间）。这意味着：
- 设置
-Xss同时约束 Java 方法调用深度和 Native 方法调用深度 - 深度递归调用 native 方法（如层层 JNI 回调）同样可能触发
StackOverflowError -
SocketRead0等单次调用通常栈开销小，但若嵌套在大量 native 层调用链中（如某些 JNI 封装库），仍需警惕栈溢出
异常与资源释放不经过 JVM 栈展开机制
Native I/O 执行期间发生的错误（如 EINTR、EBADF、超时或连接重置）由 C 层直接捕获并转换为 Java 异常（如 IOException）。这个过程绕过 Java 的异常表和栈展开（stack unwinding）机制：
- 不会触发
finally块或 try-with-resources 的自动关闭逻辑（除非 Java 层已提前注册了 close hook） - 本地栈帧直接弹出，JVM 不执行任何 Java 层的栈帧清理动作
- 资源泄漏风险更高——例如文件描述符未显式关闭，仅依赖
finalize()或 Cleaner 是不可靠的
