虚拟机栈专为Java方法服务，本地方法栈服务于native方法；二者在HotSpot中常合并实现但语义分离；栈帧含局部变量表、操作数栈、动态链接和返回地址；StackOverflowError因调用过深，OutOfMemoryError因线程数多或-Xss过大。
虚拟机栈与本地方法栈的核心分工
虚拟机栈专为 Java 方法服务，每个线程独有一份，方法调用即创建栈帧，方法结束即销毁栈帧。本地方法栈则服务于 native 方法（如 Object.hashCode()、System.nanoTime()），由 JNI 调用 C/C++ 实现的逻辑，不遵循 Java 字节码规范。
二者在 HotSpot JVM 中常被合并实现，共用 -Xss 参数配置内存大小；但语义上严格分离：一个管 Java 字节码执行，一个管底层系统交互。
栈帧结构与局部变量表的关键细节
虚拟机栈中每个栈帧包含四个固定部分：
- 局部变量表：按槽（Slot）存储方法参数和内部局部变量，大小在编译期确定（见 class 文件 Code.max_locals），32 位数据占 1 槽，long 和 double 占 2 槽；第 0 槽默认存放 this 引用（非静态方法）
- 操作数栈：执行引擎的“计算器”，字节码指令在此完成入栈/出栈运算，初始为空，深度也在编译期确定
- 动态链接：指向运行时常量池中该方法的符号引用，支撑多态调用和运行时解析
- 方法返回地址：记录调用者下一条指令位置，支持正常返回或异常退出
本地方法栈的栈帧结构无统一定义，由本地语言（如 C 函数调用惯例）决定，JVM 不参与其内部布局管理。
栈溢出的两种典型场景与定位思路
栈相关错误只有两类，但成因和排查路径不同：
- StackOverflowError：单线程内方法调用链过深，如无限递归、深层嵌套、AOP 过度代理。表现为堆栈日志极长，线程仍在运行，仅当前线程崩溃
- OutOfMemoryError: unable to create new native thread：不是栈本身爆了，而是 JVM 尝试为新线程分配栈空间时失败——通常因线程总数过多（如未限制线程池）、或 -Xss 设置过大导致总内存超限
验证方式：减小 -Xss（如设为 128k）后若 OOM 频次下降，说明是线程数与栈大小不匹配；若 SOF 仍频繁出现，则需检查代码递归逻辑或 AOP 切面层数。
调优建议：从参数到代码习惯
栈内存不可回收，也不受 GC 管理，调优重点在预防而非事后清理：
- 默认 -Xss 值（HotSpot 64 位常见为 1MB）对多数业务偏大，可结合压测下调至 256k～512k，节省线程内存开销
- 避免在递归方法中声明大对象或数组，它们虽在堆分配，但引用变量会持续占据局部变量表槽位，间接压缩可用栈深度
- 使用 Thread.setStackTrace() 或 JFR（Java Flight Recorder）采样，识别高频/深调用栈路径
- 本地方法调用频次高时（如密集序列化、加解密），注意 native 层是否存在栈上大缓冲区分配，这类问题不在 JVM 控制范围内，需查 C 侧代码
