Java GC仅回收不可达对象，内存泄漏等问题仍需开发者干预；判断标准是GC Roots可达性；finalize已废弃，应使用Cleaner或try-with-resources；弱引用GC即回收，软引用内存不足时回收；收集器选择取决于延迟或吞吐量目标。
Java 的 GC 不会“自动解决所有内存问题”，它只负责回收不可达对象，而内存泄漏、频繁 Full GC、堆外内存失控等问题依然需要开发者干预。
GC 什么时候真正开始回收对象
对象是否被回收，唯一判断标准是「是否可达」——即从 GC Roots 出发能否找到该对象的引用链。常见的 GC Roots 包括：正在执行的线程栈帧中的局部变量、静态字段、JNI 引用、JVM 内部对象（如类加载器）等。
注意：finalize() 方法已被废弃（Java 9 起标记为 @Deprecated），不保证执行，也不应依赖它释放资源；Cleaner 或 try-with-resources 才是正确替代方案。
- 对象即使重写了
finalize()，也只可能被最多执行一次，且执行时机不确定 -
System.gc()仅是建议 JVM 运行 GC，不保证触发，生产环境应禁用 - 弱引用（
WeakReference）关联的对象，在下一次 GC 时就会被回收；软引用（SoftReference）则尽量保留到内存不足时
不同垃圾收集器对应用行为的实际影响
选择收集器不是看“最新”或“默认”，而是看延迟敏感度与吞吐量目标。例如：
立即学习“Java免费学习笔记（深入）”；
