java变量生命周期需精准匹配使用场景：局部变量就近声明、用完即弃；实例变量随对象存在，避免内存泄漏；静态变量慎用，防止资源累积；资源型变量必须显式释放或用try-with-resources。
Java 变量声明不是写完就完事，关键在“什么时候用、用多久、谁在管”。生命周期不清晰，轻则编译报错、空指针，重则内存泄漏、状态混乱。真正高效的做法，是让变量的声明位置、作用范围和存活时间三者严丝合缝。
局部变量：用完即走，别拖泥带水
方法内、循环里、if 块中定义的变量，只该活在它真正需要的地方。
- 在最靠近使用处声明，避免提前声明却迟迟不用——比如不要在方法开头一口气声明所有变量
- 循环变量（如 for (int i = 0; i ）必须在 for 括号内声明，确保每次迭代都是干净的新变量
- 代码块内声明的变量（如 { String tmp = "abc"; ... }）出块即失效，不可跨块复用，也不必手动置 null
- 未初始化就访问会直接编译失败，这是保护机制——别依赖“后面会赋值”，声明即初始化更安全
实例变量：跟着对象走，别让它背不动的锅
定义在类里、方法外，没加 static 的变量，属于每个对象自己的状态。
- 不需要显式初始化就有默认值（int→0，Object→null），但业务上建议在构造器或初始化块中明确设初值
- 避免在实例变量中长期持有大对象或上下文引用（如 Activity、Context、Handler），尤其在 Android 或 Web 应用中容易引发内存泄漏
- 若某个字段仅在特定方法中临时使用，考虑改用局部变量；若多个方法共用且确属对象状态，再升为实例变量
- 同名局部变量会遮蔽实例变量，用 this.field 显式访问可读性更好，也避免误操作
静态变量：全局共享，但不是万能筐
static 变量属于类，加载即生、卸载才灭，几乎贯穿整个 JVM 生命周期。
- 慎用静态集合（如 static List
cache = new ArrayList(); ），它不会随对象回收，容易越积越多 - 避免静态引用 Activity、Fragment、View 等组件，这类引用会阻止 GC 回收整个界面栈，是内存泄漏高发区
- 多线程环境下修改静态变量必须同步（synchronized 或 Atomic 类），否则可能产生脏数据
- 配置类常量优先用 public static final，编译期内联，安全又高效；普通静态变量除非真需全局共享，否则尽量不用
资源型变量：开完就得关，不能靠运气
InputStream、Connection、FileChannel 等实现了 AutoCloseable 的变量，生命周期不仅关乎内存，更关乎系统资源。
- 优先用 try-with-resources 语法，JVM 保证退出时自动 close，比 finally 手动关更可靠
- 即使声明为局部变量，也不能假设“方法结束就释放”——流、连接、锁等资源必须显式释放，否则可能耗尽数据库连接池或句柄
- 不要把资源型变量声明为静态或实例变量，除非你有完整的生命周期管理策略（如连接池）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
