Riverpod异步Notifier方法是否会出现竞态条件？

核心结论 #

Riverpod 默认不会自动对Notifier的异步方法调用进行FIFO排队，如果多个异步方法同时读取并修改状态，确实存在互相覆盖修改的风险。

详细解释 #

1. 状态更新的本质
   Notifier的状态更新依赖于state = newState的赋值操作，异步方法执行时会先读取当前状态，经过异步操作后再赋值新状态。若两个异步方法几乎同时启动，它们读取的是同一初始状态，后续各自修改后赋值，就会出现后执行的赋值覆盖前一个修改的情况。

2. Riverpod的默认行为
   Riverpod并没有为Notifier的方法调用实现内置的队列机制。每个方法调用都是独立的，异步方法的执行不会被其他调用阻塞或排队。

3. 解决方案
   若需要确保异步方法按调用顺序执行、避免竞态条件，确实需要自行实现队列逻辑：

   • 在Notifier内部维护一个Queue存储待执行任务
   • 暴露唯一公开方法接收任务，内部检查是否有正在执行的任务，若无则从队列取出任务执行，完成后再处理下一个
   • 将所有状态修改逻辑封装到私有方法中，仅通过队列调度执行

   示例伪代码：

   class MyNotifier extends Notifier<List<Item>> {
     final Queue<Future<void> Function()> _taskQueue = Queue();
     bool _isProcessing = false;
   
     @override
     List<Item> build() => [];
   
     // 唯一公开方法，用于提交任务
     void submitTask(Future<void> Function() task) {
       _taskQueue.add(task);
       _processQueue();
     }
   
     Future<void> _processQueue() async {
       if (_isProcessing || _taskQueue.isEmpty) return;
       _isProcessing = true;
       try {
         await _taskQueue.removeFirst()();
       } finally {
         _isProcessing = false;
         _processQueue(); // 递归处理下一个任务
       }
     }
   
     // 私有异步方法，实际修改状态
     Future<void> _addItem(Item item) async {
       // 模拟异步操作
       await Future.delayed(const Duration(milliseconds: 100));
       state = [...state, item];
     }
   
     // 对外暴露的添加方法，通过submitTask调度
     void addItem(Item item) => submitTask(() => _addItem(item));
   }
   

额外提示 #

• 对于简单的同步状态修改，无需担心竞态问题，因为同步方法会立即执行状态赋值，Riverpod会保证状态更新的原子性。
• 如果异步操作仅依赖最新状态，可结合freezed等不可变数据类使用state = state.mutate(...)的方式，但这只能解决单次修改的一致性，无法解决多异步任务的顺序问题。

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