Java局部变量生命周期为“栈上生、栈上灭”，方法调用时入栈，返回时自动销毁，不参与GC；优化核心是匹配实际使用时长，避免误入堆、善用作用域块、适时置null、借助逃逸分析实现栈上分配。
Java 局部变量的生命周期短、确定性强，本质是“栈上生、栈上灭”——方法调用时入栈，方法返回时自动销毁，不参与垃圾回收。优化关键不在手动干预，而在于让变量的“活法”匹配它的实际使用时长：该早退就早退，该复用就不乱new，该隔离就用块封住。
局部变量天生在栈上，但别让它意外拖进堆里
基础类型（int、boolean）和轻量引用（如字符串字面量、小范围Integer）默认分配在栈帧的局部变量表中，访问快、释放零成本。但以下写法会让它“被迫上堆”，增加GC负担：
- 循环内反复 new StringBuilder → 改为方法内单例复用，或用 try-with-resources + StringBuilder.clear()
- 用 Integer.valueOf(128) 代替 int → 超出 [-128,127] 缓存范围会触发堆分配，能用基本类型就不用包装类
- 方法开头就 new 一个大 byte[]，但只在末尾用 → JVM 会在栈帧创建时预留空间，浪费栈容量且可能触发 StackOverflowError
用代码块主动收口，让变量“用完即走”
一对 {} 不仅是逻辑分组，更是作用域边界。把临时对象、中间结果、资源操作限定在块内，能让变量在块结束时立即不可见，减少栈帧占用和命名冲突：
- 数据库查询后立刻关闭 ResultSet，相关变量（如 PreparedStatement、Connection）全包在块里
- JSON 解析生成的 Map 或 List，只在处理阶段需要 → 块内声明，块外无法误用
- 多个并行处理段都用 temp、i 等通用名 → 各自用独立块封装，互不干扰
注意：块不宜嵌套超过两层，更不能替代方法拆分；JVM 栈管理已很高效，只为“省几个字节”加块意义不大。
立即学习“Java免费学习笔记（深入）”；
长方法里显式置 null，帮 GC 提前识别“已弃用”
局部变量超出作用域自然消失，但复杂控制流（多重 if/else、异常分支、提前 return）可能导致编译器保留引用槽位。对大对象引用（如 byte[]、缓存 Map、第三方 SDK 返回的大结构体），主动切断更可靠：
- 方法中加载了 10MB 缓存数据，后续 80% 逻辑不再依赖 → 在使用完毕后立即赋值为 null
- 循环迭代中复用同一对象实例 → 每次迭代结尾将前次引用置 null，避免被编译器优化“延长存活”
- 注意：JDK 8u60+ 对隐式 null 已较智能，但显式置 null 在异常路径多、分支深的场景下仍具确定性价值
逃逸分析不是玄学，是可验证的栈上分配开关
JVM（HotSpot，JDK 8u60+ 默认开启）会通过逃逸分析判断对象是否“逃出”当前方法：没逃逸，就可能栈上分配甚至标量替换（拆成字段直存栈帧）。提升命中率的关键是“不越界”：
- 对象不返回给调用方（不 return、不 throw）
- 不赋值给 static 字段或实例字段
- 不传入未知方法（如第三方库 API、反射调用）
- 字符串拼接优先用 StringBuilder，字面量拼接走常量池 → 避免重复堆分配
可通过 -XX:+PrintGCDetails 观察年轻代分配量是否下降，或配合 JFR 查看 “Allocation Reused” 指标确认栈上分配效果。
