c# Lazy 的用法 c#延迟初始化和线程安全_技术教程

Lazy 应用于构造开销大且未必访问的场景（如 DbContext、大型缓存），避免用于简单对象或短生命周期对象；线程安全仅保障工厂最多调用一次，不保护其内部逻辑；异常会被缓存并重复抛出；不支持真正异步延迟，应改用 AsyncLazy 或 Func。

的用法 c#延迟初始化和线程安全">

Lazy 什么时候该用，什么时候不该用

延迟初始化只在值构造开销大、且不保证一定会被访问时才有意义。比如一个 DbContext 实例、大型缓存对象、或需要 IO 初始化的配置类。如果只是 new List() 或简单字符串，用 Lazy 反而增加间接层和内存占用，得不偿失。

常见误用场景：
• 把所有字段都套上 Lazy 当“性能优化”
• 在单线程短生命周期对象里滥用（如 ASP.NET Core 的 transient service）
• 用它替代构造函数参数注入——这混淆了职责

默认构造 vs 自定义工厂函数：线程安全差异在哪

Lazy 的线程安全性取决于构造方式：
• new Lazy()（无参）：使用默认构造函数，线程安全，首次 Value 访问时最多执行一次构造
• new Lazy(func)（带工厂）：同样线程安全，但要注意 func 内部是否含非线程安全操作（比如静态字典写入）
• new Lazy(func, isThreadSafe: false)：显式关闭同步，仅适用于已知单线程上下文，否则可能重复执行工厂函数

关键点：
• 线程安全 ≠ 工厂函数内部安全；Lazy 保证的是“工厂最多调用一次”，不保护你写的 func 里的逻辑
• 如果工厂里要写共享状态，仍需自己加锁或用 ConcurrentDictionary 等

Value 属性触发时机和异常传播规则

Value 第一次被读取时才执行初始化，后续读取直接返回缓存值。但如果初始化过程抛出异常，Lazy 会缓存该异常，之后每次访问 Value 都重新抛出同一个异常实例（不是新异常），这点容易踩坑。

示例：

var lazy = new Lazy(() => { throw new InvalidOperationException("Boom"); });
try
{
    var s = lazy.Value; // 第一次：抛 InvalidOperationException
}
catch (InvalidOperationException)
{
    // 处理
}
try
{
    var s2 = lazy.Value; // 第二次：仍抛同一个 InvalidOperationException 实例
}
catch (InvalidOperationException)
{
    // 这里也会进
}

规避方法：
• 初始化前用 IsValueCreated 判断是否已尝试创建（但无法区分是成功还是失败）
• 更稳妥的

是封装一层，捕获并重置 Lazy（需重建实例）
• 或改用手动双检锁 + volatile 字段，完全掌控异常行为

与 async/await 不兼容：为什么不能 Lazy>

Lazy 是同步机制，T 必须是具体类型。写成 Lazy> 看似可行，但实际是“延迟创建 Task 对象”，而非“延迟执行异步操作”——Task 构造极快，起不到延迟效果，还掩盖了真正的 await 需求。

正确做法：
• 用 AsyncLazy（需自行实现或引用 Microsoft.Bcl.AsyncInterfaces 中的类型）
• 或封装为 Func> + 手动缓存 Task 实例（注意 Task 完成后不可重用）
• ASP.NET Core 中更推荐用 IServiceScopeFactory 延迟解析服务，而非在字段级做异步延迟

一句话记住：Lazy 解决的是「要不要 new」，不是「要不要 await」。