如何理解Java的垃圾回收(GC)_标记清除与分代收集算法基础-java教程-PHP中文网

标记-清除算法先标记可达对象，再清除未标记对象内存，不移动对象但产生碎片；适用于老年代，现代JVM多作为Mark-Compact或G1的基础阶段。

如何理解java的垃圾回收(gc)_标记清除与分代收集算法基础

标记-清除算法到底在干啥

它不移动对象，只做两件事：先遍历所有可达对象并打标（从 GC Roots 出发），再扫一遍堆，把没被打标的对象内存直接清掉。

常见错误现象：OutOfMemoryError: Java heap space 频发，但 jstat 显示老年代使用率不高——很可能是碎片太多，大对象申请不到连续空间
适用场景：老年代回收（存活对象多，复制成本高），但现代 JVM 几乎不单独用它，而是作为 Mark-Compact 或 G1 的基础阶段
性能影响：标记阶段耗时与存活对象数正相关；清除阶段耗时与整个堆大小正相关；最致命的是不整理内存，必然产生碎片

为什么新生代不用标记-清除而用复制算法

因为绝大多数对象“朝生夕死”，Eden 区一满就触发 Minor GC，此时存活对象通常不足 10%，复制比标记+清除快得多，且天然无碎片。

参数差异：-XX:SurvivorRatio=8 表示 Eden : Survivor = 8:1（两个 Survivor 合计占 1 份），不是 8:1:1 —— 这个比例直接影响对象晋升阈值和 GC 频率
容易踩的坑：把 Survivor 区调太小（如设成 1），会导致存活对象频繁“躲不过去”直接进老年代，引发不必要的 Major GC
真实代价：复制算法要预留一块空闲区，所以年轻代实际可用内存只有理论值的约 90%（Eden + 1 个 Survivor），不是 100%

分代收集不是凭空分的，是靠对象年龄和晋升规则驱动的

对象每熬过一次 Minor GC，年龄 +1；默认到 15 岁（-XX:MaxTenuringThreshold=15）就进老年代——但这只是上限，实际可能早得多。

Java调试

通过 JDWP 实现 Java 远程调试：连接远程 JVM、设置断点、单步执行代码、查看变量值、获取调用栈。适用于需要调试远程 Java 应用、排查运行时状态、追踪代码执行流程的场景。术语注解 JDWP：Java Debug Wire Protocol，Java 调试有线协议（Java 远程调试底层通信协议） remote JVM：远程 Java 虚拟机 step through code：代码单步调试（步入 / 步过 / 步出调试） inspect variables：变量查看 / 变量检视 stac

下载

关键触发条件：Survivor 空间不够存下本轮存活对象时，JVM 会按年龄从小到大批量晋升，哪怕年龄远低于 15
典型误判：看到老年代增长快，第一反应是“内存泄漏”，其实可能是 SurvivorRatio 不合理或对象创建节奏突变（比如批量读文件生成临时 DTO）
兼容性注意：ZGC/Shenandoah 等低延迟收集器弱化了分代概念，但 HotSpot 默认仍是分代设计，-XX:+UseSerialGC 或 -XX:+UseG1GC 会影响分代行为是否启用

别被 System.gc() 欺骗，它不等于立即回收

System.gc() 只是建议 JVM 执行 GC，是否执行、何时执行、用哪个收集器，全由 JVM 自行决定。在生产环境调用它，基本等于给系统埋雷。

常见错误现象：本地测试时加了 System.gc() 看似有效，上线后完全失效，甚至因频繁请求 GC 导致 STW 时间飙升
真正可控的方式只有 JVM 启动参数：-XX:+PrintGCDetails -Xlog:gc*（JDK 10+）才能看清实际发生了什么
隐蔽陷阱：某些框架（如旧版 Netty、Log4j2 的某些配置）会隐式触发 System.gc()，需通过 -XX:+DisableExplicitGC 彻底屏蔽

分代和标记-清除都不是抽象概念，它们直接对应着堆内存的物理布局、对象生命周期的统计规律，以及每次 GC 日志里那几行看似枯燥的数字。真正卡住人的，往往不是算法本身，而是没意识到：对象能不能活过一次 GC，取决于你代码里引用的持有方式，而不是 new 出来的那一刻。