在资源受限的微控制器上运行 TinyGo 编译的 WASM 程序时，垃圾回收（GC）引起的暂停是影响系统实时性的关键瓶颈。与标准 Go 运行时不同，TinyGo 采用保守式 mark-sweep 垃圾回收器，其设计优先考虑代码体积而非最短暂停时间，这使得在中断驱动的嵌入式场景中需要额外的工程调优。
保守式 GC 的暂停根源分析
TinyGo 在 ARM Cortex-M 等微控制器目标上默认使用保守式 mark-sweep 垃圾回收器，其工作原理分为标记（mark）和清除（sweep）两个阶段。标记阶段需要遍历所有 GC 根（全局变量和栈上的活跃对象），并递归标记所有可达对象；清除阶段则释放不可达对象占用的内存块。这种设计虽然代码量小（通常仅几百字节），但在大规模对象遍历时会引发明显的暂停。
关键问题在于，微控制器通常只有 64KB 至 256KB 的 RAM，而地址空间可达 4GB。这意味着保守式 GC 必须扫描大量可能的指针值，任何碰巧落在堆地址范围内的整数都会被误认为是指针（假阳性），导致本应回收的对象被错误保留，进一步加剧后续 GC 的工作负担。对于 WASM 目标，虽然运行在浏览器或 WASI 运行时环境中，但内存模型同样受限，GC 暂停仍会阻塞事件循环，影响中断响应的及时性。
量化来看，在 64KB RAM 的 STM32F103 上，一个包含 2000 个活跃对象的程序进行一次完整 GC 周期可能耗时 5 至 15 毫秒，这对于要求毫秒级响应的实时控制任务是不可接受的。WASM 环境下的暂停时间虽因宿主环境性能差异而有所不同，但在低端设备上同样存在显著影响。
内存分配策略与 GC 模式选择
针对不同的实时性需求，TinyGo 提供了多种 GC 和调度器组合，这是调优的核心入手点。
第一种组合是完全禁用 GC，使用 -gc=none -scheduler=none 编译参数。这消除了所有 GC 暂停，但要求开发者手动管理内存生命周期。所有分配的对象将永久驻留堆中，适用于程序运行期间分配模式固定、或仅有初始化阶段需要内存的场景。这种方式下，内存占用完全可预测，没有任何运行时干扰，是硬实时系统的首选。代价是失去了 Go 语言的自动内存管理优势，开发者需要通过对象池或静态分配确保不会发生内存耗尽。
第二种组合是保守式 GC（默认），使用 -gc=conservative -scheduler=asyncify。这是 TinyGo 的默认行为，GC 在堆即将耗尽时触发。优点是开箱即用，缺点是暂停时间不可控。当 GC 触发时，整个世界都会停止，直到标记和清除阶段完成。对于 WASM 目标，asyncify 调度器允许在等待异步操作时让出控制权，但这不能解决 GC 本身导致的阻塞。
第三种组合是泄漏模式，使用 -gc=leaking -scheduler=none。这种模式下分配的内存永不释放，GC 几乎不做什么工作，仅在分配时检查堆边界。这将暂停降至最低，但代价是内存只增不减，适合具有确定性生命周期的小程序 —— 例如一次性传感器读数处理函数，运行完毕即结束，无需回收。
对于需要一定内存管理能力但要求更低暂停的场景，可以考虑减少堆压力。具体策略包括：使用 sync.Pool 重用临时对象，减少每单位时间的分配数量；将大对象拆分为小对象并通过指针链接，降低单次 GC 扫描的复杂度；以及避免在中断处理函数中进行任何堆分配，所有中断相关的数据结构均预先分配在静态内存中。
中断响应延迟的量化调优参数
微控制器环境中的实时性要求通常以中断延迟来衡量。GC 暂停对中断响应的影响取决于两个变量：GC 触发频率和单次暂停时长。以下参数组合可作为基准起点，随后根据实际测量进行调整。
对于硬实时要求（中断延迟必须小于 1 毫秒）的场景，推荐配置为 -gc=none -scheduler=none -opt=2，并配合静态内存分配。此配置下代码体积最小，无任何运行时干扰。中断处理函数中不应包含任何 new、make 或隐式堆分配操作，必要时可通过编译器分析确认没有意外分配。
对于软实时要求（中断延迟可容忍 5 至 10 毫秒）的场景，可使用 -gc=conservative -scheduler=coroutines -gc-initial-heap-size=8192 -gc-growth-threshold=4096。这里通过减小初始堆大小和降低增长阈值，使 GC 更频繁但每次工作量更小，从而将长暂停拆分为多次短暂停。-scheduler=coroutines 提供了轻量级协程支持，可在 GC 期间让出 CPU。
对于 WASM 特定优化，TinyGo 文档建议添加 -wasm-abi=js 以生成更紧凑的 WASM 模块，同时关注堆大小的精确控制。在 WASI 环境下，可考虑使用社区开发的 nottinygc 项目作为高性能分配器替代方案。
监控 GC 行为的关键指标包括：堆使用量峰值、GC 触发次数、以及每次 GC 的实际耗时。由于 TinyGo 运行时能力有限，可在关键代码段前后插入时间戳记录，通过串口输出或 LED 闪烁模式观察 GC 是否在预期时刻发生。对于更精细的诊断，可利用 -gc=leaking 模式运行一段时间后检查堆最大占用，作为调优基线。
资料来源
本文技术细节主要参考 TinyGo 官方文档及 Ayke van Laethem 关于 TinyGo 垃圾回收器内部实现的分析。