栈上分配受限于对象大小（通常>128字节即禁用）、逃逸分析失败（如反射、异常分支、jni等干扰引用追踪）、标量替换失效（含不可分解字段）及jit策略限制（如非热点方法或版本兼容性约束）。
对象大小超出栈容量限制
栈空间是线程私有的，且默认大小有限（如HotSpot JVM默认栈大小通常为1MB，可通过-Xss调整）。当逃逸分析判定某对象“不逃逸”，理论上可栈上分配，但若其内存占用过大，编译器会主动放弃该优化。例如一个含数百字段的大型结构体或超长数组，在栈帧中分配可能引发栈溢出（StackOverflowError），危及线程稳定性。因此JVM设定硬性阈值——通常对象大小超过约128字节时，即使未逃逸，也会被保守地分配到堆上。
复杂控制流干扰引用追踪精度
逃逸分析依赖对变量引用路径的静态或近似静态推导。一旦代码中存在以下情况，分析结果易趋于保守：
- 反射调用（如Field.set()、Method.invoke()），使编译器无法确认引用是否写入堆或跨线程共享
- 异常处理分支中隐式传递对象（如catch块内将局部对象赋给静态集合）
- 循环中动态决定是否返回指针，或条件分支分别触发不同逃逸行为（如if分支返回地址、else分支仅本地使用）
- JNI调用边界，因JVM无法穿透本地代码分析对象去向
这些场景导致分析器无法建立确定的引用传播链，为保证程序语义正确，它会将对象标记为“可能逃逸”，从而禁用栈上分配。
标量替换失效间接阻断栈上分配
栈上分配在JVM中常与标量替换协同实现：先拆解对象为基本类型字段，再将各字段独立分配在栈帧或寄存器中。但若对象包含不可分解成分——比如含有final Object[]字段、泛型类型擦除后无法确定实际元素类型、或字段本身是已知会逃逸的引用类型——标量替换就会失败。此时即使对象未逃逸，也无法完成栈上布局，最终回落至堆分配。
JIT编译策略与版本兼容性约束
并非所有JVM实现都启用栈上分配。HotSpot自Java 6起支持逃逸分析，但栈上分配在部分版本中默认关闭（需显式开启-XX:+DoEscapeAnalysis -XX:+EliminateAllocations），且C2编译器对热点方法才执行深度分析。非热点方法、启动初期的解释执行阶段，逃逸分析本身就不生效。此外，某些JDK版本（如部分Java 11~17更新）因稳定性考量临时弱化了栈上分配逻辑，导致本可优化的对象仍落堆。
