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 内部是否含非线程安全操作(比如静态字典写入)
• new Lazy:显式关闭同步,仅适用于已知单线程上下文,否则可能重复执行工厂函数
关键点:
• 线程安全 ≠ 工厂函数内部安全;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」。










