面试防线：Worker 与主线程高频通信导致的内存暴涨与 GC 治理
面试官提问：
“在 Worker 里算出大量数据后高频使用 postMessage 发回主线程，因为结构化克隆过程，反而会引发极高的内存飙升和频繁的 GC（垃圾回收）停顿，你是怎么治理的？”
核心回答思路 (STAR法则)
-
业务痛点 (Situation)
测试高频实时刷新 IoT 大屏时，Worker 算得快，但一秒钟发几十次 postMessage 传巨大图表配置。主线程消费不过来，消息严重积压，内存飙到几个 G，触发 V8 引擎疯狂 GC，页面假死。 -
技术考量 (Task)
这是经典的生产者-消费者失衡。必须减少传输体积或控制生产者的发送节奏（引入背压 Backpressure）。 -
架构决策 (Action)
- 零拷贝与数据压缩 (Transferable Objects)：底层的明细点阵坚决不传 JSON。在 Worker 里转换为 Float64Array 强类型数组，并在 postMessage 时标记转移其所有权。这让内存瞬间易主，无需深拷贝，彻底消灭了序列化的内存激增。
- 引入双向背压机制 (Backpressure)：建立节流阀。Worker 算完发消息后进入等待；主线程用 requestAnimationFrame 画完并回复 ACK 消息后，Worker 才继续推下一批。
- 环形缓冲区 (Ring Buffer)：在 Worker 内部设计定长的 Ring Buffer 队列。如果主线程来不及画，新计算结果直接覆盖旧数据，坚决不让无用数据堆积。
- 业务价值 (Result)
极端场景下的内存占用被死死按在 150MB 以下。这套严密的主从线程调度架构，为工业级实时大屏提供了强有力的基建。