看到没？这已经不是“我写了个大对象结果GC卡了一下”这种程度的问题了，这是苹果这种量级的公司都压不住的系统性问题。你要知道，他们干的还是“密码管理”这种活——高频、敏感、延迟敏感、请求量巨大的线上服务。
苹果最近写了一篇很轻描淡写的技术迁移文：他们把密码管理服务从Java搬到了Swift，性能一飞冲天。
写得很克制，结果信息量爆炸。
看完只想说一句：原来不是我们写得不行，是垃圾回收（GC）这条路本身就有坑。
苹果点破了那个所有人都不想说的真相
文里有一段话反复看了三遍，给你摘出来：
我们先没急着换语言，先是把 JVM 能调的参数都调了。 用了 G1 GC，这个 GC 比老一代强很多：能控制暂停时间、有分区、还能并行干活。 ——但！在高并发场景下，GC 还是难搞：一来会有长暂停，二来性能开销会顶上来，三来要想让它适配各种各样的业务，就得一直细调、细调、再细调。
看到没？这已经不是“我写了个大对象结果GC卡了一下”这种程度的问题了，这是苹果这种量级的公司都压不住的系统性问题。
你要知道，他们干的还是“密码管理”这种活——高频、敏感、延迟敏感、请求量巨大的线上服务。
“讨厌GC”其实很多人想说但不敢说
大家对 GC 的情绪也不算中立的。
在移动端上这一点更明显： 你认真滚动一个 Flutter 界面，动画正丝滑，GC 突然说：该洗一洗内存了——咔！掉帧。
你用户根本不在乎你在做什么回收算法，只知道：“怎么卡了一下？”
以前总觉得： “行，客户端容易卡是因为 UI 线程比较娇贵；但在服务器上，总有 20ms 的网络延迟，GC 卡个十几毫秒，应该没人能看出来吧？”
——苹果这篇文直接告诉你：想多了。
它不是“偶然卡一下”的问题，是你量一旦上来了，GC 这套机制本身就变成了阻力。 一个密码管理服务，全球几百万、几千万设备，分分钟都是对象分配和释放，GC 的成本就不再是“小数点后第二位”的事了。
先回忆一下：GC 最原始的样子有多粗暴
一开始的垃圾回收很朴素：停世界，涂颜色。
程序停一停，谁也别动从“根”（栈、全局、寄存器）开始，把能走到的对象都标成“活的”其他的都当垃圾，一把丢掉这种叫标记-清除，思想简单，工程实现也比较直观。 问题也很直观：你得停。
游戏里就是卡顿，前端里就是掉帧，后端里就是尾延迟蹿上去。
于是这一停世界，就让几十年的语言设计师、JVM 工程师、runtime 大神们开始拼命“降卡顿”。
然后我们走上了一条“工程师自我感动”的路
于是就有了各种“听起来很高级”的GC：
分代回收并行、并发回收分区 / region-based（Java 的 G1 就是这个）可预测暂停时间增量式、分片式、后台标记……听上去是不是很厉害？
但苹果那句话其实已经说透了：它们都没解决根问题，只是把大坑切成了很多小坑。
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% 还是你自己得有脑子。
所以问题就变成了：
