局部变量不释放内存，而是随栈帧销毁自然消失；关键在于避免对象逃逸，使jvm/go编译器能将其分配在栈上，绕过gc。需规避返回引用、静态存储、跨线程传递、过度闭包捕获，并精简作用域、验证逃逸分析效果，辅以对象池兜底。
局部变量本身不“释放内存”，它只是栈帧的一部分；栈帧销毁时，整个空间（含局部变量槽和其中的引用）被整体弹出，引用自然消失——这才是你该抓住的天然红利。关键不是等它销毁，而是让引用指向的对象也别逃逸，从而让 JVM 或 Go 编译器有机会把对象本身也放在栈上，彻底绕过 GC。
让对象真正“待在栈里”，不往外跑
只要对象没逃逸，JVM 的逃逸分析就可能触发栈上分配（Stack Allocation）或标量替换（Scalar Replacement）。这时对象生命周期完全绑定栈帧，函数一返回，对象连同栈帧一起消失，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 代替 User u, Order o, Item i 多个参数，减少局部变量槽数量，也降低逃逸概率
验证是否真的“没上堆”，别靠猜
不看日志，永远不知道对象到底去了哪。高频 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 命中率提高
配合轻量复用，堵住漏网之鱼
即使逃逸分析生效，仍有些对象因大小、动态性等原因必须堆分配。这时别硬扛 GC，用最小成本兜底。
- 对固定结构小对象（如 HttpHeader、MetricTag），用 ThreadLocal
> 实现无锁池化 - HTTP 请求中频繁创建的 byte[] 或 ByteBuffer，优先走 ByteBufferPool 或 Netty 的 PooledByteBufAllocator
- 所有归还池的对象，必须显式重置状态（清空字段、置 null 引用、还原 flag），否则下一次获取就是脏数据
