Blazor中OnAfterRenderAsync与DisposeAsync竞态问题及方案咨询

解决方案与分析 #

1. 使用lock是否有效？ #

有效，但要注意使用边界。OnAfterRenderAsync和DisposeAsync运行在不同线程，用lock包裹对_CTSList的所有读写操作（包括添加、遍历、移除），能直接避免并发修改导致的访问冲突。但绝对不能在lock块里执行异步操作（比如JS互调用），否则会阻塞.NET线程，拖慢整个组件的响应速度。

2. 更优方案 #

推荐以下几种更贴合Blazor场景的方案：

• 用线程安全集合替代普通列表：直接用ConcurrentBag<CancellationTokenSource>代替List<CancellationTokenSource>，它本身就支持并发读写，不需要额外加锁，适合这种多线程添加、批量清理的场景。
• 标记组件销毁状态：在组件里加一个private bool _isDisposed字段，OnAfterRenderAsync开头先检查这个状态，如果已经标记为销毁，直接返回不执行后续逻辑；DisposeAsync里先设置_isDisposed = true，再去清理资源，从根源上切断并发操作的可能。
• 封装JS资源管理器：把ResizeObserver这类需要生命周期管理的JS逻辑封装成组件级的工具类，内部处理并发、CancellationToken和清理逻辑，组件只需要调用初始化和销毁方法，降低耦合度。
• 用信号量控制并发：初始化一个SemaphoreSlim(1, 1)，OnAfterRenderAsync执行前先调用WaitAsync()获取信号量，执行完后释放；DisposeAsync里先调用WaitAsync()等待所有正在执行的OnAfterRenderAsync逻辑完成，再执行清理，确保DisposeAsync是最后执行的操作。

3. 为什么这类JS操作实现复杂？ #

主要是Blazor跨环境特性带来的几个核心矛盾：

• 生命周期与异步性不兼容：Blazor的组件生命周期方法运行在.NET线程，JS操作在浏览器JS线程，两者执行时序完全独立，很难做到精准同步，容易出现组件已销毁但JS还在运行的情况。
• ElementReference的有效性限制：ElementReference只有在组件渲染完成后才有效，组件卸载后对应的DOM元素直接消失，JS再引用就会报错，必须严格控制访问时机。
• 多线程并发风险：尤其是服务器端Blazor，组件生命周期方法可能在不同线程执行，加上JS互操作的异步特性，很容易出现竞态条件，需要额外处理线程安全。
• JS资源的手动清理责任：像ResizeObserver这类JS对象不会随组件销毁自动回收，必须手动调用销毁方法，而.NET和JS跨环境通信的特性，很容易遗漏清理步骤，导致内存泄漏。

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