一、前言

之前写过一篇关于单例的文——C#中单例模式的实现，讲了讲单例是什么以及在C#中的常见代码实现，那篇文的内容偏理论，并不实用。

最近在用WPF写上位机，发现我在实际开发中使用单例时，并不关心其底层实现，也不太会出现这样的单例类代码：

using System;public sealed class Singleton
{private static volatile Singleton instance;private static object syncRoot = new Object();private Singleton() {}public static Singleton Instance{get {if (instance == null) {lock (syncRoot) {if (instance == null) instance = new Singleton();}}return instance;}}
}

而往往是创建一个服务容器（ServiceProvider），然后把想要实现单例的类以单例模式加入其中，并将服务容器公开（通常是放在App类中）以使整个程序代码都能访问之，在想要用到该单例时，从容器中取出即可：

public IServiceProvider Services { get; }private static IServiceProvider ConfigureServices()
{var services = new ServiceCollection();services.AddSingleton<Class>();...return services.BuildServiceProvider();
}

如果你还没有用过这种容器的方式，可能会觉得很麻烦；而一旦接受了这种方式，你会发现它变成了一种定式。几乎所有应用程序都可以这么做（服务容器的这种方式本身也是一种设计模式Ioc）。

这些内容不是本文要讲的东西，本文主要想讲讲上位机程序中单例的应用，以及一个场景该怎样使用单例的思考。

二、上位机单例应用场景

2.1 上位机

先提一下上位机，
上位机通常不是什么庞大的程序，它主要用以：

提供界面，用户可友好操作；
与下位机通讯，将采集的数据加工，并呈现在界面上；
将部分数据存储至数据库，以供报表、查询、统计分析；
与更上层的系统（MES、ERP等）进行对接；
可能还会结合一些专业技术（如视觉、文档处理等）辅助生产。

这样一个体量不大的用于专门设备的程序，其涉及的技术还是挺广的。

2.2 单例及其应用

单例的目的是为了保证一个类在程序中只有一个实例，并提供一个访问它的全局访问点。
很明显，单例这样的设计使一个类只有一个实例，并且要易于外界访问，从而方便对实例进行控制并节约系统资源。

因此，它的应用场景通常为：

有频繁实例化（也就是频繁new）然后销毁的情况；
创建对象耗时过多或者耗资源过多的情况；
频繁访问IO资源的对象，如数据库连接池或文件。

我相信很多人第一次使用单例并不是因为性能的问题，而仅仅想要一个类似于C语言中全局变量的东西，希望有一个类的实例能被不同页面的代码访问到。这其实就是单例中提到的提供全局访问点的特性。

这边有一个大家非常熟悉的应用——Windows上的任务管理器。ctrl + shift + esc打开，并且无论你按多少次，都只会出现一个任务管理器。也就是说，在Windows系统这个程序中，任务管理器是唯一的。

那为什么这样设计，不这样设计会怎样呢？

如果弹出了多个任务管理器窗口，且这些窗口展示的内容完全一致，这样打开的就全是重复的对象了，就会造成系统资源的浪费，内存的损耗。实际使用中根本不需要多个呈现相同内容的窗口。
如果弹出了多个任务管理器窗口，且内容不一致，那就更糟糕了。这意味着，某一时刻应用的使用情况和进程、服务等信息存在多个状态，那到底哪个才是真实的呢？显然这更不可取。

由此可见，确保任务管理器在系统中有且仅有一个非常重要。