Java中对象销毁由GC自动管理，无法手动触发；应显式关闭资源、避免强引用泄漏，弃用finalize()，改用Cleaner或PhantomReference；System.gc()仅是建议且影响性能。
Java里不能手动销毁对象，只能建议JVM回收
Java没有类似C++的delete或free，所谓“销毁”其实是让对象变成不可达状态，交由垃圾回收器（GC）后续处理。你调用obj = null、离开作用域、或清空集合引用，只是移除强引用——GC是否立刻回收、何时回收，完全不由你控制。
常见错误现象：
– 写了obj = null就以为内存立刻释放
– 在循环里反复赋值null试图“加速回收”
– 把资源清理逻辑全堆在finalize()里，结果发现它几乎不执行
- 真正该做的是：显式关闭
InputStream、Connection等实现AutoCloseable的资源，用try-with-resources最稳妥 - 避免在对象字段里长期持有大数组、缓存、监听器等强引用，容易引发内存泄漏
- 弱引用（
WeakReference）和软引用（SoftReference）适合做缓存，它们不影响GC判断对象可达性
finalize()方法已被弃用，别再依赖它做清理
从Java 9开始，finalize()被标记为@Deprecated(forRemoval = true)；Java 21已彻底移除支持（运行时忽略，编译期警告）。它不仅不可靠（不保证执行、不保证顺序、不保证及时），还会显著拖慢GC速度——因为带finalize()的对象要进F-Queue二次处理，至少延迟一个GC周期。
使用场景只剩极少数遗留系统兼容需求，新代码必须绕开。
立即学习“Java免费学习笔记（深入）”；
- 替代方案是实现
Cleaner（Java 9+）或PhantomReference，配合ReferenceQueue做异步清理 - 如果只是关文件/连数据库，直接在业务逻辑末尾调用
close()，或用try-with-resources -
Runtime.getRuntime().gc()不能触发finalize()执行，也不该在生产环境调用
System.gc()只是建议，实际效果取决于JVM参数和GC策略
调用System.gc()仅向JVM发出“现在可以考虑回收”的信号，是否执行、何时执行、回收多少，完全由当前GC算法（如G1、ZGC）和启动参数（如-XX:+DisableExplicitGC）决定。线上服务通常禁用显式GC，因为它可能引发STW（Stop-The-World）暂停，破坏响应稳定性。
性能影响明显：
– G1在显式GC时会强制进入Full GC流程（除非配置-XX:+ExplicitGCInvokesConcurrent）
– ZGC虽支持并发，但System.gc()仍会引入额外协调开销
- 测试环境偶尔用它辅助验证内存行为，但日志里看到
System.gc()调用，基本说明设计有问题 - 监控内存应看
java.lang:type=MemoryPoolMBean指标，而不是靠主动触发GC来“观察” - 若真遇到频繁OOM，优先检查对象引用链（用MAT分析hprof）、线程局部变量（
ThreadLocal未remove）、静态集合缓存
对象真的“没用了”，但内存还是不降？重点查这三处
GC后堆内存没回落，大概率不是GC失效，而是对象仍被隐式持有。最常踩的坑不在代码逻辑，而在框架和工具链的引用残留。
- Spring Bean默认单例，
@Autowired注入的对象生命周期绑定容器，不会随方法结束消失 - Logback/SLF4J的MDC（Mapped Diagnostic Context）用
ThreadLocal存map，忘记MDC.clear()会导致整个请求链路对象无法释放 - 使用
new Thread()但没显式setDaemon(true)，线程存活会阻止其所在类加载器卸载，间接锁住大量类元数据
复杂点在于：这些引用往往跨多层抽象，不dump堆、不走引用链分析，光看业务代码根本发现不了。一旦怀疑，直接用jmap -histo:live对比前后对象数量，再用jstack查线程状态，比猜快得多。
