应避免手动实现双重检查锁单例,.NET 4.0+ 优先用 Lazy(需静态字段+异常处理),旧框架用静态构造函数;Lazy 不支持异步,需异步初始化时改用 AsyncLazy 或 Task 封装;慎用全局单例,优先考虑 DI 的 scoped 生命周期。为什么不用 lock + 双重检查就别碰单例手动用 lock 和 if (instance == null) 套两层判断,看似稳妥,实则极易出错:忘记加 volatile 修饰字段会导致指令重排,.NET 4.0 之前还可能因 JIT 优化让未初始化对象被其他线程看到。这不是理论风险------真实项目里出现过构造函数没跑完、instance 却已非 null 的诡异 crash。实操建议:- 绝对不要自己手写双重检查锁(Double-Checked Locking)- .NET 4.0+ 直接用 Lazy<t></t>,它底层已处理内存屏障和线程同步- 若必须兼容旧框架(如 .NET 3.5),改用静态构造函数方式,靠 CLR 保证只执行一次且线程安全Lazy 初始化失败时怎么捕获异常Lazy<t></t> 默认是"第一次访问 Value 时才执行工厂函数",但如果工厂函数抛异常,这个异常会被缓存------后续每次读 Value 都直接 rethrow,不是重新尝试初始化。很多人误以为会重试,结果日志里反复看到同一个 NullReferenceException 却查不到源头。实操建议:- 显式传入 LazyThreadSafetyMode.ExecutionAndPublication(默认值,但写出来更清晰)- 工厂函数内必须包住所有可能异常,或至少 log 出错上下文- 检查是否真需要延迟加载:如果构造开销不大,直接用静态只读字段反而更透明- 示例:private static readonly Lazy<MyService> _instance = new Lazy<MyService>(() => { try { return new MyService(); } catch (Exception ex) { Log.Error(ex); throw; } }, LazyThreadSafetyMode.ExecutionAndPublication);Singleton 实例被 GC 回收?那是你用了错误的 Lazy 构造方式如果用的是 new Lazy<t>(Func<t>)</t></t> 无参构造,实例生命周期由 GC 管理,一旦没有强引用指向 Lazy<t></t> 对象本身,整个延迟初始化机制就失效了------下次再 new 一个 Lazy<t></t>,又会重新创建实例。这不是单例,是"伪单例"。 arXiv Xplorer ArXiv 语义搜索引擎,帮您快速轻松的查找,保存和下载arXiv文章。
相关推荐
承渊政道8 分钟前
【从零开始大模型开发与微调:基于PyTorch与ChatGLM】(开源大模型ChatGLM高级定制化应用实战)AIgorithmGEEK5 小时前
MySQL 索引全解(下):建、查、删实战与知识速查表Smoothcloud润云6 小时前
PyTorch大模型权重加载与启动耗时优化实战:定位磁盘、内存与显存瓶颈databook7 小时前
从循环到向量化:NumPy提速的7个关键思维唠点键盘之外的7 小时前
26 向量数据库实战:从 0 搭一条能用的检索链路(pgvector + Spring AI)云和恩墨7 小时前
数据库监控简史:监控不止于告警——从图表大爆发到健康管理闭环ly76897 小时前
MongoDB 事务开销实测:快照隔离下的写冲突、重试与分片事务边界棉猴7 小时前
玩游戏学Python1-Python和pgzero库的安装豆角焖肉7 小时前
Spring AOP 自定义注解实现系统操作日志诺伦7 小时前
GEO优化数据实证:78%引用流向官网的机制拆解与小品牌三步管线实战教程 | RiseClaw玄策