局部变量不释放内存，而是随栈帧弹出瞬时消失；真正规避高频gc需对象不逃逸，以触发栈上分配或标量替换。
局部变量本身不“释放内存”，它只是栈帧的一部分；方法执行结束，栈帧整体弹出，变量连同其引用一并消失——这个过程瞬时、确定、无需 GC 干预。真正能规避高频 GC 的，是让被引用的对象也“别逃逸”，从而触发 JVM 或 Go 编译器的栈上分配或标量替换。
让对象真正留在栈上，不往外跑
只要对象未逃逸，JVM 的逃逸分析就可能将其分配在栈上，或进一步拆解为标量（如把 User 拆成 name、age 两个局部变量）。这时对象生命周期完全绑定栈帧，函数返回即彻底消失，GC 完全不感知。
- 避免返回对象引用：比如
return new User()或return list.get(0)，直接触发方法逃逸 - 别塞进静态容器：如
cache.put("key", user)、LIST.add(user)，属于全局逃逸 - 跨线程传递要警惕：往
ExecutorService.submit()传对象、写入ConcurrentHashMap、发到BlockingQueue，都算线程逃逸 - 闭包捕获要精简：Lambda 中只取需要字段，例如用
String name = user.getName(); () -> log(name)，而非捕获整个user
主动收窄作用域，帮编译器做判断
编译器依赖清晰的作用域边界来判定是否逃逸。代码写得松散，它就保守判逃逸；写得紧凑，栈分配成功率明显提升。
- 把大对象声明尽量靠近使用位置，不用时尽早结束其作用域（可用
{ }包裹一段逻辑） - 循环内避免反复
new：把StringBuilder sb = new StringBuilder()提到循环外并复用 - 方法参数能封装就封装：用
RequestContext ctx替代多个零散参数，减少局部变量槽数量，也降低逃逸概率
验证是否真没上堆，别靠猜
不看日志，永远不知道对象到底去了哪。高频 GC 压力是否缓解，得用数据说话。
- Java 启动加参数：
-XX:+PrintEscapeAnalysis -XX:+DoEscapeAnalysis -Xlog:gc+allocation=debug，观察关键对象是否不再出现在 Young GC 分配日志中 - Go 编译时加：
go build -gcflags="-m -l"，确认关键结构体没有escapes to heap提示 - 配合 JFR 抓取
Allocation Outside TLAB事件频次：下降明显，说明栈分配 / TLAB 命中率提高
轻量复用兜底，堵住漏网之鱼
即使逃逸分析生效，仍有部分对象因大小、动态性等原因必须堆分配。这时需组合手段巩固效果：
- 对高频临时对象（如 HTTP 请求缓冲区、序列化中间结构），用
sync.Pool或 NettyRecycler复用 - 预分配 slice 容量，避免
append触发多次底层数组扩容和拷贝 - 字符串拼接优先用
strings.Builder或bytes.Buffer，避免+运算符隐式生成多个临时字符串对象
