Java中类生命周期由JVM自动管理，对象生命周期需开发者主动干预：控制创建方式、管理引用可达性、显式释放资源。
Java 中类与对象的生命周期管理是两个不同层级的问题：类的生命周期由 JVM 类加载机制控制，对象的生命周期则由开发者编码习惯与 JVM 垃圾回收协同决定。关键不在于“能不能管”，而在于“哪些环节必须主动干预”。
类的生命周期：JVM 自动管控，但可影响时机
类从被加载（Load）→ 验证（Verify）→ 准备（Prepare）→ 解析（Resolve）→ 初始化（Initialize）→ 使用 → 卸载（Unload），全程由类加载器和 JVM 控制。
- 类只有在首次主动使用时才触发初始化（如 new 实例、调用静态方法、访问静态字段等），不是一加载就执行 static 块
- 类卸载极为罕见，仅当其 ClassLoader 被回收且该类无任何活跃实例或引用时才可能发生（常见于 OSGi、热部署场景）
- 开发者能做的主要是：避免静态集合长期持有对象引用；慎用
Class.forName("xxx")触发意外初始化；通过模块化（Java 9+）或自定义 ClassLoader 精细控制加载边界
对象创建阶段：控制入口，减少冗余
对象诞生于堆内存，但它的“出生方式”直接影响后续管理成本。
- 优先用静态工厂方法（如
LocalDate.of()、Optional.empty()）替代 new——可复用实例、命名清晰、支持返回子类型 - 高频短命对象（如日志事件、DTO）考虑对象池（如 Apache Commons Pool），避免 GC 频繁压力
- 避免在循环内 new 相同类型对象，尤其大对象；改用复用或预分配策略
- 构造函数保持轻量，不执行 I/O、网络、复杂计算；重逻辑移至初始化方法或 Builder 中
运行中引用管理：防止泄漏的核心战场
对象是否存活，取决于它是否“可达”。强引用未断，GC 就不会碰它——哪怕你心里觉得“它早该死了”。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
- 静态集合（
static Map、static List）是泄漏高发区：存入后务必配对 remove，或改用WeakHashMap - 监听器、回调、线程本地变量（
ThreadLocal）用完必须显式清理（remove()），否则绑定线程不结束，对象就一直挂着 - 缓存场景按需选用引用类型：软引用（
SoftReference）适合内存敏感缓存；弱引用（WeakReference）适合关联映射（如监听器与目标对象） - 长生命周期对象（如 Activity、Service）持短生命周期对象（如 Context、Listener）时，优先用弱引用或静态内部类 + Handler 防止隐式强引
资源释放与终结：不能依赖 finalize
持有文件、Socket、NIO Buffer、JNI 句柄等外部资源的对象，必须显式释放——GC 不保证及时性，更不保证执行顺序。
- 实现
AutoCloseable接口，配合try-with-resources语法，确保异常下仍关闭 - 提供明确的
close()或shutdown()方法，并在 JavaDoc 中强调“必须调用” - 必要时用
Cleaner（替代已废弃的finalize）注册清理逻辑，用于释放 native 资源 - 不要在
finalize中做任何关键清理——它不被保证执行，也不被保证何时执行
类的生命周期基本交由 JVM，对象的生命周期却始终掌握在你写的每一行引用、每一次注册、每一个 try 块里。真正有效的管理，不是等 GC 来收拾残局，而是让对象从诞生起，就清楚自己该活多久、跟谁有关、怎么退场。
