Java GC是基于可达性分析的分代回收系统，从GC Roots出发标记存活对象，新生代用复制算法，老年代用标记清除/整理，System.gc()仅建议不保证执行。
Java中的垃圾回收（GC）不是“定时清理内存”的简单任务，而是一套基于对象生命周期特征、分代管理、自动触发的内存自治系统——它不靠你写 free 或 delete，而是靠JVM持续扫描堆中“没人再找得到”的对象，并安全释放其内存。
GC怎么知道一个对象该被回收？看它还能不能被“找到”
JVM不数引用次数（引用计数法已被弃用），而是用可达性分析：从一组固定起点（GC Roots）出发，顺着所有引用链往下找。凡没被任何路径连上的对象，就是垃圾。
-
GC Roots包括：栈帧里的局部变量、类的静态字段、常量池中的字符串字面量、JNI本地引用 - 注意：循环引用（A引用B，B引用A）完全不影响判断——只要它们俩都和
GC Roots断开，立刻被回收 - 常见误判场景：对象刚被设为
null，但还在方法栈帧里；或被ThreadLocal、缓存、监听器意外持有，导致“明明不用了却死活不回收”
为什么堆要分新生代和老年代？因为99%的对象活不过一次GC
这不是为了炫技，而是基于弱代假设（Weak Generational Hypothesis）做的工程优化：新创建的对象极大概率短命，长期存活的是少数。
- 新生代（
Young Generation）：占堆约1/3，默认结构是Eden:S0:S1 = 8:1:1；每次Minor GC只清理Eden + 一个Survivor，存活对象复制到另一个Survivor - 老年代（
Old Generation）：长期存活对象晋升至此；回收用Mark-Sweep或Mark-Compact，暂停时间更长，即常说的Full GC - 踩坑点：
-XX:MaxTenuringThreshold设太小，对象过早进老年代；设太大，Survivor区反复拷贝浪费CPU；默认15，但多数应用调到6–8更稳
System.gc()有用吗？基本没用，还可能坏事
它只是向JVM发一个“建议”，不保证执行，也不控制时机。在生产环境频繁调用，反而会干扰JVM的自适应GC策略，甚至诱发不必要的 Full GC。
关于Objective
下载
本文档主要讲述的是关于Objective-C手动内存管理的规则；在ios开发中Objective-C 增加了一些新的东西，包括属性和垃圾回收。那么，我们在学习Objective-C之前，最好应该先了解，从前是什么样的，为什么Objective-C 要增加这些支持。有需要的朋友可以下载看看
立即学习“Java免费学习笔记（深入）”；
- 真正需要干预时，应通过JVM参数调优，例如：
-XX:+UseG1GC、-Xms2g -Xmx2g（避免堆动态扩容）、-XX:G1HeapRegionSize=1M（大对象直入老年代） - 验证GC行为，别靠
System.gc()，改用-XX:+PrintGCDetails -Xloggc:gc.log看真实日志 - 测试中想强制触发？可用
jcmd或 JMX 的VM.runFinalization MemoryPoolMBean，但仅限诊断
public class GCDemo {
public static void main(String[] args) {
// 创建大量短命对象，快速填满Eden
for (int i = 0; i < 100_000; i++) {
byte[] b = new byte[1024]; // 1KB对象
}
// 此处很可能触发Minor GC，但System.gc()不参与调度
System.gc(); // ← 这行几乎不影响实际GC时机
}
}
GC不是黑盒魔法，它是可观察、可推演、可调优的子系统。真正卡住你的，往往不是“GC有没有运行”，而是对象为何迟迟不被回收——检查引用链、审视缓存策略、留意线程上下文绑定，比背算法更重要。
