hotspot虚拟机将本地方法栈与虚拟机栈物理合一，因二者执行模型趋同：均需独立栈帧、遵循lifo、具完整生命周期、触发同类异常、线程私有；实现上共用栈空间，通过帧标记区分java/native；jstack不单独显示本地栈，-xss统一约束深度；主流jvm如openj9、graalvm（java模式）亦采用此设计。
HotSpot虚拟机把本地方法栈和虚拟机栈物理上合二为一，不是功能缺失，而是执行模型趋同下的合理统一。
调用行为本质一致
Java方法和本地方法在运行时表现出高度相似的执行特征：
- 都需要独立栈帧保存局部变量、操作数、返回地址
- 都严格遵循后进先出（LIFO）调用顺序
- 都经历完整的进入、执行、退出生命周期
- 都会触发StackOverflowError或OutOfMemoryError
- 都是线程私有，生命周期与线程完全绑定
实现层面共用同一栈空间
HotSpot不维护两套独立栈结构，而是通过栈帧内部标记区分类型：
- Java栈帧含PC寄存器指向字节码地址，局部变量表存Java引用
- Native栈帧标记为native，PC可能为空或指向C函数地址，参数按ABI规则传递（如x86-64使用寄存器+栈）
- 调用链可自然混合：Java → JNI入口 → C函数 → 回调Java，全程复用同一栈空间
对开发和运维的实际影响
日常编码几乎无感知，但排查问题需注意以下细节：
- jstack输出中不会单独列出“本地方法栈”，所有帧统一显示，native方法仅标注Native Method字样
- -Xss参数同时约束Java与Native调用的最大深度，JNI层无限递归同样抛StackOverflowError
- 本地方法回调Java时，线程会切换执行上下文，但栈空间连续不中断
- 某些AOT编译或特殊GC阶段，native帧可能绕过部分Java栈校验，属JVM内部优化细节
主流JVM已基本达成共识
一体化并非HotSpot特有设计：
- OpenJ9同样采用统一Java栈，native方法使用相同栈帧格式
- GraalVM在Java模式下行为一致；启用Native Image后则脱离Java栈范式，转为标准C栈
- JRockit曾保留分离设计，但已被Oracle弃用，现代JVM已无实质差异
