本地方法栈是JVM运行时数据区中专为native方法服务的线程私有内存区域，它不处理Java字节码，而是支撑Java与C/C++等本地代码的交互执行。
它为什么存在？——解决Java无法直接触达底层的问题
Java语言设计强调跨平台与安全性，因此屏蔽了直接操作硬件、调用系统内核或管理原生内存的能力。但实际开发中又绕不开这些需求，比如：
- 获取系统时间（System.currentTimeMillis()底层调用操作系统clock_gettime）
- 启动线程（Thread.start0()需创建OS级线程）
- 文件读写（FileInputStream.read0()最终通过libc的read系统调用）
- 哈希计算（Object.hashCode()依赖JVM本地实现）
这些功能由C/C++编写并编译为动态库（如Linux的.so、Windows的.dll），再通过JNI暴露给Java。本地方法栈就是JVM为这类调用准备的“过渡空间”。
它怎么工作？——模拟C语言调用栈的行为
每当一个带有native关键字的方法被调用，JVM不会在虚拟机栈里压入Java栈帧，而是切换到本地方法栈，为其分配一个本地栈帧（Native Stack Frame）。这个帧结构类似C函数调用栈，包含：
- 方法参数的副本（从Java栈拷贝而来）
- C函数所需的寄存器保存区（如RBP、RSP、返回地址）
- 本地局部变量存储空间（例如malloc分配的临时缓冲区）
- 执行上下文切换信息（确保从JVM模式安全进入OS原生执行环境）
执行结束后，该帧弹出，控制权交还给上层Java方法，并将返回值传回Java栈。
它和虚拟机栈有什么区别？——分工明确，互不干扰
两者虽都是栈结构、线程私有、支持嵌套调用，但职责严格分离：
- 虚拟机栈：只管Java方法，帧中存局部变量表、操作数栈、动态链接、方法出口等JVM语义信息
- 本地方法栈：只管native方法，帧中存C函数调用所需的状态，不解析字节码，也不参与GC
- HotSpot虚拟机默认将二者合二为一（即共用同一块内存），但这属于实现优化；JVM规范仍要求逻辑上独立
- 异常表现也不同：栈溢出时，虚拟机栈抛StackOverflowError，本地方法栈也可能抛此异常；若内存不足无法扩展，则可能抛OutOfMemoryError
它有哪些实际影响？——开发与排查中值得关注的点
多数Java开发者无需主动操作本地方法栈，但在以下场景中它的行为会显性化：
- 使用JNI编写或调用本地库时，C代码崩溃可能导致JVM直接终止（因本地栈帧失控）
- 频繁调用native方法（如高频IO或加密运算）会增加本地栈压力，极端情况下触发栈溢出
- 线程数极大且每个线程都调用native方法时，本地方法栈总内存占用会上升，需关注整体内存布局
- 某些JVM参数（如-Xss）同时影响虚拟机栈和本地方法栈大小（取决于具体实现）
