先聊聊，JVM到底是干嘛的？

说实话，JVM就是个把Java字节码变成机器码的翻译官。

不过它还有个副业——内存管理。

这玩意儿要是不好好收垃圾，程序迟早会崩溃。

所以今天咱们就八卦一下JVM的垃圾收集算法和收集器。

分代收集——先把世界划分成几块地

老规矩，堆被划成新生代、老年代。

新生代里啥dou活不久，老年代里对象往往Neng活个几天甚至geng久。

这划分的好处是：不同的“寿命”用不同的算法回收，geng省事儿。

新生代：复制算法

复制算法简直就是搬家大法师。

把活着的对象全搬到另一块空闲区，然后把原来的那块全清空。

优点？一次性清理，STW时间短；缺点？需要两块等大的空间。

-XX:+UseParNewGC：开启并行版的新生代复制收集器。

老年代：标记-清除 & 标记-整理

先说标记-清除，它先遍历所有根对象，把Neng到达的标记为“活”。

然后一刀切把未标记的全给扫掉。

听起来挺爽，但后果是产生大量碎片。

初始标记:

表示未被垃圾收集器访问过显然在可达性分析刚开始阶段，所有对象dou是白色的。若在分析结束阶段仍然是白色对象，即代表不可达。

重新标记:

并发标记期间用户线程继续跑，会导致标记状态变化，需要再来一次小规模的修正。这个阶段停顿时间比初始标记稍长，但远远比并发标记短。

并发清理:

-XX:+CMSParallelRemarkEnabled：在重新标记的时候多线程执行，缩短STW；

老年代：标记-整理

跟Mark‑Sweep一样先标记，但不直接清除，而是把存活对象压缩到一端，再一次性回收尾部空间。

这样碎片问题基本解决了只是搬运成本geng高点儿。

主流收集器大盘点 - Serial 收集器

-XX:+UseSerialGC：单线程收集器，Zui经典、Zui省CPU，却会STW整个应用进程。

适合单核机器或对吞吐量要求不高的小程序。

- Parallel Scavenge& Parallel Old

-XX:+UseParallelGC：多线程新生代复制收集器，以吞吐量为目标。

-XX:+UseParallelOldGC：对应老年代的多线程标记-整理实现。

说白了就是Serial 的兄弟版，只不过开了好多条“手”，抢CPU资源hen激烈。对CPU敏感。

- CMS

-XX:+UseConcMarkSweepGC：启用CMS，是第一款真正意义上的并发收集器。目标是Zui小化停顿时间。

-XX:CMSInitiatingOccupancyFraction=92：当老年代使用率达到92%时触发CMS。

-XX:+CMSParallellnitialMarkEnabled：表示在初始标记的时候多线程执行，缩短STW。

-XX:+CMSParallelRemarkEnabled：在重新标记的时候多线程执行，缩短STW；

- G1

-XX:+UseG1GC：面向大内存服务端，用Region 分区管理堆，每次回收局部Region，以控制停顿目标。

-XX:MaxGCPauseMillis=200：给G1一个暂停时间上限，让它自行调配回收力度。

-XX:G1HeapRegionSize=8m：设置Region大小，一般8~32M比较合适。

-XX:ConcGCThreads=4：并发GC线程数，可根据CPU核数调节。

细说几个常用参数——别只kan名字，要懂背后干啥子事儿！ # 新生代参数

-Xmn 512m  # 手动指定新生代大小，太小会频繁Minor GC；太大又占用老年代空间。

-XX:SurvivorRatio=8  # Eden : Survivor = 8:1:1，一般默认够用。

-XX:NewRatio=2  # 老年代/新生代比例，大约 2:1 时效果Zui佳。

-XX:ParallelGCThreads=4  # 并行复制时使用多少条线程。

# 老年代参数 & Full GC 控制

-XX:+UseCMSInitiatingOccupancyOnly  # 只使用设定阈值触发CMS，不自动调节。

-XX:CMSFullGCsBeforeCompaction=5  # 每5次Full GC后Zuo一次压缩整理。

-XX:+UseCMSCompactAtFullCollection  # Full GC之后Zuo压缩整理。

-XX:ConcGCThreads=4  # 并发阶段使用多少条GC线程。

"三色" 标记法——别怕，这名字其实hen形象！

白色： 未被遍历过对象可NengYi经死亡；

灰色： Yi遍历但其子对象还未遍历；

黑色： 自身以及所有子对象douYi遍历完毕，是安全存活对象；

CMS 与 G1 的对比——选哪个？别慌，我帮你拆解下！

CMS： 低延迟、适合交互式系统。但容易产生碎片，需要定期Full GC 或者开启压缩；适合对响应时间极度敏感的Web服务。

G1： 面向大堆内存，Ke以预估停顿时间，geng易调优；但是在极端低延迟场景下可Neng仍有抖动。适合金融、电商等需要兼顾吞吐与延迟的大型后台系统。

TIPS： Ru果你的机器只有8核以内且堆内存不超过6G，用Parallel足矣；Ru果追求毫秒级响应，用CMS或者G1dou行，不过得结合监控数据再细调。

Amdahl 定律和 GC 调优——别忘了硬件瓶颈！

"啊哈"，hen多人总以为只要改改参数就Neng飞起，其实CPU占比才是真正决定上限的关键。Ru果你的应用本身CPU占用Yi经接近100%，再怎么调GC也只Neng让你离峰值geng近一点而Yi。所以先搞好业务代码，再去玩调参，这才是王道呀！

"我到底该怎么选"——实战经验速递

① 小型工具 / 单机脚本： -Xmx256m -Xms256m -XX:+UseSerialGC

② 中等流量 Web 服务： -Xmx4g -Xms4g -XX:+UseParallelGC -XX:ParallelGCThreads=8

③ 高交互电商站点： -Xmx8g -Xms8g -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSCompactAtFullCollection

④ 大数据平台 / 长连接服务： -Xmx16g -Xms16g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:G1HeapRegionSize=16m

end of story—祝你玩转 JVM 垃圾回收 🎉

---