Java GC通过可达性分析（从GC Roots出发）判断对象是否为垃圾，而非引用计数；新生代用复制算法（因对象存活率低），老年代用标记-整理（因对象存活率高）；GC由内存压力触发（如Eden满、老年代不足），非System.gc()强制执行。
Java里的垃圾回收（GC）机制，本质是JVM自动识别并回收堆中“不再可达”的对象所占内存的过程——它不靠引用计数，而靠从GC Roots出发的可达性分析；不是随时运行，而是按分代策略在Eden区满、老年代空间不足等时机触发。
怎么判断一个对象是不是“垃圾”？别信引用计数，看GC Roots能不能摸到它
很多人以为“没被变量引用了就是垃圾”，但Java不用引用计数法，因为循环引用（比如A.instance = B且B.instance = A）会让计数器永远不为0，导致内存泄漏。JVM实际用的是可达性分析：从一组固定的起点（GC Roots）出发，沿着引用链往下找。找不到路径的对象，才被标记为可回收。
常见的GC Roots包括：
-
虚拟机栈中正在执行的方法的局部变量（比如MyObject obj = new MyObject()里的obj） - 类的
static字段（如public static MyObject CACHE） - 方法区中的常量（如字符串常量池里的
"hello"） -
本地方法栈中JNI调用持有的对象
注意：被标记为不可达 ≠ 立刻被回收。如果对象重写了finalize()（已弃用），还可能被“复活”一次——但这属于历史包袱，现代代码应完全避免依赖它。
立即学习“Java免费学习笔记（深入）”；
为什么新生代用复制算法，老年代却用标记-整理？因为对象“活下来”的概率差十倍以上
这不是拍脑袋定的，而是基于“弱代假设”：98%的新对象活不过一次Minor GC。所以新生代（Eden + S0 + S1）用复制算法——只把活着的少量对象拷过去，清空原区域，快且无碎片。但老年代里对象平均存活几十次GC，复制成本太高，改用标记-整理，边清理边压缩，避免大对象分配失败。
典型配置与行为：
-
-XX:SurvivorRatio=8→ Eden : S0 : S1 = 8:1:1，意味着每次Minor GC后，最多约10%的存活对象能进入Survivor区 - 对象在Survivor区“熬过”一定次数（默认15次，由
-XX:MaxTenuringThreshold控制）就晋升到老年代 - 大对象（如超过
-XX:PretenureSizeThreshold的数组）会直接进老年代，跳过新生代——避免在复制过程中反复搬运
什么时候会触发GC？别迷信System.gc()，它只是个礼貌的请求
System.gc()不会立刻触发Full GC，甚至可能被JVM完全忽略（尤其在启用了-XX:+DisableExplicitGC时）。真实触发条件更依赖内存压力：
- Minor GC：当
Eden区满时必然发生，扫描新生代，存活对象移入Survivor或老年代 - Full GC：通常由老年代空间不足引发，但也可能因元空间（
Metaspace）耗尽、CMS并发失败、或显式调用System.gc()（未禁用时）触发 - 特别注意：频繁Minor GC但晋升很少，可能是
Survivor空间太小或MaxTenuringThreshold设得太低，导致对象“早熟”进老年代，埋下Full GC隐患
怎么看GC是否出问题？先加-XX:+PrintGCDetails -XX:+PrintGCTimeStamps，再盯住三件事
光看日志不够，得抓关键信号：
- Minor GC频率突增（比如从每5分钟1次变成每10秒1次）→ 检查是否有短生命周期对象暴增（如循环内new HashMap）
- 每次Minor GC后老年代使用率持续上升 → 对象晋升过多，可能是Survivor区溢出或对象本身生命周期变长
- Full GC耗时超过200ms或频繁发生 → 很可能有内存泄漏，用
jstat -gc确认YGC/FGC次数与耗时，再用jmap -histo或堆转储分析大对象来源
真正容易被忽略的点是：GC日志里显示“Allocation Failure”并不等于代码写错了，它只是说明Eden撑不住了——但背后到底是业务流量上涨、缓存没设上限，还是某个工具类偷偷持有了静态引用，得结合堆快照才能定位。别只盯着算法名字，要盯住你自己的对象怎么活、怎么死、又怎么赖着不走。
