Go 采用了三色并发垃圾收集器，其中对象从白色（未标记）转变为灰色（排队）再到黑色（完全扫描）。在标记期间的基本不变量是 黑色对象绝不能包含指向白色对象的指针，因为这可能导致收集器错误地释放可达的内存。为了在不停止世界的情况下强制执行这一点，Go 使用了 写屏障——一个在每次指针写入堆时触发的编译器插入的钩子。当一个变异 goroutine 执行指针写入时，屏障检查目标对象是否为白色；如果是，它会在完成写入之前立即将目标对象的颜色改为灰色，原子性地保持不变量。
我们观察到在处理每秒数百万事件的实时分析管道中出现严重的尾延迟。该系统使用复杂的图结构，其中节点根据流数据频繁更新对子节点的引用，导致在 Go 的 GC 周期中大量的指针颠覆。
考虑的第一个解决方案： 我们试图通过将 GOGC 增加到 200% 来减轻这个问题，以延迟收集。 优点：减少了 GC 周期的频率，从而降低了随时间推移的总屏障执行次数。 缺点：这显著增加了峰值堆大小，风险在于在内存受限的容器中发生 OOM 崩溃，并且仅仅推迟了延迟峰值而不是解决它们。
考虑的第二个解决方案： 我们尝试使用 sync.Pool 进行对象池化，以重用节点结构并减少分配。 优点：降低了分配压力和新白色对象创建的速度。 缺点：由于我们仍然以相同的速度在现有（通常已经扫描过的）黑色对象内变更指针，写屏障开销仍然很高；池化并没有解决指针更新时屏障执行的成本。
考虑的第三个解决方案： 我们重构了图，以对大型切片使用整数索引而不是直接指针来表示节点关系。 优点：整数赋值不是指针写入，完全绕过了写屏障机制，并消除了标记期间相关的 CPU 成本。 缺点：这需要为切片实现手动内存管理（处理空洞、压缩），并使代码变得不那么地道且更难维护。
选择的解决方案： 我们为高颠覆的核心图采用了基于索引的方法，同时为静态元数据保留了指针。这直接消除了写屏障的热点路径，同时保持了图形的连通性语义。
结果： GC 期间的尾延迟降低了 90%，从 15 毫秒下降到 1.5 毫秒，由于减少了 GC 协助工作占用变异程序的 CPU，整体吞吐量提高了 40%。
为什么写屏障将目标对象着色为 灰色 而不是被修改的对象？
候选人通常错误地假设屏障应该将源对象（被写入的那个）标记为需要重新扫描。然而，源对象已经是灰色或黑色；如果它是黑色，重新扫描它将是昂贵的，并且需要跟踪其所有出去的指针。相比之下，将 目标（新的指针值）立即着色为灰色满足了三色不变量：如果源是黑色而目标是白色，边缘从黑色变为灰色，这样是安全的。这一区别至关重要，因为它最小化了工作量（只有新的目标被排队），而不是要求可能很大的源对象被重新扫描。
写屏障如何与堆栈分配交互，以及为什么可能需要重新扫描堆栈？
虽然写屏障主要拦截堆的指针写入，但 Go 还必须处理从堆栈到堆的指针。如果一个 goroutine 将一个指向白色堆对象的指针写入一个黑色堆栈帧，写屏障会执行以着色目标。然而，由于堆栈可能会增长、缩小和被复制，因此保持每个堆栈槽的精确黑/白状态是复杂的。 Go 通过将堆栈视为可能需要在标记阶段结束时重新扫描的根节点来解决这个问题，如果它们在标记期间是活动的。候选人常常忽视堆栈重新扫描是必要的后备选项，当堆栈上的写屏障无法保证不变量时，且这个最终的停止世界阶段通常是短暂但对正确性至关重要。
Dijkstra 写屏障和 Yuasa 写屏障之间有什么区别，Go 使用哪一个？
Dijkstra 屏障在安装指针时将目标对象着色（黑色变异器，白色目标），从而防止黑色到白色边缘的存在。相反，Yuasa 屏障记录即将被覆盖的 旧 指针值并对其进行着色，保留“开始时快照”属性。Go 使用混合 Dijkstra 屏障，因为它更简单，确保强三色不变量立即成立，尽管如果一个白色对象在被着色后立即变得不可达，可能会导致浮动垃圾。候选人常常将这些混淆或认为 Go 由于其保守的堆栈处理而使用 Yuasa，但理解 Dijkstra 的选择可以解释为何 Go 的屏障与写入同步而不是基于日志。