HotSpot JVM 实际上并不做栈上分配（Stack Allocation），所谓“栈上分配”是逃逸分析后标量替换（Scalar Replacement）的间接效果，不是对象整体搬去栈上。
为什么很多人误以为 HotSpot 会把对象分配到栈上
这是对逃逸分析宣传的常见误解。JDK 7 起默认开启 -XX:+DoEscapeAnalysis，但 HotSpot 从未实现真正意义上的栈上分配——即不把整个 new Demo() 对象结构塞进栈帧里。它只在满足严格条件时启用 标量替换：把未逃逸、可分解的对象拆成若干个局部变量（如 int x、long y），这些变量自然落在栈帧的局部变量表或寄存器中。
对象本身仍会在堆上尝试分配，但 JIT 编译器发现后续没用到该对象引用，就跳过 new 指令，直接操作其字段你看到的“没触发 GC”“内存占用低”，其实是标量替换 + 堆分配被省略的结果，不是对象真在栈上用 -XX:+PrintEscapeAnalysis 可观察到类似 demo is not escaped 的日志，但这不代表它去了栈上，只代表它可能被拆解
什么情况下逃逸分析会认为对象“不逃逸”
必须同时满足以下所有条件，逃逸分析才可能判定为 No Escape，进而触发标量替换：
对象仅在当前方法内创建，且 未作为参数传给任何其他方法（包括 toString()、System.out.println() 等隐式调用）未赋值给任何 非局部变量：不能写入实例字段、静态字段、数组元素、集合容器，也不能被 lambda 捕获（除非是 effectively final 且 JIT 能证明无共享）未被 反射访问（如 Field.set()）、未被 JNI 引用、未被序列化框架（如 Jackson）通过 getter/setter 触达对象类型不能含 finalizer（即不能重写 finalize()），否则强制视为逃逸
哪怕只有一行 list.add(obj) 或 return obj，逃逸等级立刻升为 Method Escape，标量替换立即失效。
如何验证逃逸分析是否生效
光看代码逻辑不够，得靠 JVM 输出和实际行为交叉验证：
加参数 -XX:+UnlockDiagnosticVMOptions -XX:+PrintEscapeAnalysis，运行后搜 not escaped 或 escaped 关键字配合 -XX:+PrintGCDetails 观察相同逻辑下 GC 频次是否明显下降（标量替换成功 → 少堆分配 → 少 GC）注意：逃逸分析只在 服务端模式（-server）+ C2 编译器 下启用；使用 -Xint 或 client 模式会完全跳过小对象（如 Point、Pair）更容易被替换；大对象（含数组、复杂嵌套）即使不逃逸，JIT 也大概率放弃标量替换
容易被忽略的关键点
标量替换不是银弹，它高度依赖 JIT 的编译时机与上下文：
逃逸分析只在方法被 C2 编译（通常是执行约 10000 次后）才进行，冷启动阶段全是堆分配同一段代码，在不同 JVM 版本（如 JDK 8u292 vs JDK 17）或不同 GC 算法（ZGC vs G1）下，逃逸判定结果可能不同哪怕对象被成功标量替换，它的字段仍可能被分配到 CPU 寄存器而非栈内存——所谓“栈上”，只是概念性说法，底层由 JIT 自主调度
真正可控的优化手段，是写出让逃逸分析“容易看懂”的代码：避免临时对象参与任何跨作用域传递，优先用原始类型组合代替小对象封装。
评论(0)