Java必须有垃圾回收，因为堆内存动态分配且生命周期不可预测，手动管理易导致内存泄漏或悬空引用；JVM通过可达性分析自动判断对象存活，而操作系统仅在进程退出时回收内存，无法满足长期运行需求。
为什么Java必须有垃圾回收，而不是靠程序员手动释放？
因为Java堆内存的分配是动态且不可预测的——你无法在编译期知道某个方法会创建多少对象、生命周期多长、是否跨线程共享。如果像C++那样要求new配delete，光是处理异常分支、提前return、循环引用这些场景，就足以让90%的业务代码出现OutOfMemoryError或悬空引用。
更关键的是：栈帧和局部变量的生命周期由JVM自动管理（方法结束即弹栈），但堆上对象的“存活”只取决于是否能从GC Roots触达。这个判断逻辑太复杂，人写不出稳定规则，只能交给JVM实时扫描。
不回收会怎样？不是还有操作系统兜底吗？
操作系统确实会在进程退出时回收全部内存，但Java应用往往要连续运行数月甚至数年。不及时回收的后果不是“等崩溃再说”，而是：
-
OutOfMemoryError: Java heap space——堆满后连新对象都分配不了，哪怕物理内存还剩10GB - 频繁触发Full GC，STW（Stop-The-World）时间飙升，接口P99延迟从20ms跳到2s+
- 内存碎片化严重，大对象分配失败，触发本可避免的压缩式回收
这不是理论风险。线上常见案例：一个缓存Map没设过期策略，Key是未重写hashCode()的临时对象，3天后占满老年代。
立即学习“Java免费学习笔记（深入）”；
System.gc()到底有没有用？什么时候该调？
System.gc()只是向JVM发一个建议，HotSpot默认直接忽略它；开启-XX:+ExplicitGCInvokesConcurrent后，才可能触发CMS或G1的并发回收——但依然不保证立即执行。
本文档主要讲述的是关于Objective-C手动内存管理的规则；在ios开发中Objective-C 增加了一些新的东西，包括属性和垃圾回收。那么，我们在学习Objective-C之前，最好应该先了解，从前是什么样的，为什么Objective-C 要增加这些支持。有需要的朋友可以下载看看
真正需要手动干预的场景极少，仅限于：
- 大型离线任务结束前（如ETL批处理），显式触发一次回收，避免残留对象影响后续子任务
- 嵌入式或资源受限环境（如Android低内存设备），配合
Runtime.getRuntime().freeMemory()做粗略水位判断
绝大多数Web服务中调用System.gc()，只会增加GC线程调度开销，还可能打断G1的预测性回收节奏。
为什么引用计数法被彻底放弃？循环引用真那么常见？
不是“常见”，而是“根本防不住”。哪怕你没写objA.ref = objB; objB.ref = objA;，日常开发中大量隐式循环引用：
- 内部类持有外部类引用（
new Thread(() -> { doSomething(); })里捕获的局部变量） - 监听器注册后忘记
removeListener()，导致Activity/Fragment无法释放（Android典型OOM源） - ThreadLocal的
staticMap强引用Value，Value又反向引用Thread，线程池复用时泄漏
可达性分析法绕开了计数逻辑，直接从GC Roots（栈帧变量、静态字段、JNI句柄等）出发做图遍历，天然免疫这类问题——代价是必须STW做快照，但这是可接受的权衡。
真正容易被忽略的点是：GC只管堆内对象，finalize()已废弃，Cleaner也不再推荐；文件句柄、数据库连接、DirectByteBuffer这些堆外资源，仍需开发者显式关闭——垃圾回收不是万能的免责牌。
