垃圾分类真相：为何大多数回收都被浪费了

看到没？这已经不是“我写了个大对象结果GC卡了一下”这种程度的问题了，这是苹果这种量级的公司都压不住的系统性问题。你要知道，他们干的还是“密码管理”这种活——高频、敏感、延迟敏感、请求量巨大的线上服务。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

苹果最近写了一篇很轻描淡写的技术迁移文：他们把密码管理服务从Java搬到了Swift，性能一飞冲天。

写得很克制，结果信息量爆炸。

看完只想说一句：原来不是我们写得不行，是垃圾回收（GC）这条路本身就有坑。

苹果点破了那个所有人都不想说的真相

文里有一段话反复看了三遍，给你摘出来：

我们先没急着换语言，先是把 JVM 能调的参数都调了。 用了 G1 GC，这个 GC 比老一代强很多：能控制暂停时间、有分区、还能并行干活。 ——但！在高并发场景下，GC 还是难搞：一来会有长暂停，二来性能开销会顶上来，三来要想让它适配各种各样的业务，就得一直细调、细调、再细调。

看到没？这已经不是“我写了个大对象结果GC卡了一下”这种程度的问题了，这是苹果这种量级的公司都压不住的系统性问题。

你要知道，他们干的还是“密码管理”这种活——高频、敏感、延迟敏感、请求量巨大的线上服务。

“讨厌GC”其实很多人想说但不敢说

大家对 GC 的情绪也不算中立的。

在移动端上这一点更明显： 你认真滚动一个 Flutter 界面，动画正丝滑，GC 突然说：该洗一洗内存了——咔！掉帧。

你用户根本不在乎你在做什么回收算法，只知道：“怎么卡了一下？”

以前总觉得： “行，客户端容易卡是因为 UI 线程比较娇贵；但在服务器上，总有 20ms 的网络延迟，GC 卡个十几毫秒，应该没人能看出来吧？”

——苹果这篇文直接告诉你：想多了。

它不是“偶然卡一下”的问题，是你量一旦上来了，GC 这套机制本身就变成了阻力。 一个密码管理服务，全球几百万、几千万设备，分分钟都是对象分配和释放，GC 的成本就不再是“小数点后第二位”的事了。

先回忆一下：GC 最原始的样子有多粗暴

一开始的垃圾回收很朴素：停世界，涂颜色。

这种叫标记-清除，思想简单，工程实现也比较直观。 问题也很直观：你得停。

游戏里就是卡顿，前端里就是掉帧，后端里就是尾延迟蹿上去。

于是这一停世界，就让几十年的语言设计师、JVM 工程师、runtime 大神们开始拼命“降卡顿”。

然后我们走上了一条“工程师自我感动”的路

于是就有了各种“听起来很高级”的GC：

听上去是不是很厉害？

但苹果那句话其实已经说透了：它们都没解决根问题，只是把大坑切成了很多小坑。

GC 还是得暂停的，只是从“一次停很久”变成了“停很多次、每次短一点”。 而且更要命的是：你分区、你分代，其实都是在给 runtime 自己加开销。在高负载场景下，这个开销很快就会浮出来。

所以苹果最后说：我们还是换语言吧。

你以为苹果会秒选 Swift？他们也犹豫过

他们自己写的：我们其实看了好多语言，不是那种“苹果出品必用 Swift”那种拍脑袋。

最后还是落到了 Swift，核心原因其实就一个：它不用垃圾回收。

Swift 用的是ARC（Automatic Reference Counting，自动引用计数）。

它不搞“我过一阵子再来看看谁还能活着”这一套， 它搞的是：“你被引用+1，你不被引用-1；你变成0，我立刻干掉你。”

这个思路有两个惊人的优点：

这，就是为什么在 UI 场景下，ARC 体验肉眼可见地更顺。

苹果现在的说法是：同样的爽感，在服务器上也能拿到。

当然，ARC 也不是天使

你要是只说“GC 有暂停，ARC 没暂停”，那就太不讲究了。

ARC 最大的雷，大家都知道：循环引用。

A 引用 B，B 引用 A，两个都有人爱，引用计数永远不会变成 0， 但其实外面没人能走到它们了——这就是一坨泄露。

Swift 的做法是： 给你弱引用（weak）、unowned这种不参与计数的引用， 你自己在该用的地方用，不该用的地方别用。

也就是说：ARC 不是傻瓜式的。你还是得懂点内存生命周期，不然你也能写出一锅烂。

不过话说回来，GC 也不是傻瓜式的。

你要是一直往一个全局 List 里塞对象、从来不删，GC 也清不了你。 本质上还是：语言帮你减了 80% 的内存活，剩下 20% 还是你自己得有脑子。

所以问题就变成了：