垃圾回收是一個錯誤

作者：dev 2025-11-03 08:14:06

看到?jīng)]？這已經(jīng)不是“我寫了個大對象結(jié)果GC卡了一下”這種程度的問題了，這是蘋果這種量級的公司都壓不住的系統(tǒng)性問題。你要知道，他們干的還是“密碼管理”這種活——高頻、敏感、延遲敏感、請求量巨大的線上服務(wù)。

蘋果最近寫了一篇很輕描淡寫的技術(shù)遷移文：他們把密碼管理服務(wù)從 Java 搬到了 Swift，性能一飛沖天。

寫得很克制，結(jié)果信息量爆炸。

看完只想說一句：原來不是我們寫得不行，是垃圾回收（GC）這條路本身就有坑。

蘋果點(diǎn)破了那個所有人都不想說的真相

文里有一段話反復(fù)看了三遍，給你摘出來：

我們先沒急著換語言，先是把 JVM 能調(diào)的參數(shù)都調(diào)了。用了 G1 GC，這個 GC 比老一代強(qiáng)很多：能控制暫停時間、有分區(qū)、還能并行干活。 ——但！在高并發(fā)場景下，GC 還是難搞：一來會有長暫停，二來性能開銷會頂上來，三來要想讓它適配各種各樣的業(yè)務(wù)，就得一直細(xì)調(diào)、細(xì)調(diào)、再細(xì)調(diào)。

看到?jīng)]？這已經(jīng)不是“我寫了個大對象結(jié)果GC卡了一下”這種程度的問題了，這是蘋果這種量級的公司都壓不住的系統(tǒng)性問題。

你要知道，他們干的還是“密碼管理”這種活——高頻、敏感、延遲敏感、請求量巨大的線上服務(wù)。

“討厭GC”其實(shí)很多人想說但不敢說

大家對 GC 的情緒也不算中立的。

在移動端上這一點(diǎn)更明顯：你認(rèn)真滾動一個 Flutter 界面，動畫正絲滑，GC 突然說：該洗一洗內(nèi)存了——咔！掉幀。

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

以前總覺得： “行，客戶端容易卡是因為 UI 線程比較嬌貴；但在服務(wù)器上，總有 20ms 的網(wǎng)絡(luò)延遲，GC 卡個十幾毫秒，應(yīng)該沒人能看出來吧？”

——蘋果這篇文直接告訴你：想多了。

它不是“偶然卡一下”的問題，是你量一旦上來了，GC 這套機(jī)制本身就變成了阻力。一個密碼管理服務(wù)，全球幾百萬、幾千萬設(shè)備，分分鐘都是對象分配和釋放，GC 的成本就不再是“小數(shù)點(diǎn)后第二位”的事了。

先回憶一下：GC 最原始的樣子有多粗暴

一開始的垃圾回收很樸素：停世界，涂顏色。

程序停一停，誰也別動
從“根”（棧、全局、寄存器）開始，把能走到的對象都標(biāo)成“活的”
其他的都當(dāng)垃圾，一把丟掉

這種叫標(biāo)記-清除，思想簡單，工程實(shí)現(xiàn)也比較直觀。問題也很直觀：你得停。

游戲里就是卡頓，前端里就是掉幀，后端里就是尾延遲躥上去。

于是這一停世界，就讓幾十年的語言設(shè)計師、JVM 工程師、runtime 大神們開始拼命“降卡頓”。

然后我們走上了一條“工程師自我感動”的路

于是就有了各種“聽起來很高級”的GC：

分代回收
并行、并發(fā)回收
分區(qū) / region-based（Java 的 G1 就是這個）
可預(yù)測暫停時間
增量式、分片式、后臺標(biāo)記……

聽上去是不是很厲害？

但蘋果那句話其實(shí)已經(jīng)說透了：它們都沒解決根問題，只是把大坑切成了很多小坑。

GC 還是得暫停的，只是從“一次停很久”變成了“停很多次、每次短一點(diǎn)”。而且更要命的是：你分區(qū)、你分代，其實(shí)都是在給 runtime 自己加開銷。在高負(fù)載場景下，這個開銷很快就會浮出來。

所以蘋果最后說：我們還是換語言吧。

你以為蘋果會秒選 Swift？他們也猶豫過

他們自己寫的：我們其實(shí)看了好多語言，不是那種“蘋果出品必用 Swift”那種拍腦袋。

最后還是落到了 Swift，核心原因其實(shí)就一個：它不用垃圾回收。

Swift 用的是 ARC（Automatic Reference Counting，自動引用計數(shù)）。

它不搞“我過一陣子再來看看誰還能活著”這一套，它搞的是：“你被引用+1，你不被引用-1；你變成0，我立刻干掉你。”

這個思路有兩個驚人的優(yōu)點(diǎn)：

釋放是分散的，不是集中的所以不會突然來一刀，整個線程都進(jìn)去回收
時機(jī)更可預(yù)期引用一旦沒了，馬上釋放，不會拖到幾秒鐘后再清

這，就是為什么在 UI 場景下，ARC 體驗肉眼可見地更順。

蘋果現(xiàn)在的說法是：同樣的爽感，在服務(wù)器上也能拿到。

當(dāng)然，ARC 也不是天使

你要是只說“GC 有暫停，ARC 沒暫停”，那就太不講究了。

ARC 最大的雷，大家都知道：循環(huán)引用。

A 引用 B，B 引用 A，兩個都有人愛，引用計數(shù)永遠(yuǎn)不會變成 0，但其實(shí)外面沒人能走到它們了——這就是一坨泄露。

Swift 的做法是：給你弱引用（weak）、unowned 這種不參與計數(shù)的引用，你自己在該用的地方用，不該用的地方別用。

也就是說：ARC 不是傻瓜式的。你還是得懂點(diǎn)內(nèi)存生命周期，不然你也能寫出一鍋爛。

不過話說回來，GC 也不是傻瓜式的。

你要是一直往一個全局 List 里塞對象、從來不刪，GC 也清不了你。本質(zhì)上還是：語言幫你減了 80% 的內(nèi)存活，剩下 20% 還是你自己得有腦子。

所以問題就變成了： ?? 為了這 20%，你愿不愿意換來一個“幾乎不掉幀、幾乎不突刺、尾延遲更穩(wěn)”的世界？

蘋果的答案是：愿意。

那么問題來了：既然 ARC、所有權(quán)、arena 這些都在，為什么當(dāng)年我們選了 GC？

這才是本文真正的靈魂拷問。

你看可選方案其實(shí)一大堆：

像 Swift 這樣：引用計數(shù) + 弱引用
像 Rust 這樣：所有權(quán) + 借用檢查
像 Ada 那樣：只能指向“更深”的對象，天生不容易環(huán)
像游戲引擎常用的：區(qū)域 / arena 分配，一幀分配完，一幀回收
像 Jai、很多高性能系統(tǒng)用的：一大塊內(nèi)存開出來，用完一刀清
甚至還有引用計數(shù) + 少量GC兜底這種折衷

你看，路線這么多，我們偏偏走了“讓程序自己去猜你要不要內(nèi)存”的那條。

這事你要是放到公司里來，是不是像這樣

甲：我們能不能在寫代碼的時候就標(biāo)一下“我這個對象多久用完”？乙：不用，我們寫個超級復(fù)雜的系統(tǒng)，隔一會就去全內(nèi)存里掃一遍，看有沒有人不要了。甲：？？？

如果這是你同事提的方案，你是不是要拍桌子了？

可是現(xiàn)實(shí)世界里，我們真的就這么干了，而且還干了30年。

為啥？我也覺得就是營銷贏了

“看，我們這是像 C 一樣快的語言，但你不用自己 free。” “你再也不用擔(dān)心內(nèi)存泄露了！” “寫業(yè)務(wù)就行，內(nèi)存我們管。”

很香，對吧。

于是 Java 火了，.NET 火了，很多企業(yè)都投了，連蘋果這種公司都在用它的 JVM。

但代價是什么？

一整代工程師被教育成：不需要顯式表達(dá)生命周期。

然后 runtime 就只能跟個猜你心思的戀人一樣，一遍一遍全內(nèi)存掃，想看你到底還愛不愛這個對象。

每一次掃，都是CPU、內(nèi)存、能源的浪費(fèi)。

我看到一個 HN 的評論，真是一針見血，我給你翻一下

垃圾回收就是“沉沒成本”的典范。我們30年都在往一個壞主意上砸聰明人。真相其實(shí)是：我們不愿意在語言層面、語法層面給足編譯器“對象會活多久”的上下文；于是就只好搞一個近乎自我感知的系統(tǒng)，去猜我們是不是用完了。它浪費(fèi)時間、浪費(fèi)空間、浪費(fèi)能量。要是當(dāng)年這些人去做“更聰明的語言”，而不是去搞“更聰明的GC”，我們今天會過得好很多。 GC 就是壞主意。我高興看到我們終于準(zhǔn)備好往前走了。

你看，這個吐槽有多狠。我們不是不會表達(dá)生命周期，是我們懶得表達(dá)。于是就有了一個“全內(nèi)存 for 一遍”的東西。