读书笔记-设计模式-可复用版-Singleton 单例模式-腾讯游戏学院

Singleton单例设计模式是最简单，最常用，最易于理解的一种设计模式

你几乎可以在任何项目中看到Singleton使用的地方，只要对象是“独一无二”的，我们都可以设置成Singleton模式

（单例模式应该是所有模式中，最有的讲的，因为涉及到多线程会牵扯出来不少的额外的知识）

关键词：

1.lock&deadlock

2.lazy&greedy

3.memory barrier

4.beforeFieldInit

比如游戏中的各种管理器（GameManager，AchievementManager，LevelManager，LoginManager....),工具类，甚至是某些全局常驻的UI视图类，只要他是独一无二，

都可以定义为Singleton

概念：

保证当前类的实例，在整个程序的运行周期中，有且仅有一个实例，并提供一个访问它的全局接口。

单例模式，有如下几个特点：

1.这个类是无法直接进行new初始化的，类的构造函数需要设置为private私有

2.通常单例的类是密封的sealed（JIT优化），不可以派生重写，否则实例就不唯一了

3.单例要对外提供一个获取Instance实例的接口，且是静态的

最简单的单例模式例子：

我们直接通过Singleton.Instance.xxxx就可以方便的调用指定的方法了，在C#中，可以将Instance设置为属性，这样连()都不需要了

这是最简单的单例模式的代码，但这种写法非常的糟糕，下面会说明原因。

难道单例设计模式只有这一点儿可讲吗？

如果涉及到多线程，就需要处理同步的问题，并且在实际应用中，很常见，只要涉及到网络，通常都会涉及到多线程。

也就是说，上面的写法糟糕在它不是线程安全的(Thread Unsafe)!

他会带来的问题是，当我们去调用Instance()时，instance = new Singleton()可能会被初始化多次，这样实例就不唯一了！

举例说明：

public class InstanceTest

｛

private static InstanceTest instance;

private InstanceTest() ｛｝

public static InstanceTest GetInstance()

｛

if (instance == null)

｛

instance = new InstanceTest();

Debug.Log("create new instacne");

｝

return instance;

｝

public void SaySomething(string text)

｛

Debug.Log(text);

｝

定义一个简单的单例类，创建三个线程来调用

Thread thread = new Thread(new ThreadStart(ThreadTest));

thread.Name = "thread_1";

Thread thread2 = new Thread(new ThreadStart(ThreadTest));

thread2.Name = "thread_2";

Thread thread3 = new Thread(new ThreadStart(ThreadTest));

thread3.Name = "thread_3";

public void ThreadTest()

｛

InstanceTest.GetInstance().SaySomething("hello " + Thread.CurrentThread.Name);

｝

可以多运行几次，会发现有如下情况出现：

create new instance 被执行了两次，实例化了两次，因为同时有多个线程都执行到if(instance==null)判定的部分，也就分别创建了实例

为何会造成这种情况出现？

在执行判断语句之前，instance可能已经创建了，但内存模型并不能保证instance的值可以被其它的线程看到，除非通过了适当的内存屏障（Memory Barrier）

这里引出了一个新的概念：

这里提到的读写操作是保证了数据可以被其它的线程可见

Memory Barrier就是一条CPU指令，他可以确保操作执行的顺序和数据的可见性

编译器和 CPU 可以在保证输出结果一样的情况下对指令重排序，使性能得到优化，这样就会倒置，代码的编写顺序和内存的读写顺序因为重排序的原因，变成乱序了（但结果保证是一样的），但在多线程中，这种优化会带来数据不同步的问题。

再举个例子，比如你在编写代码的时候，先修改A，再修改B，但内存处理可能并不是按照这个顺序的，可能会调换位置，并且修改的值可能一直保存在了寄存器中，没有更新到缓存或是主存，这样其它线程读取的时候，并不能保证每次读取到的都是新值！

为了解决这种编码和内存读取乱序的问题，就出现了Memory Barrier(内存屏障）

相当于告诉 CPU 和编译器先于这个命令的必须”先“执行，后于这个命令的必须”后“执行。

内存屏障也会强制更新一次不同CPU的缓存，会将屏障前的写入操作，刷到到缓存中，这样试图读取该数据的线程，会得到新值。确保了同步。

有点儿抽象，上一个例子说明：

int _answer;

bool _complete;

void A()

｛

_answer = 123;

_complete = true;

｝

void B()

｛

if (_complete)

｛

Console.WriteLine(_answer);

｝

如果方法A和方法B，在不同的线程上并行，B得到的结果有没有可能是”0“？

答案是肯定的。上面提到过，CPU和编译器为了优化，会对CPU指令进行重排序

也可能会进行缓存优化，导致其它线程不能马上看到变量的值。

也就是说:

_answer = 123;

_complete = true;

_complete = true;因为指令重排序(reorder)可能会先执行，这样B输出的_answer就是0了。

解决方法就是添加内存屏障（Memory Barrier)

插入一个内存屏障，直接引用上面提到过后段话

"相当于告诉 CPU 和编译器先于这个命令的必须”先“执行，后于这个命令的必须”后“执行。内存屏障也会强制更新一次不同CPU的缓存，会将屏障前的写入操作，刷到到缓存中，这样试图读取该数据的线程，会得到新值。确保了同步。"

对例子做出如下修改：

int _answer;

bool _complete;

void A()

｛

_answer = 123;

Thread.MemoryBarrier(); // 屏障 1

_complete = true;

Thread.MemoryBarrier(); // 屏障 2

｝

void B()

｛

Thread.MemoryBarrier(); // 屏障 3

if (_complete)

｛

Thread.MemoryBarrier(); // 屏障 4

Console.WriteLine (_answer);

｝

屏障 1 和 4 可以使这个例子不会打印 “ 0 “。屏障 2 和 3 提供了一个“最新（freshness）”保证：它们确保如果B在A后运行，读取_complete的值会是true。

相关参考：

http://wiki.jikexueyuan.com/project/disruptor-getting-started/storage-barrier.html

https://blog.csdn.net/shanyongxu/article/details/48053675

https://www.zhihu.com/question/20228202

那么，如何处理多线程模式下，单例模式是线程安全的(Thread Safe)，即有没有更简

单的方法来处理指令重排序的问题？

通过lock语句，实际上，lock锁定，隐含的执行了Memory Barrier（内存屏障）

这篇文章进行了很好的讲解，在大话设计模式也有不错的解释

http://csharpindepth.com/Articles/Singleton#exceptions

（可以直接参考这两部分的资料）

线程安全的实现

通过lock语句，获取一个共享对象上的锁，保证当前只能有一个线程进入lock代码块，其它线程需要等待，lock语句执行时，会加锁，lock语句在结束以后，会释放锁，这样其它的进程才可以再进来，这样就保证了Instance不会被实例化多次。

在上面的网址中有这样一段话：

(as locking makes sure that all reads occur logically after the lock acquire, and unlocking makes sure that all writes occur logically before the lock release)

locking确保了所有逻辑上读取会在lock acquire(获取lock)之后发生，unlocking确保了所有逻辑上的写入会在lock release(lock释放)之前发生，这样就保证了，我在解锁前，instance的值会被写入到内存中，同时也就保证了下一个线程可以正确的获取instance的值，保证了有序性，也就不会出现Instance被创建两次的情况！

在之前的测试代码中，将方法做如下修改：

public void ThreadTest()

｛

lock(obj)

｛

InstanceTest.GetInstance().SaySomething("hello " + Thread.CurrentThread.Name);

｝

再执行，看看控制台的输出：

create new instance仅创建了一次，并且调用顺序也是有序的。

关于lock(xxx)中锁定的对象：

lock 关键字可确保当一个线程位于代码的临界区时，另一个线程不会进入该临界区。如果其他线程尝试进入锁定的代码，则它将一直等待（即被阻止），直到该对象被释放。

lock 关键字在块的开始处调用 Enter，而在块的结尾处调用 Exit。

private static readonly object padlock = new object();

是定义的私有的只读的共享对象，默认是CLR在启动装载时，就会创建，但在有些代码中，还可以见到这种写法：

lock(this)

lock(typeof(type))

lock("xxx")

三者一样糟糕

MSDN的文档中，并不建议这样做，因为一切public的地方，都是不安全的,超出了代码的控制范围，可能会产生deadlock (死锁）

应避免锁定 public 类型，否则实例将超出代码的控制范围。

Stackoverflow中也有讨论：

https://stackoverflow.com/questions/251391/why-is-lockthis-bad

大致翻译下，通常来讲，最好避免去锁定一个公共的类型（某个具体的类 typeof(type))，或者超出控制范围的对象实例（即公共的实例)，例如，如果实例可以被公共public说，那么，lock(this)会出现问题，因为这样，其它部分的代码也可以lock这个实例，这会带来的直接问题就是死锁，两个或多个线程等待同一个对象的释放。

锁定一个公共的数据类型(data type)，而不是对象，会引起相同的问题

锁定字符串是尤其危险的，字符串比较特殊，他是”暂留”在CLR运行时中，意味着，相同的字符串，实际上是全局同一个对象的，也会引起相同的问题，死锁(deadlock)

使用危险的字符串，模拟一个死锁的例子：

Thread thread = new Thread(new ThreadStart(DeadLock1));

thread.Name = "thread_1";

Thread thread1 = new Thread(new ThreadStart(DeadLock2));

thread1.Name = "thread_2";

thread.Start();

thread1.Start();

public void DeadLock1()

｛

lock ("A")

｛

Debug.Log(Thread.CurrentThread.Name + " get lock A");

lock ("B")

｛

Debug.Log(Thread.CurrentThread.Name + " get lock B");

｝

Debug.Log(Thread.CurrentThread.Name + " release lock B");

｝

Debug.Log(Thread.CurrentThread.Name + " release lock A");

｝

public void DeadLock2()

｛

lock ("B")

｛

Debug.Log(Thread.CurrentThread.Name + " get lock B");

lock ("A")

｛

Debug.Log(Thread.CurrentThread.Name + " get lock A");

｝

Debug.Log(Thread.CurrentThread.Name + " release lock A");

｝

Debug.Log(Thread.CurrentThread.Name + " release lock B");

｝

创建两个线程，分别执行DeadLock1,DeadLock2两个方法，运行结果是：

thread_1 get lock A

thread_2 get lock B

产生死锁！

解释下死锁的产生：

假设线程一先执行，线程一执行了DeadLock1，进入方法内部，lock("A")//获取引用对象“A"的锁，这时候，另外一个线程也执行了DeadLock2，lock("B")//获取引用对象“B"的锁

A和B均被锁住(locking)

假设A先继续向下执行，执行到lock("B")，但此时B被线程二锁住，线程一处于等待，

线程二继续执行，执行到lock("A"),但A被线程一锁住，尴尬情况就出现了，线程一在等待

线程二释放B，而线程二在等待线程一释放A，就这么僵持，死锁！

相应的，lock(this),lock(typeof(type)) 也会引起相同的问题，这里在使用中，一定要注意！

那么什么是最佳的写法？

最佳的方法就是提供一个private/protected的静态成员，控制他的访问范围，专门用于locking

private static readonly object padlock = new object();

lock(padlock)

｛

....

｝

现在接手的一个项目中，就是使用的lock(this),同事通过代码质量管理工具SonarQube，有提示此句有错误，当时不以为然......

通过locking,解决了同步的问题，但遗憾的是，通过上面可知，lock语句这么强大，肯定是有性能消耗的，所以这种方式在频繁的调用中，每次都要lock acquire/lock release,性能堪忧，尤其是放在Update中的时候......所以下面是一个优化的方案：

采用双重检查锁定（double-check locking)

乍看上去，代码很奇怪，为何要在lock的外面，再加一层if(instance==null)的判定

原因是当其中一个线程持有共享对象的锁，并进入lock语句，完成instance的创建，然后释放锁(这个过程的读取和写入都是在after lock acquire和before lock release发生的，也就确保内存上的数据会更新），下一个线程执行时，执行到if(instance==null)时会返回，因为上一个线程已经完成了Instance的创建，所以下一个线程就不会再执行lock语句了，这样就提高了性能，上面的代码是每一次都会调用lock，而加上double-check，就可以避免每次都调用lock了

通过双重检查锁定机制，性能有了一定的提升，但他还是不够好，在参考的文档中有说到，他没法在Java中执行等，还有更好的方法，即不使用lock

没有使用lock，但也是线程安全的(thread-safe)，这里使用到了静态构造函数

static Singleton()

｛｝

加上静态构造函数的原因是什么？

看上面有一段注释：

// Explicit static constructor to tell C# compiler

// not to mark type as beforefieldinit

显示声明静态构造函数，告诉 C#编译器，不要将类型(type)标记为beforefieldInit,可以理解为字段初始化之前。也就是说，默认是beforefieldInit

什么是beforeFieldInit?

这里有一篇文章进行了很详细的解释

http://csharpindepth.com/Articles/BeforeFieldInit

这是一个.Net中关于类型构造器执行时机的问题，有两种方案：

beforefiledinit(默认)

precise

这两个模式的切换只需要添加一个static构造函数即可，存在静态构造函数则是precise方案，

没有static构造函数则是beforefieldinit方案

C#编译器，默认是beforefieldInit（为了提高性能），类型的初始化会在静态字段调用之前执行或者说一进方法就会执行。比如：

public class MyClass

｛

public static readonly DateTime Time = GetNow();

private static DateTime GetNow()

｛

Debug.Log("GetNow execute!");

return DateTime.Now;

｝

void Start()

｛

Debug.Log("Main execute!");

Debug.Log("int: " + MyClass.Time);

｝

当我们调用Start函数时，输出结果如下：

方法中，Main execute明明应该先执行，现在是GetNow execute!先执行了，也就是MyClass.Time 静态成员先进行了初始化，然后再是Main execute!

最后是输出具体的时间

对于单例模式，这种执行顺序有的时候不是我们希望的，所以，为了解决这个问题，我们需要添加一个static静态构造函数

static MyClass()

｛｝

再次运行输出：

通常这才是我们需要的结果，所以在单例模式中，我们经常会看到一个静态构造函数（通常是空的!)，就是为了解决静态字段提前初始化的原因。

默认是beforefieldinit的原因是性能更好，因为beforefieldinit，JIT只需要检查一次类型是否被初始化，而precise,JIT则需要每次都要检查类型是否被初始化。

这种初始化的方式叫lazy initilizer，可以翻译为延时初始化，或是懒汉初始化，相应的也会有lazy load

lazy的意思是：只有在我调用的时候，我才去初始化它！

不调用的时候，他就一直处于未初始化的状态。

一定要添加static静态构造函数吗？答案是否定的，如果不带有静态构造函数，上面例子已经给出了，我们在方法中会调用该类的实例时，会先进行类型的初始化，这种方式被称为Greedy在，即饿汉式，只要我引用类中任意一个静态成员，调用之前，静态字段就会分配内存，而相应的Lazy是只有我调用的时候，才进行初始化。

严格意义上来讲，上面的不能算是完成的Full Lazy，在截图上说not quite as Lazy（没那么Lazy)，原因如果类中有其它的静态字段，那么调用任意的静态字段，其它的字段也会被初始化。

比如，添加如下方法并调用：

添加一个静态字段：

public static readonly DateTime Time1 = GetNow1();

private static DateTime GetNow1()

｛

Debug.Log("GetNow execute 1!");

return DateTime.Now;

｝

void Start()

｛

Debug.Log("Main execute!");

Debug.Log("Time:"+MyClass.Time1);

｝

只调用了MyClass.Time1，则Time静态字段也会被初始化

运行结果：

所以，他不能算严格意义上的Full Lazy.

所以他又提供了另外一个Full Lazy Version：

添加了一个Nested嵌套内部静态类，我只有调用Singleton.Instance时，Nested的静态字段才会被初始化。如果Singleton中有其它的静态方法，Nested均不会被初始化。

但通常，我们并不需要Full Lazy的版本，Fourth Version就可以满足了。

文档中还提供了最后一个实现版本：

如果你使用.Net 4或是更高的版本，可以使用System.Lazy<T> 实现Lazy版本，非常的简单，你要做的传递一个delegate，直接写一个Lamada表达式，里面初始化具体的Instance就好，简单且性能很好，并且你可以通过 IsValueCreated属性去判断Instance是否已经被创建。

上面的代码隐式地使用LazyThreadSafetyMode.ExecutionAndPublication作为Lazy<Singleton>的线程安全模式。

但很多Unity项目依然是使用Stable .Net 3.5的版本，所以只能等.Net 4(or higher)以后才可以使用。

在文章的最后做了一些关于性能方面的讨论，到底哪个方案最好，如果说你要在Update中，每帧调用，带有lock的会被认为最为低效的，但为什么不声明一个变量先保存他的引用，然后再在Update中调用呢，如果是这样的话，性能最差的版本，也可以获得不错的表现:)

这也是为何很多版本中，经常能够看到单一lock的实现方式，有的文章说double-check更安全，其实并不是，是为了提高性能，避免反复的lock，通常这种性能上的差异可以忽略不计，正如上面最后那段话说的那样。

我个人偏向于single lock,not quite as lazy,full lazy 版本，如果是在.Net4.0(or highter)，毫无疑问，我会选择System.Lazy<T>的版本

最后，如果当前的项目中，大量的应用了单例设计模式（只要满足实例全局独一无二），会引起什么问题？

1.调用方面，单例过多，不易于管理，可以通过维护一个关联列表或是使用外观设计模式（后面会讲到），提供统一的接口，减少依赖性

2.重复代码过多，单例部分的实现都是一样的，定义Instance,GetInstnace(),过多重复的代码显然不合理，可以通过泛型来提高复用性，减少重复的代码，且利于维护

范型单例：

public class Singleton<T> where T : class, new()

｛

private static readonly T instance = new T();

public static T Instance

｛

get

｛

return instance;

｝

public class InstanceTest : Singleton<InstanceTest>

｛

public static string Time = GetTime();

public static string GetTime()

｛

Debug.Log("Get Time");

return "2019.03.03";

｝

public void SaySomething(string text)

｛

Debug.Log(text);

｝

static InstanceTest()

｛｝

｝

调用代码：

InstanceTest.Instance.SaySomething("hello my buddy!");

对于静态构造函数：

static InstanceTest()

｛｝

通常不需要添加，没有那么严格的使用环境

Singleton<T>泛型的实现，还可以使用lock(single check or double check):

public class Singleton<T> where T : class, new()

｛

private static T instance;

private static readonly object padLock = new object();

public static T Instance

｛

get

｛

if (instance == null)

｛

lock (padLock)

｛

if (instance == null)

｛

instance = new T();

｝

return instance;

｝

效果是一样的，只是性能上，相比第一个肯定要差一些，但上面的讨论中也提到，如果你一定要在Update中循环调用，应该声明一个引用来缓存它。这样两者之间的差别就可以忽略不计了。

最后说一说在Unity中的Singleton泛型如何实现，游戏中会有众多的MonoBehaviour，同样，我们也不需要每一个都实现重复的代码，下面的代码是Unity中实现Singleton的泛型模板，大致说下原理。

* Singleton.cs

* - Unity Implementation of Singleton template

using UnityEngine;

/// <summary>

/// Be aware this will not prevent a non singleton constructor

/// such as `T myT = new T();`

/// To prevent that, add `protected T () ｛｝` to your singleton class.

///

/// As a note, this is made as MonoBehaviour because we need Coroutines.

/// </summary>

public class Singleton<T> : MonoBehaviour where T : MonoBehaviour

｛

private static T _instance;

private static object _lock = new object();

public static T Instance

｛

get

｛

if (applicationIsQuitting) ｛

Debug.LogWarning("[Singleton] Instance '"+ typeof(T) +

"' already destroyed on application quit." +

" Won't create again - returning null.");

return null;

｝

lock(_lock)

｛

if (_instance == null)

｛

_instance = (T) FindObjectOfType(typeof(T));

if ( FindObjectsOfType(typeof(T)).Length > 1 )

｛

Debug.LogError("[Singleton] Something went really wrong " +

" - there should never be more than 1 singleton!" +

" Reopenning the scene might fix it.");

return _instance;

｝

if (_instance == null)

｛

GameObject singleton = new GameObject();

_instance = singleton.AddComponent<T>();

singleton.name = "~"+ typeof(T).ToString();

DontDestroyOnLoad(singleton);

Debug.Log("[Singleton] An instance of " + typeof(T) +

" is needed in the scene, so '" + singleton +

"' was created with DontDestroyOnLoad.");

｝ else ｛

Debug.Log("[Singleton] Using instance already created: " +

_instance.gameObject.name);

｝

return _instance;

｝

private static bool applicationIsQuitting = false;

/// <summary>

/// When Unity quits, it destroys objects in a random order.

/// In principle, a Singleton is only destroyed when application quits.

/// If any script calls Instance after it have been destroyed,

/// it will create a buggy ghost object that will stay on the Editor scene

/// even after stopping playing the Application. Really bad!

/// So, this was made to be sure we're not creating that buggy ghost object.

/// </summary>

public void OnDestroy () ｛

applicationIsQuitting = true;

｝

MonoBehaviour是不能new实例化，通过我们在Awake中完成构造，所以和上面的有一定的区别。

MonoBehaviour均是存在于Scene中某一个GameObject上，Singleton是整个生命周期中有且仅有一个实例，所以需要将GameObject设置为DontDestroyOnLoad，这样UnLoadScene时，该GameObject不会被释放，Singleton依然可以正常使用。

还有一种情况，虽然是MonoBehaviour，但我并没有附加在任何一个GameObject上，这时候然调用的时候，会创建一个空的GameObject,并将Type以组件的形式添加到GameObject，并设置为DontDestroyOnLoad

默认使用单例的组件，都应该是DontDestroyOnLoad的，我们通常是启动的时候创建他们，而不是在游戏的过程中动态的处理，所以这里出现了另外一种情况，在某个GameObject上绑定了单例的类，但没有任何脚本执行了DontDestroyOnLoad，通过Singleton<T>调用的时候，

并不会主动的将当前的GameObject设置为DontDestroyOnLoad，那么当场景Unload的时候，

单例就会被释放，而出现调用Null的情况，要避免这种情况，尽量不要动态的去添加单例对象。它们应该预加载。

最后提下在最近的工作上，碰到了一个关于单例设计模式的坑，上面有提到，只要是”独一无二的“的对象，通常都可以做成单例模式

因为接手的是一个第三方CP的项目，犹豫前期对代码的不了解以及一些疏忽，游戏中的GameComponent组件（游戏功能菜单），我们为了方便使用，设计成了单例模式（游戏并没有基于观察者模式去实现UI上的交互）

因为当前的场景中，只有一个GameComponent，这样使用单例是没有问题的，后来发现，当我们加载多人游戏的Scene时，我们调用GameComponent接口，功能不正常了，原因是多人游戏场景的Prefab中也绑定了一个GameComponent

这样就会倒置,GameComponent.Instance静态实例，在加载了多人游戏的Scene时，指向了多人游戏的GameComponent

void Awake()

｛

instance = this;

｝

而且在退出多人游戏后，逻辑上并没有直接Unload Scene，仅仅只是隐藏了Scene，GameComponent.Instance始终还是指向多人游戏的GameConponent，这样我们在调用GameComponent的接口时，影响的还是多人游戏，而单人游戏的GameComponent，并没有变化，这种问题很难发现，所以一定要注意这种情况！

先到此为止，没有想到的是小小的单例模式牵扯出来这么多的内容，周末晚愉快，take a snooze，然后去吃张记烤羊腿~)

参考文献：

1.设计模式-可复用版

2.大话设计模式

3.http://csharpindepth.com/Articles/Singleton#exceptions

4.http://www.cnblogs.com/tianguook/p/3663651.html

5.https://blog.csdn.net/gdou_yun/article/details/53131781

感谢您的阅读，如文中有误，欢迎指正，共同提高

欢迎关注我的技术分享的微信公众号，Paddtoning帕丁顿熊，期待和您的交流

Recommend

好洗得 Wash Duck - 香港的洗衣服务 - NEXT

微信难下神坛

一年内“三降两涨”五度调价，用户质疑特斯拉善变营销如儿戏

想发言先交钱，这个以字数计费的聊天室遍地是大佬

贾跃亭或新涉8000万美元诉讼 FF债权融资将公布

两运营商净利相差5倍杨杰如何掌舵中国移动？

iOS 数据持久化方案-Realm的使用 - 简书

平时上网用的 IP 地址，到底能暴露多少信息？

图解：单链表反转的三种方式！

分布式系统关注点——“拆库“

About Joyk