Scala.js项目中AnalyzerRun.WorkTracker的竞态条件分析与修复

在Scala.js项目的链接器组件中，AnalyzerRun.WorkTracker类负责跟踪分析阶段的工作任务完成情况。最近发现了一个关键的竞态条件问题，可能导致Promise被多次完成，从而引发IllegalStateException异常。

问题背景

AnalyzerRun.WorkTracker类的主要职责是协调分析阶段多个并行任务的完成状态。它使用一个计数器(pending)来跟踪正在进行的任务数量，以及一个标志位(_allowComplete)来控制何时允许完成关联的Promise。

当所有任务完成且允许完成时，WorkTracker会完成Promise以通知调用方分析阶段结束。然而，在特定情况下，两个线程可能同时尝试完成Promise，导致异常。

竞态条件分析

问题的根本原因在于allowComplete()方法和任务完成逻辑之间的竞态条件。具体场景如下：

1. allowComplete()方法首先设置_allowComplete = true
2. 最后一个正在进行的任务恰好在此刻完成，调用pending.decrementAndGet()
3. 任务完成线程发现计数器为0且允许完成，于是尝试完成Promise
4. 同时，allowComplete()方法也检查到相同条件，也尝试完成Promise
5. 两个线程都调用Promise的complete方法，导致IllegalStateException

这种竞态条件在高并发环境下尤其容易出现，特别是在分析阶段任务较少且完成时间接近的情况下。

解决方案

修复方案的核心思想是消除独立的_allowComplete标志，将其功能整合到现有的任务计数器中。具体实现方式是在计数器初始值时加1，这个额外的计数代表"允许完成"的状态。

当调用allowComplete()时，不是设置一个布尔标志，而是递减计数器。这样：

• 初始计数器值为任务数+1
• 每个任务完成时递减计数器
• allowComplete()调用也递减计数器
• 只有当所有任务和allowComplete()都完成后，计数器才会归零

这种方法确保了原子性，因为所有状态变更都通过单一的原子计数器完成，消除了标志位和计数器之间的竞态条件。

实现细节

在修复后的实现中：

1. 构造函数初始化计数器为tasks + 1而不是tasks
2. allowComplete()方法简化为直接调用pending.decrementAndGet()
3. tryComplete()逻辑保持不变，但条件判断更加简单

这种设计不仅解决了竞态问题，还简化了代码逻辑，减少了状态变量的数量，使整体行为更加清晰可靠。

影响与验证

该修复影响了Scala.js链接器的分析阶段，这是构建过程中的关键步骤。修复后：

• 消除了Promise被多次完成的可能
• 保持了原有的功能语义
• 提高了在高并发环境下的稳定性

通过单元测试可以验证修复的有效性，特别是那些涉及并发分析和增量编译的场景。测试应模拟多个任务几乎同时完成的情况，确保Promise只被完成一次。

结论

在并发编程中，使用多个同步原语协调复杂状态容易引入竞态条件。Scala.js的这个案例展示了如何通过状态简化来解决这类问题 - 将多个同步变量合并为单个原子变量，从根本上消除竞态可能。这种模式在并发系统设计中值得借鉴。