增量标记并非消除STW，而是将长停顿拆为多个毫秒级暂停，通过空闲周期穿插执行、三色模型推进和写屏障保障正确性，使主线程保持响应。
增量标记不是“避免阻塞”，而是把一次长阻塞拆成多个极短暂停，让主线程仍有响应能力。 它无法消除 STW（Stop-The-World），但能让每次停顿控制在毫秒级，用户几乎感知不到卡顿——这是现代 JS 引擎（如 V8）处理大型单页应用的关键机制。
为什么 Mark-Sweep 一气呵成会卡死主线程
传统全量标记需从 GC roots（如 window、调用栈）出发，递归遍历所有可达对象。堆越大、引用链越深，这个过程越久：10 万对象可能耗时 50–200ms。浏览器在此期间完全冻结，动画掉帧、输入延迟、setTimeout 失效都可能发生。
- 典型现象：
console.time('mark')测出单次标记 >30ms，页面明显卡顿 - 触发条件：一次性创建大量 DOM 节点、JSON 解析超大响应、Canvas 纹理批量生成
- 关键限制：标记必须在一致快照下进行，否则并发修改会导致漏标（本该活的对象被清掉）
IncrementalMarking 怎么把大任务切成小片执行
V8 在空闲周期（如事件循环末尾、requestIdleCallback 可用时）插入微任务，每次只扫描几十到几百个灰色对象，更新其子对象颜色并推进三色状态。它不追求“做完”，只保证“不落后”。
- 每次执行粒度可控：
v8::Isolate::RequestGarbageCollectionForTesting可强制触发单步，但生产环境由引擎自动调度 - 依赖写屏障（
write barrier）：当 JS 线程修改引用（如obj.a = newObj）时，若obj已是黑色而newObj是白色，引擎会立即将newObj重标为灰色，确保后续被扫描 - 不适用场景：频繁跨代写入（如老生代对象大量引用新生代对象），会放大写屏障开销
什么情况下增量标记反而更慢或失效
增量标记的收益高度依赖对象图结构和修改频率。某些模式会让它退化为近似全量标记，甚至引发额外开销。
- 对象图极度稀疏但深度极大（如链表式 DOM 树）：每次只扫固定数量节点，来回跳转多，缓存不友好
- 高频写屏障触发：例如
for (let i = 0; i ，每赋值一次都可能触发屏障逻辑 - 内存压力陡增时自动关闭：当堆使用率超过阈值（V8 默认 ~70%），引擎会放弃增量，直接切 Full GC，此时 STW 回归明显
- 开发者误操作：
globalThis.hugeCache = new Map()持有大量对象却不清理，灰色队列持续膨胀，增量节奏跟不上分配速度
真正难处理的从来不是“怎么开启增量标记”，而是识别哪些对象图结构正在拖慢它的节奏——比如一个未解绑的全局事件监听器，悄悄把整个组件树钉在内存里，让灰色队列永远扫不完。这时候再细的增量步长也救不了卡顿。
