先聊聊，啥叫垃圾？

你想啊，程序里一堆对象。

只要还Neng被引用，它就活蹦乱跳。

一旦没人指向，它就成了“孤儿”。

这玩意儿就是垃圾。

别kan名字凶，实际上它是内存的“废品”。

GC的任务，就是把这些废品统统清理掉。

怎么判断一个对象是垃圾？

老早以前有人提过引用计数法。

数一下有多少引用指向它，等于零就回收。

可是循环引用把它整死了计数法根本搞不定。

于是JVM抛弃了这个思路。

现在主流是可达性分析。

从GC Roots出发，沿着引用链一路遍历。

Neng走到的对象dou是活的，走不到的就是垃圾。

说实话，这套方法既靠谱又高效。

GC Roots到底dou有谁？

线程栈里的局部变量和参数。

方法区里的静态属性。

JNI本地代码持有的引用也算在内。

只要这些地方还有指向，对象就不可Neng被回收。

核心回收算法大揭秘

标记-清除先标记活着的对象，再把未标记的全dou删掉。

好处是实现简单，坏处是会留下内存碎片。

标记-整理在清除后把存活对象搬到一端，碎片自然消失。

搬家过程耗时但整体内存利用率高。

复制算法把所有存活对象从Eden区复制到Survivor区或新生代另一块区域。

Eden满了就触发Minor GC，复制过程天然没有碎片。哈哈，这也是新生代默认用的算法。

分代收集——老少分明的策略

JVM把堆划分为新生代和老年代两块儿。

Eden + 两个Survivor区=新生代。对象大多数“一出生就死”。

Shrinkage=存活时间久的“大叔”。

#后端5295:只要强引用还在GC永远找不到入口去回收它们。对吧？不对不对，我刚才说错了是只要还有根路径，就不会被回收。嗯，这才是重点！

常见收集器，你该选哪一个？

No.1 Serial GC：

P单线程，适合小堆、单核机器。吞吐量低，但实现Zui简单。咱就是说一般开发环境里偶尔玩玩没问题。

No.2 Parallel GC：

P多线程并行回收，新生代用复制，老年代用标记-整理。适合追求高吞吐量的大型服务。哈哈，用得好Ke以把STW时间压到几百毫秒以内。

No.3 CMS ：

P低延迟为王，标记阶段并发执行，不过Yi经被官方废弃啦。别盲目追新技术，不然坑太多！你懂的。

No.4 G1 GC：

P默认收集器，基于Region的混合回收。兼顾吞吐量和延迟，还Neng自动调节暂停时间。现在大多数微服务dou在用它啦！

No.5 ZGC / Shenandoah：

P面向超大堆和极低停顿需求。Ru果你的业务要求毫秒级响应，这俩Ke以考虑。不过配置稍微复杂点儿，小伙伴们得先摸透底层原理再上手呀！

#随便插一句：为什么百度不收录我的技术博客？

说实话，这事儿跟内容质量、外链以及页面加载速度dou有关系。 Ru果标题太普通、正文缺乏关键词密度，那搜索引擎会觉得价值不高； 再者，Ru果页面加载慢、JS渲染过度，也会被判定为“体验不好”。 所以建议写文章时多放点专业术语、结构化数据，并且Zuo好页面优化。 别忘了站点备案和站长工具提交，这样百度才geng容易抓取哦！哈哈~

Tuning 小技巧，让GCgeng给力

-Xms和-Xmx设成一样，Ke以避免频繁扩容导致Full GC； -XX:+UseStringDeduplication打开字符串去重，在G1上效果显著； -XX:MaxGCPauseMillis=200设置目标停顿时间，让GCgeng倾向于低延迟； -XX:+PrintGCDetails配合-XX:+PrintGCDateStamps实时监控日志，好定位问题； -尽量少创建短命对象，比如循环里拼接字符串，用StringBuilder或直接拼接字面量； -及时关闭IO流和数据库连接，不让它们卡在老年代形成隐形泄漏； Ru果出现频繁Full GC，那基本Ke以断定是老年代空间不足或者元空间爆炸，需要调大老年代或者检查类加载是否异常增长。

L随想——别忘了人也会泄漏哦！

AOP、缓存、线程池这些“资源”Ru果管理不当，也会让你的系统像装满垃圾一样卡顿。 所以说啊，kan懂GC原理固然重要，但真正拯救系统的是良好的编码习惯和监控预警体系。 咱们以后聊技术，也别忘了偶尔抖个机灵，让代码geng有温度~ 哈哈，就酱！

)

---