IAsyncInitialization不是 .NET 框架内置接口,而是开发者为解决“异步初始化必须只执行一次且可等待”这一常见问题而约定的模式接口——它本质是
Task的状态封装契约,不是语法糖,而是工程化兜底手段。
为什么不能直接用 Task InitializeAsync()
?
直接暴露
InitializeAsync()方法看似简单,但会引发三类高频问题: 多次调用导致硬件重复初始化、端口重开、资源泄漏(比如温箱设备被
StartAcquisitionAsync()前反复
InitializeAsync()) 并发调用时竞态:两个线程同时进入初始化逻辑,一个成功、一个失败,但调用方无法感知最终状态 UI 或 MVVM 场景下,ViewModel 无法安全绑定“初始化是否完成”,因为
Task本身不提供
IsCompletedSuccessfully或
Exception的可观测属性
标准 IAsyncInitialization
接口长什么样?
典型定义极简,但每项都有明确语义:
public interface IAsyncInitialization
{
Task Initialization { get; }
bool IsInitialized { get; }
Exception? InitializationException { get; }
}关键点:
Initialization是只读
Task,首次访问才触发初始化逻辑,后续访问返回同一实例(自动实现“只执行一次”)
IsInitialized和
InitializationException提供同步状态查询能力,UI 可直接绑定,无需
await就能判断成败 不包含
InitializeAsync()方法——避免使用者误调用底层逻辑,强制走统一入口
在温箱控制类中怎么落地?
以硬件初始化场景为例(如多温箱共用串口通信),需结合动态锁与状态管理:
public class IncubatorController : IAsyncInitialization
{
private readonly object _initLock = new();
private Task? _initTask;
private volatile bool _isInitialized;
private Exception? _initException;
<pre class='brush:php;toolbar:false;'>public Task Initialization => _initTask ??= InitializeCoreAsync();
public bool IsInitialized => _isInitialized;
public Exception? InitializationException => _initException;
private async Task InitializeCoreAsync()
{
// 动态锁:m_ParameterMap["EnableLock"] == true 时才加锁
using var guard = m_ParameterMap.GetValueOrDefault("EnableLock", true)
? await AsyncLock.LockAsync(_initLock, TimeSpan.FromSeconds(10))
: null;
try
{
await InitializeHardwareAsync().ConfigureAwait(false);
_isInitialized = true;
}
catch (Exception ex)
{
_initException = ex;
throw;
}
}
private async Task InitializeHardwareAsync() { /* 实际 I/O 初始化 */ }}
注意坑点:
必须用volatile bool+
??=确保
_initTask初始化线程安全;
??=在 C# 8+ 才支持,旧项目需手动 double-check lock 不要在
Initializationgetter 中写
await—— getter 应该快,耗时逻辑全放
InitializeCoreAsync
AsyncLock要带超时(如示例中
TimeSpan.FromSeconds(10)),否则多温箱场景下某个设备卡死会导致整个系统初始化阻塞
真正难的不是写这个接口,而是让所有调用方养成“先 await controller.Initialization,再调 RiseAsync/StartAcquisitionAsync”的肌肉记忆——一旦漏掉,异步初始化的收益就归零了。
