Go并发任务触发实现的竞态条件隐患及相关问题咨询

你提到的实现试图通过动态替换sync.Once实例来实现“同一时间仅执行一次任务、忽略并发触发”的需求，但存在几个关键问题，以下逐一分析：

闭包的过期指针对GC的影响 #

不会造成永久性内存泄漏，但存在临时内存占用的情况：

• onceBody返回的闭包捕获了变量v，每个闭包都是独立的。当某个sync.Once实例的Do方法执行完成后，若没有其他goroutine持有该实例的指针，它会被GC回收，对应的闭包也会被回收。
• 但在once指针被替换后，那些还未完成once.Do调用的goroutine仍持有旧sync.Once实例的指针，直到这些goroutine执行完毕（你的代码里有wg.Wait保证所有goroutine结束），旧实例才会被GC回收。如果是长期运行的服务，频繁替换once可能导致短时间内存在多个未被回收的sync.Once实例，但不会造成永久泄漏。

忽略once竞态条件的其他问题 #

你已知once变量存在竞态，但这个竞态会直接破坏你的核心需求，引发以下问题：

• 任务重复执行：当处理任务的goroutine刚完成once = &sync.Once{}的赋值时，多个等待中的goroutine可能同时看到新的sync.Once实例，它们的Do调用都会执行，导致多次向trigger发送数据，任务被重复触发，完全违背了“同一时间仅执行一次”的设计目标。
• 触发值不可控：竞态下，最终被执行的闭包对应的v值是随机的，可能出现多个不同的v被触发的情况，导致业务逻辑结果不可预测。
• 违背sync.Once设计意图：sync.Once的原生设计是用于一次性初始化，并非支持动态重置复用。虽然通过替换指针的方式看似能“重置”，但这种用法不在其设计考虑范围内，可能引发未定义的并发行为。

其他潜在问题 #

• Channel阻塞风险：trigger是无缓冲channel，若处理任务的goroutine未及时接收，发送闭包的goroutine会被阻塞。在once替换的瞬间，若有多个goroutine同时执行发送操作，会导致这些goroutine阻塞，直到channel被接收。测试场景下因为wg.Wait等待所有goroutine结束，不会有问题，但长期运行的服务中，可能造成goroutine堆积，消耗系统资源。
• 不必要的goroutine开销：创建100000个goroutine，即使大部分会因sync.Once.Do直接返回，goroutine的创建和调度本身也会带来性能开销，高并发场景下可能影响服务性能。

内容的提问来源于stack exchange，提问作者shampu