交互系统为什么宁可少干活，也不要卡一下？讲懂吞吐换停顿你可能见过这种程序：平均速度不慢，但偶尔一点按钮，界面会像突然去

你可能见过这种程序：平均速度不慢，但偶尔一点按钮，界面会像突然去想人生一样愣一下。对用户来说，这种“顿一下”往往比“整体慢一点”更难受。

所以工程上经常会做一个很现实的选择：宁可系统总共少干一点活，也别让它一次卡太久。这就是“吞吐换停顿”。

先讲人话：它到底在换什么？

先别急着背术语，先记三个画面。

术语版再说一遍：在带垃圾回收的运行时里，常会通过更频繁回收、更小堆、严格对象生命周期控制，来缩短单次回收停顿；代价是回收更忙，业务线程可用时间变少，所以总吞吐会下降。不同语言和回收器细节不一样，但这个取舍思路很常见。

生活类比也很直白：大垃圾桶可以少倒几次，但一倒就是一大车；小垃圾桶要常倒，但每次很快。如果你最怕的是“门口突然堵死”，你往往会更愿意选后者。

小案例：

一个聊天输入框每敲一次字，都会产生一批临时字符串和列表。要是这些临时对象越积越多，回收一来就可能把界面卡一下；如果让它们更早失效、垃圾更早收走，单次卡顿就会短很多。

看这条过程线就明白了：

创建很多短命对象 -> 垃圾慢慢堆大 -> 一次回收要扫更多东西 -> 单次停顿变长

改成更频繁回收 + 更小堆 + 对象尽快失效 -> 每次回收更轻 -> 单次停顿变短 -> 但回收次数变多 -> 总吞吐下降

这条过程线说明：如果你的目标是“别一下卡住用户”，下一步就该先检查是不是在放任短命对象堆成一次大清扫。

这里的三个手段，可以这样理解。

人话：保洁多来几趟，每次扫一点。

术语：提高回收触发频率，减少单次需要处理的垃圾量。

Mini-case：消息列表每 100ms 产生一批临时对象，分散回收时每次只停几毫秒；拖到 1 秒再收，可能一下停几十毫秒。

人话：垃圾桶小一点，满了就倒。

术语：限制堆规模，让回收更早发生，避免“堆很大、一次扫很久”。

Mini-case：同样 1 万个临时对象，小堆可能分 5 次收掉，大堆可能攒到一次大回收才处理。

人话：一次性纸杯喝完就扔，别顺手塞进背包。

术语：让对象只活在真正需要它的那段时间，避免临时对象被全局变量、缓存、长生命周期容器意外“养着”。

Mini-case：一次请求里生成的中间结果，本该请求结束就消失；如果被挂到全局缓存里，它就会活更久，回收更慢。

如果你的系统最怕“卡一下”，这套思路就很值钱，比如：

如果你的任务是“后台多跑点活”，比如离线统计、批处理、夜间任务，那很多时候反而更该保吞吐。

|---|---|---|---|---|

这张表的意思很简单：如果你的 KPI 是点击响应、掉帧和卡顿体感，就先站到“单次停顿更短”这一列；如果 KPI 是每小时多处理多少数据，就先站到“总吞吐更高”这一列。

假设你做一个搜索框联想功能。

这就是“吞吐换停顿”的核心：它不是让系统绝对更快，而是让它对人看起来更稳。

误区 1：堆越大越好。

不一定。对交互系统来说，堆太大有时只是把垃圾攒到更后面，再来一次更重的停顿。

误区 2：回收越勤越好。

也不一定。太勤可能变成“刚扫完又要扫”，吞吐掉得太多。

误区 3：所有对象都该复用。

别走极端。复用能减少分配，但过度复用会让代码变复杂，甚至让对象活得更久，反而不利于回收。