DI on 纪伟的个人博客

设计模式实战（八）：单例模式——全局唯一与它的反模式面

Tue, 30 Dec 2025 10:00:00 +0800

写在前面

单例是 23 个模式里名声最差的一个——不是因为它没用，而是因为它被滥用得最狠。新手最爱写单例（Instance 多酷），然后收获一堆"测试不了、并发炸了、依赖藏起来"的坑。

这篇不光讲怎么写单例，更要讲怎么别写单例——以及 .NET DI 容器提供的正确姿势。

一、问题：全局唯一实例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


有些对象，整个进程只要一个：
 - 配置读取器（Configuration）
 - 日志工厂（LoggerFactory）
 - 数据库连接池
 - 全局缓存（IMemoryCache）
 - 设备访问（打印机、硬件接口）

 为什么必须唯一：
 - 多个实例浪费资源（重复加载配置、多个连接池）
 - 多个实例导致状态不一致（两个缓存各存各的）
 - 有些资源本身是单点的（一个打印机）

 → 需求：保证一个类只有一个实例，全局可访问。
 → 这就是单例模式。

二、单例：保证全局唯一

1
2
3
4
5
6
7
8


意图：确保一个类只有一个实例，并提供全局访问点。

 要点：
 1. 构造函数私有（外部不能 new）
 2. 类内持有一个静态实例
 3. 提供一个静态访问点（Instance）

 关键词：唯一 + 全局可访问。

三、.NET 线程安全的几种写法

单例最大的技术难点是多线程下也要保证唯一。几种写法，从糙到精：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


// ❌ 错：非线程安全，多线程下可能造出多个
public class BadSingleton
{
 private static BadSingleton? _instance;
 public static BadSingleton Instance =>
 _instance ??= new BadSingleton(); // 竞态：两个线程同时进来
}

// ✅ 写法 1：双检锁（经典，但要 volatile + lock）
public class DclSingleton
{
 private static DclSingleton? _instance;
 private static readonly object _lock = new();
 public static DclSingleton Instance
 {
 get
 {
 if (_instance is null) // 一检：已有就直接返，避免锁开销
 lock (_lock)
 if (_instance is null) // 二检：进了锁再确认一次
 _instance = new DclSingleton();
 return _instance;
 }
 }
}

// ✅✅ 写法 2：静态只读字段（最简洁，CLR 保证线程安全的懒初始化）
public class StaticSingleton
{
 public static readonly StaticSingleton Instance = new();
 private StaticSingleton() { } // 私有构造
} // CLR 在首次访问类时初始化 static 字段，且保证线程安全

// ✅✅✅ 写法 3：Lazy<T>（显式控制，延迟到首次访问 Instance）
public class LazySingleton
{
 private static readonly Lazy<LazySingleton> _lazy = new(() => new LazySingleton());
 public static LazySingleton Instance => _lazy.Value; // 线程安全 + 懒加载
 private LazySingleton() { }
}

1
2


现代 .NET 推荐：写法 2（static readonly，最简洁）或写法 3（Lazy<T>，最灵活）。
双检锁是 Java 时代的老黄历，C# 里基本不用了。

四、但请优先用 DI 容器的 Singleton

上面三种手写单例，现代 .NET 开发几乎都不用。理由是 DI 容器给了更干净的方案：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// 注册为 Singleton —— 容器保证全局唯一
services.AddSingleton<IConfigurationReader, JsonConfigurationReader>();
services.AddSingleton<ILoggerFactory, LoggerFactory>();
services.AddSingleton<IMemoryCache, MemoryCache>();

// 用：构造函数注入，不直接碰 Instance
public class OrderService(IConfigurationReader _config, IMemoryCache _cache)
{
 ...
}

1
2
3
4
5
6
7
8
9


DI Singleton vs 手写单例：

 ✓ 全局唯一由容器保证（你不用操心线程安全）
 ✓ 显式依赖（构造函数注入，依赖一目了然，不藏）
 ✓ 可测试（单测时换 Transient/假实现，改注册即可）
 ✓ 生命周期集中管理（Singleton/Scoped/Transient 统一规则）
 ✓ 没有静态全局状态（Instance 全局可访问 = 反模式，下面讲）

 → 唯一性需求，首选 services.AddSingleton，别手写 Instance。

五、单例的反模式面（为什么名声差）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


手写单例（静态 Instance）的五大罪：

 1. 全局状态
 Instance 是全局可变点，任何代码都能访问修改
 → 状态在程序各处飘，谁改的、什么时候改的，无从追踪

 2. 隐藏依赖
 public void DoWork() { Config.Instance.Get(...) }
 → 方法签名看不出依赖 Config，像个隐式全局变量
 → 代码可读性、可测试性都差

 3. 测试困难
 单元测试想隔离，但 Instance 是全局静态，没法 mock/替换
 → 测试时不得不连真实配置/真实缓存
 → 详见《.NET 单元测试（四）：依赖注入与可测试性》

 4. 并发陷阱
 单例被多线程共享，状态必须自己加锁保护
 → 稍不留神就是竞态、死锁

 5. 生命周期捕获（.NET DI 专属大坑）
 services.AddSingleton<Foo>(); Foo 注入了一个 Scoped 服务
 → Singleton 持有 Scoped，Scoped 被强制升级为单例
 → 跨请求共享本不该共享的状态，数据串了
 → 容器会抛异常提醒（Cannot resolve scoped service from root provider）

 所以社区共识：能不用手写单例就不用，用 DI Singleton 替代。

六、什么时候仍需要单例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


不全是反模式，少数场景仍合理：

 ✓ 互斥的外部资源（硬件接口、单点打印机、全局信号量）
 ✓ 框架/底层组件的引导（LoggerFactory、Configuration 根）
 ✓ 性能敏感、确实只要一份的全局缓存

 但即便这些，也优先用 DI Singleton 表达"唯一性"，
 只在"必须用静态全局访问点"时（如扩展方法里取服务、遗留代码）才手写。

 判断：要的是"唯一性"，还是"全局可访问"？
 多数时候只要"唯一性" → DI Singleton 就够。
 真需要"全局随便谁能取"才手写 Instance。

七、何时用 / 何时别用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


该用（以 DI Singleton 形式）：
 ✓ 确需进程内唯一的共享资源（配置、缓存、连接池、日志工厂）
 ✓ 构造昂贵、可复用的无状态服务

别用：
 ✗ 只是为了"方便取"就上单例 → 那是全局变量，用依赖注入
 ✗ 有状态的"上下文"对象 → 单例会跨请求/跨线程串数据
 ✗ 为了少传参数 → 把依赖藏进单例 → 测试灾难
 ✗ Singleton 注入 Scoped 服务（生命周期捕获）

 信号：当你想写 `static Instance` 时，先问自己：
 "我能不能用 services.AddSingleton + 构造函数注入 代替？"
 99% 的答案是可以。

八、小结

意图：保证一个类只有一个实例，全局可访问
手写：私有构造 + 静态实例；线程安全用 static readonly 或 Lazy<T>（双检锁过时了）
正确姿势：services.AddSingleton<T>() —— 容器保证唯一，干净、可测
反模式五罪：全局状态、隐藏依赖、测试困难、并发陷阱、生命周期捕获（Singleton 注入 Scoped）
多数时候你要的是"唯一性"而非"全局可访问" → DI Singleton 足矣，别手写 Instance
要单例，先想 DI；手写静态 Instance 是最后手段

下一篇（收官）讲命令与状态模式——正好接上 DDD 里的 CQRS Command 和订单状态机，给整个模式系列收口。

设计模式实战（三）：工厂模式——创建对象的烦恼与 DI 容器

Wed, 10 Dec 2025 10:00:00 +0800

写在前面

上一篇策略模式解决了"选算法"。这篇讲创建型模式的代表——工厂模式，解决"造对象"。

很多新手觉得工厂模式绕：简单工厂、工厂方法、抽象工厂，三个名字像、又不一样。这篇把它们一次讲清，并落到 .NET 上——你会发现 DI 容器本身就是个超级工厂，现代 .NET 开发里，大部分时候你不用手写工厂。

一、问题：到处 new

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 反例：直接 new，和具体类型死死绑死
public class OrderService
{
 public void Place(Order order)
 {
 var repo = new SqlOrderRepository(); // 写死具体实现
 var notifier = new EmailNotifier(); // 写死
 repo.Save(order);
 notifier.Send(order);
 }
}

1
2
3
4
5
6
7
8
9


这坨代码的病：
 ✗ 依赖具体类（SqlOrderRepository），不是抽象
 → 违反依赖倒置（DIP）
 ✗ 换实现（改 Mongo、换短信通知）要改这里
 ✗ 没法注入假实现做单元测试
 ✗ 如果构造对象本身复杂（要查配置、要条件判断），new 就更难看

 病根：对象"怎么造"和对象"怎么用"搅在一起了。
 解法：把"造"的责任抽出去——这就是工厂。

二、简单工厂（静态工厂）

最朴素：一个方法，按参数决定造哪个。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


public static class DiscountFactory
{
 public static IDiscountStrategy Create(string type) => type switch
 {
 "Normal" => new NormalDiscount(),
 "Vip" => new VipDiscount(),
 "Employee" => new EmployeeDiscount(),
 _ => throw new ArgumentException($"未知折扣类型: {type}")
 };
}
// 用：var d = DiscountFactory.Create("Vip");

1
2
3
4
5
6
7


特点：
 ✓ 简单，集中了创建逻辑，调用方不关心具体类
 ✗ 严格说它不是"GoF 模式"，只是个习惯用法
 ✗ 违反开闭：加新类型要改这个 switch

 适合：创建逻辑简单、类型不多、不频繁变化。
 （上一篇策略模式里的"字典派发"，其实就是简单工厂的现代版。）

三、工厂方法（Factory Method）

把"创建"推迟到子类：父类定义流程，子类决定造哪个。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


// 父类：定义"创建 + 使用"的流程，但"造哪个"交给子类
public abstract class NotificationSender
{
 protected abstract INotifier CreateNotifier(); // 工厂方法（抽象）

 public void Send(string msg)
 {
 var notifier = CreateNotifier(); // 用子类造的对象
 notifier.Send(msg);
 }
}

// 子类 A：决定造 EmailNotifier
public class EmailSender : NotificationSender
{
 protected override INotifier CreateNotifier() => new EmailNotifier();
}
// 子类 B：决定造 SmsNotifier
public class SmsSender : NotificationSender
{
 protected override INotifier CreateNotifier() => new SmsNotifier();
}

1
2
3
4
5
6


vs 简单工厂：
 简单工厂：一个方法里 switch（加类型改 switch）
 工厂方法：每种类型一个子类（加类型加子类，老代码不动 → 开闭）

 代价：类变多。
 适合：创建逻辑需要配合一套"使用流程"，且类型会扩展。

四、抽象工厂（Abstract Factory）

造一"族"相关对象，保证它们配套。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


// 工厂接口：造一族 UI 控件
public interface IUiFactory
{
 IButton CreateButton();
 ITextBox CreateTextBox();
}
// 一族：Windows 风格
public class WindowsUiFactory : IUiFactory
{
 public IButton CreateButton() => new WindowsButton();
 public ITextBox CreateTextBox() => new WindowsTextBox();
}
// 另一族：Mac 风格
public class MacUiFactory : IUiFactory
{
 public IButton CreateButton() => new MacButton();
 public ITextBox CreateTextBox() => new MacTextBox();
}

1
2
3
4
5
6
7
8
9


vs 工厂方法：
 工厂方法：造"一个"产品（一个方法）
 抽象工厂：造"一族"配套产品（多个方法）

 价值：保证造出来的一组对象是配套的（不会 Windows 按钮配 Mac 文本框）。
 典型场景：跨平台 UI、多数据库方言、多主题样式。

 注意：抽象工厂常被滥用。如果只有一种产品，用工厂方法/简单工厂就够，
 别为了"显得有体系"上抽象工厂。

五、三者对比

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


 造什么 加新产品 复杂度 适用
─────────────────────────────────────────────────────────────
简单工厂 单个产品 改 switch 低 类型少、简单
工厂方法 单个产品 加子类 中 类型会扩展
抽象工厂 一族产品 加子类+改接口 高 多族配套、跨平台

 记忆窍门：
 简单工厂 = 一个函数 switch
 工厂方法 = 把函数变成虚方法，让子类决定
 抽象工厂 = 工厂方法升级版，一个工厂造多个配套产品

六、.NET DI 容器 = 超级工厂

现代 .NET 里，你几乎不用手写工厂——DI 容器（IServiceCollection / IServiceProvider）就是工厂的终极形态。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// 注册：告诉"工厂"接口对应什么实现
services.AddScoped<IOrderRepository, SqlOrderRepository>();
services.AddSingleton<INotifier, EmailNotifier>();
services.AddTransient<IDiscountStrategy, VipDiscount>();

// 用：从"工厂"要对象，不关心怎么造
public class OrderService(IOrderRepository _repo, INotifier _notifier)
{
 public void Place(Order o) { _repo.Save(o); _notifier.Send(o); }
}

1
2
3
4
5
6
7
8


DI 容器相比手写工厂：
 ✓ 自动接管创建，包括依赖链（A 依赖 B，B 依赖 C，容器递归造）
 ✓ 生命周期（Singleton/Scoped/Transient）集中管理
 ✓ 切换实现 = 改注册一行，不改业务代码
 ✓ 测试时换假实现 = 改注册，详见《.NET 单元测试（四）：依赖注入与可测试性》

 → 这就是为什么 ASP.NET Core 里很少看到手写 XxxFactory：
 DI 把"工厂模式"这件事彻底标准化了。

需要手写工厂的场景

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


// 场景：运行时才能决定造哪个（配置/类型/参数）
services.AddScoped<IOrderRepository>(sp =>
{
 var config = sp.GetRequiredService<IConfiguration>();
 return config["Db"] == "Mongo"
 ? new MongoOrderRepository(config["Conn"])
 : new SqlOrderRepository(config["Conn"]);
}); // 工厂 lambda：容器调用时才执行

// 场景：解析未知类型（插件/动态加载）
var handler = ActivatorUtilities.CreateInstance(sp, typeFromConfig);
// 或按 key 取一批已注册的服务（variance）

1
2
3
4
5
6


什么时候仍要手写工厂：
 - 运行时根据配置/类型决定实现（DI 注册时还不确定）
 - 动态解析、插件化、按 key 派发（容器不直接支持"按字符串取"）
 - 构造对象需要运行时参数（不能预先注册）

 其余情况，让 DI 容器当你的工厂。

七、小结

问题：到处 new 把"造"和"用"绑死，违反依赖倒置
简单工厂：一个方法 switch 决定造哪个（类型少时够用）
工厂方法：抽象方法交给子类决定（加类型加子类，开闭）
抽象工厂：造一族配套产品（跨平台/多主题）
选型：简单→简单工厂；扩展→工厂方法；多族配套→抽象工厂
.NET DI 容器是终极工厂：日常开发基本不手写工厂，改注册即可
手写工厂仍有场景：运行时决定、动态解析、运行时参数

下一篇讲建造者模式——当构造对象本身很复杂（一堆可选参数）时，怎么造得优雅。