Java中Major GC为何比Minor GC耗时显著更长？

首先要纠正一个关键误解：Minor GC根本不需要遍历整个对象图，这是两者耗时差异的核心原因之一，再结合回收算法、处理范围的不同，最终导致Major GC慢很多。具体拆解如下：

• Minor GC的遍历范围被卡表大幅缩小
  HotSpot虚拟机用**卡表（Card Table）**追踪老年代对年轻代的引用。卡表是个字节数组，每个元素对应老年代里一块512字节的内存区域，只要这块区域里的对象有指向年轻代的引用，就会被标记成“脏卡”。Minor GC时，只需要扫描这些脏卡对应的老年代对象，不用遍历整个老年代的对象图——这直接把遍历范围砍到了极小，耗时自然少。

• 回收算法的差异导致内存操作成本天差地别

  • 年轻代用复制算法：年轻代对象存活率极低（通常只有5%-10%），GC时只需把Eden区和一块Survivor区里的存活对象复制到另一块Survivor区，剩下的直接清空。复制的字节量极少，速度快得离谱。
  • 老年代用标记-整理/标记-清除算法：老年代对象存活率极高（一般70%以上），标记-清除会留内存碎片，后续分配大对象容易触发Full GC；标记-整理则要把所有存活对象往内存一端挪，腾出连续空间。老年代本身内存就大，存活对象的绝对字节数远多于年轻代——比如老年代4G，存活80%就是3.2G，年轻代1G存活10%才100M，移动3.2G的耗时肯定比100M多得多。

• Major GC的处理范围是整个堆
  Major GC（或Full GC）要处理整个Java堆：年轻代+老年代，还要顺带处理永久代/元空间的回收。遍历的时候得把老年代所有对象都过一遍，确定存活状态；而Minor GC只需要处理年轻代，加少量脏卡对应的老年代对象，处理范围差了好几个量级。

• 老年代对象的特性增加额外开销
  老年代里的对象大多是大对象、长生命周期对象，移动这类对象的成本更高；另外还有软引用、弱引用这类特殊引用，GC时要额外判断它们的存活状态，也会多耗点时间。

回到你的疑问：对象图遍历的时间差异是关键，内存移动的字节量也是核心原因，两者共同造成了Major GC的耗时远超Minor GC。你之前误以为Minor GC要遍历整个对象图，这是最主要的误解——卡表的存在直接帮Minor GC省掉了遍历整个老年代的工作量。

内容的提问来源于stack exchange，提问作者Alevinevich