java中不存在真正的栈上分配，所谓“栈上分配”实为逃逸分析成功后的标量替换效果：jit跳过对象创建，将字段作为独立局部变量处理；其生效前提是对象严格不逃逸且生命周期限于方法内，验证需依赖jit日志而非内存变化。
不能通过“局部化拆解复杂长生命周期变量”来触发高阶栈上分配。Java 中不存在真正意义上的“栈上分配”，HotSpot JVM 从未实现对象整体在栈上分配，所谓“栈上分配”只是逃逸分析成功后标量替换（Scalar Replacement）带来的等效效果。
标量替换不是手动拆对象
你写的代码仍是 new Point(x, y) 或 new User()，JIT 编译器在运行时确认该对象不逃逸、字段可独立访问后，才可能跳过对象创建，把 x、y 直接当作两个 int 局部变量处理——这些变量自然落在栈帧中，但 JVM 并未把对象“搬上栈”，而是根本没分配对象。
- 加
@Contended、用Unsafe、全字段final都不能强制标量化 - 手动把
Point拆成int x, int y反而可能干扰逃逸分析（如增加变量数量、改变控制流） - 所谓“长生命周期变量”本身与标量替换冲突：标量替换只适用于明确不逃逸、生命周期严格限定在方法内的对象
真正影响标量替换的关键是逃逸行为
只要对象引用离开当前方法作用域，标量替换立即失效。常见逃逸场景包括：
- 作为返回值
return user; - 被加入集合：
list.add(user); - 赋值给静态字段或成员变量
- 传入可能存储引用的方法（如任意非
private方法，除非内联成功）
哪怕只有一行 log.info("user: {}", user);，若 log.info 是公共方法且未被内联，也可能导致逃逸判定失败。
验证是否生效必须看 JIT 日志，不能靠猜测
仅观察 GC 减少或内存占用下降，无法确认标量替换发生。可靠方式是启用诊断参数：
-
-XX:+DoEscapeAnalysis -XX:+PrintEscapeAnalysis：查看逃逸分析结论 -
-XX:+EliminateAllocations -XX:+PrintEliminateAllocations：确认分配是否被消除 -
-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly（配合 hsdis）：检查生成的汇编中是否无对象分配指令
日志中出现 scalar replaced 或 eliminated allocation of 才算真正触发。
替代思路：用真正值语义的结构体风格编码
如果你的目标是避免堆分配、提升性能，更可控的方式是：
- 优先使用基础类型和不可变小对象（如
int[]替代ArrayList<integer></integer>） - 对短生命周期集合，考虑 GraalVM —— 它的部分逃逸分析更激进，能将
ArrayList字段级拆解到栈帧 - 避免为“优化”而强行重构：JIT 的标量替换是动态决策，稳定压测 + 日志验证比代码形态更重要
