逃逸分析的核心判断依据是变量是否可能被函数外部访问。若变量生命周期超出当前函数作用域，如返回其地址、赋值给全局变量、传入goroutine或存入interface{}等，即判定为逃逸，必须堆分配。
Go 和 Java 都会通过逃逸分析决定对象分配位置，但“栈上分配”不是开发者手动指定的，而是编译器/运行时在满足严格条件时自动做的优化。它只发生在对象**完全不逃逸出当前函数作用域**的前提下。
逃逸分析的核心判断依据是什么
逃逸分析本质是静态分析：编译器（Go）或 JIT（Java）检查变量是否可能被函数外访问。只要存在任一以下情况，该变量就判定为“逃逸”，必须堆分配：
-
return &x—— 返回局部变量地址，调用方拿到指针后函数已返回，栈帧销毁，必须堆上存活 -
globalVar = x—— 赋值给包级变量、全局 map/slice 字段，意味着跨函数甚至跨 goroutine 可见 -
go func() { use(x) }()—— 传入新 goroutine，生命周期不再受当前函数控制 -
interface{}(x)或append(s, x)后该 slice 被返回 —— 接口类型擦除、切片底层数组可能被外部持有，导致间接逃逸
Go 中怎么验证某个变量是否逃逸
用 go build -gcflags="-m -l" 查看编译器决策。加 -l 禁用内联，避免干扰判断。输出中出现 ... escapes to heap 就表示逃逸发生。
例如：
func makeBuf() []byte {
buf := make([]byte, 1024)
return buf // 这里 buf 会逃逸：返回了 slice，底层数组可能被外部修改
}
而改成：
func useBuf() {
buf := make([]byte, 1024)
copy(buf, "hello")
// 不返回、不传指针、不存全局 —— buf 很大概率留在栈上
}
为什么 Java 的栈上分配比 Go 更少见
Java 的栈上分配（Scalar Replacement）依赖更激进的 JIT 优化，且仅适用于**完全不逃逸 + 所有字段可拆解**的对象。一旦对象被 synchronized、作为 monitor 锁、或被反射访问，JIT 就会放弃栈分配。
常见破防点：
-
new User().toString()—— 即使 User 没逃逸，toString是虚方法调用，JIT 无法 100% 确认行为，保守堆分配 -
synchronized(u) { ... }—— 锁对象必须有稳定内存地址，栈上对象地址随函数退出失效 - 对象被放入
ThreadLocal或静态容器 —— 显式跨线程/生命周期延长，直接逃逸
容易被忽略的关键事实
栈分配不是性能银弹。小对象堆分配开销极低，GC 在现代 JVM/Go 运行时中已高度优化；盲目追求栈分配反而可能因禁用内联（-l）、拆分结构体、或规避合法接口使用，导致更差的实际性能。真正该盯的是高频分配+大对象+长生命周期组合 —— 那些真正拖慢 GC 的逃逸点。
