Java采用垃圾回收机制（GC）自动管理堆内存，因手动释放易致内存泄漏或野指针，且复杂场景下难以保证正确性；GC通过可达性分析（从GC Roots出发标记不可达对象）回收内存，但无法处理堆外资源泄漏。
Java里不需要程序员手动释放内存，但正因如此，必须有垃圾回收机制（GC）来自动识别并清理堆中不再被引用的对象——否则新对象持续分配，老对象无人清理，很快就会触发 OutOfMemoryError。
为什么不能靠程序员自己 free 或 delete？
Java设计之初就放弃手动内存管理，根本原因不是“懒”，而是安全与工程效率的权衡：
- C/C++ 中漏掉一次
free→ 内存泄漏；多调一次 → 野指针崩溃；跨线程、异常分支、复杂生命周期下极难保证正确性 - Java 把对象创建全放在堆上（
new出来的都在堆），而栈帧生命周期由方法调用天然确定，无法覆盖对象长期存活场景（比如缓存、连接池、事件监听器） - 没有 GC，每个
List、String、HashMap的使用者都得约定“谁负责销毁”，协作成本爆炸
GC 是怎么知道哪个对象该回收的？
JVM 不用引用计数（它解决不了循环引用），而是用 可达性分析算法：从一组称为 GC Roots 的对象出发，顺着引用链往下找，所有找不到的对象，就是垃圾。
常见的 GC Roots 包括：
立即学习“Java免费学习笔记（深入）”；
-
虚拟机栈（各线程的栈帧）里的局部变量（如方法参数、
int a = new User()中的a） - 方法区里的类静态属性（
static User instance） - 本地方法栈中的 JNI 引用
- 正在同步锁住的对象（
synchronized(obj)中的obj）
举个典型误判场景：
public void handleRequest() {
byte[] buffer = new byte[1024 * 1024]; // 1MB
process(buffer);
buffer = null; // ✅ 主动断开引用，帮助GC尽早回收
Thread.sleep(5000); // 此时buffer已不可达，但若没置null，可能撑满Eden区再Minor GC
}不写 buffer = null 就一定出问题吗？
不一定，但依赖“作用域自然结束”是有风险的：
- JIT 编译器可能把局部变量优化进寄存器，不写
null时，GC 可能直到方法真正返回才判定不可达（尤其在 long 方法或 try-finally 中） - 如果方法里创建了大对象又长时间阻塞（如上面的
sleep），Eden 区可能提前填满，触发不必要的Minor GC，拖慢吞吐 - 更隐蔽的是：持有
InputStream、Connection等资源的对象，即使置null，若没调close()，底层堆外内存（Direct Buffer）或文件句柄仍不会释放——这属于“逻辑泄漏”，GC 无能为力
GC 解决的是“堆内对象引用关系”的自动清理，不是万能胶水。真正要稳，得理解：对象何时不可达、哪些资源不在 GC 范围、以及不同回收器（如 G1 vs ZGC）对停顿时间的实际影响——这些才是线上调优绕不开的硬点。
