对于系统中的某些类来说，只有一个实例很重要，例如，一个系统中可以存在多个打印任务，但是只能有一个正在工作的任务；一个系统只能有一个窗口管理器或文件系统；一个系统只能有一个计时工具或ID（序号）生成器。
如何保证一个类只有一个实例并且这个实例易于被访问呢？定义一个全局变量可以确保对象随时都可以被访问，但不能防止我们实例化多个对象。
一个更好的解决办法是让类自身负责保存它的唯一实例。这个类可以私有化构造函数来保证没有其他实例被创建，并且它可以提供一个访问该实例的方法。这就是单例模式的模式动机。
定义：
确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例 单例模式的要点有三个：
- 一是某个类只能有一个实例；
- 二是它必须自行创建这个实例；
- 三是它必须自行向整个系统提供这个实例。
类图：
标准代码：
//单例模式
class Singleton
{
//限制产生多个对象
private Singleton() { }
private static Singleton ins = new Singleton();
public static Singleton GetInstance()
{
return ins;
}
public void Fun()
{
Console.WriteLine("hello world");
}
}
单例模式的几种实现方式
1.懒汉式，线程不安全
class Singleton
{
//限制产生多个对象
private Singleton() { }
private static Singleton ins;
public static Singleton GetInstance()
{
if (ins == null)
{
ins = new Singleton();
}
return ins;
}
}
是否 Lazy 初始化：是
是否多线程安全：否
描述：这种方式是最基本的实现方式，这种实现最大的问题就是不支持多线程。因为没有加锁 synchronized，所以严格意义上它并不算单例模式。
这种方式 lazy loading 很明显，不要求线程安全，在多线程不能正常工作。
2.懒汉式，线程安全
class Singleton
{
//限制产生多个对象
private Singleton() { }
private static Singleton ins;
//用来提供Lock锁的数据
static readonly object locker = new object();
public static Singleton GetInstance()
{
lock(locker )
{
if (ins == null)
{
ins = new Singleton();
}
return ins;
}
}
}
是否 Lazy 初始化：是
是否多线程安全：是
描述：这种方式具备很好的 lazy loading，能够在多线程中很好的工作，但是，效率很低，99% 情况下不需要同步。
优点：第一次调用才初始化，避免内存浪费。
缺点：必须加锁 synchronized 才能保证单例，但加锁会影响效率。
总体就是能做到懒加载，而且保证只实例化一个实例。但是如果项目中频繁的调用GetInstance()方法，会造成性能低下的问题，因为这个锁。
3.双检锁/双重校验锁（DCL，即 double-checked locking）
class Singleton
{
//限制产生多个对象
private Singleton() { }
private static Singleton ins;
//用来提供Lock锁的数据
static readonly object lockedValue = new object();
public static Singleton GetInstance()
{
//这句是为了调用该方法时，只调用一次
if (ins == null)
{
//这句是避免多个线程同时执行到此，多次初始化，因此加锁。
lock (lockedValue)
{
if (ins == null)
{
ins = new Singleton();
}
}
}
return ins;
}
}
是否 Lazy 初始化：是
是否多线程安全：是
描述：这种方式采用双锁机制，安全且在多线程情况下能保持高性能。
getInstance() 的性能对应用程序很关键。
4.饿汉式
class Singleton
{
//限制产生多个对象
private Singleton() { }
private static Singleton ins = new Singleton();
public static Singleton GetInstance()
{
return ins;
}
}
是否 Lazy 初始化：否
是否多线程安全：是
描述：这种方式比较常用，但容易产生垃圾对象。
优点：没有加锁，执行效率会提高。
缺点：类加载时就初始化，浪费内存。
它基于 classloder 机制避免了多线程的同步问题，不过，instance 在类装载时就实例化，虽然导致类装载的原因有很多种，在单例模式中大多数都是调用 getInstance 方法， 但是也不能确定有其他的方式（或者其他的静态方法）导致类装载，这时候初始化 instance 显然没有达到 lazy loading 的效果。
5.登记式/静态内部类
class Singleton
{
//限制产生多个对象
private Singleton() { }
class SingletonHolder
{
public static Singleton ins = new Singleton();
}
public static Singleton GetInstance()
{
return SingletonHolder.ins;
}
}
是否 Lazy 初始化：是
是否多线程安全：是
描述：这种方式能达到双检锁方式一样的功效，但实现更简单。对静态域使用延迟初始化，应使用这种方式而不是双检锁方式。这种方式只适用于静态域的情况，双检锁方式可在实例域需要延迟初始化时使用。
想象一下，如果实例化 instance 很消耗资源，所以想让它延迟加载，另外一方面，又不希望在 Singleton 类加载时就实例化，因为不能确保 Singleton 类还可能在其他的地方被主动使用从而被加载，那么这个时候实例化 instance 显然是不合适的。这个时候，这种方式就显得很合理。
这种方式既能满足单例模式的要求，又能懒加载，又满足线程安全。简直秒啊，唯一缺点就是需要多一个内部类；
Unity中的单例模式
MonoBehaviour和一般的类有几个重要区别，体现在单例模式上有两点。
第一，MonoBehaviour不能使用构造函数进行实例化，只能挂载在GameObject上。
第二，当切换场景时，当前场景中的GameObject都会被销毁（LoadLevel带有additional参数时除外），这种情况下，我们的单例对象也会被销毁。
方法1：简单，但是可能会导致bug
public class Singleton : MonoBehaviour {
//私有化构造方法，不能new对象，只能通过Singleton.instance的方法得到对象
private Singleton() { }
public static Singleton instance;
void Awake () {
instance = this;
}
}
这种方法比较简单，需要注意的当前场景中只能有一个物体挂载此脚本。在其他类中通过Singleton.instance得到的对象就是该物体上挂载的脚本对象。
方法2：实用
实例化（Awake）对象的时候，我们得保证场景当中只有一个实例，我们要对当前场景中的单例个数进行判断。
获取单例ins的时候，我们 得保证得到的是唯一对象。如果调用单例的时候，单例物体还没创建，我们需要手动创建一个。
为了使之不被销毁，我们需要进行DontDestroyOnLoad的处理。
因此，构建单例的方式会变成这样：（例子是游戏中只需要一个GameInputManager单例对象处理Input输入即可）
using UnityEngine;
public class GameInputManager : MonoBehaviour
{
//私有化构造函数，避免外界实例化
private GameInputManager() { }
private static GameInputManager _ins = null;
public static GameInputManager ins { get { return GetInsance(); } }
static GameInputManager GetInsance()
{
//说明是第一次访问
if (_ins == null)
{
_ins = new GameObject("Instance_GameInputManager").AddComponent<GameInputManager>();
GameObject.DontDestroyOnLoad(_ins.gameObject);
}
return _ins;
}
//单例是否初始化了
private static bool isInitialized = false;
private void Awake()
{
Debug.Log("Awake...");
if (_ins != null)
{
Debug.LogError("游戏中只允许存在一个该脚本，已存在，不允许再次添加");
GameObject.Destroy(this);
return;
}
_ins = this;
GameObject.DontDestroyOnLoad(gameObject);
}
}
私有构造函数避免了在外部实例化单例对象。用属性get保证了懒加载。
既实现了只有一个单例实例对象，也保证了不随场景销毁。
方法3：进阶，通用
游戏中一般存在较多的单例，如果每个单例脚本都想上面一样再写一遍代码，会显得繁琐。所以我们可以利用泛型来简化这一过程。
写一个单例的泛型抽象基类，相当于模版，之后的具体单例代码只需要继承该基类即可：
单例泛型基类：（GameSingleInstance.cs）
using UnityEngine;
public abstract class GameSingleInstance<T>: MonoBehaviour where T:MonoBehaviour
{
//私有化构造函数，避免外界实例化
protected GameSingleInstance() { }
protected static T _ins = null;
public static T ins { get { return GetInsance(); } }
//避免某物体在OnDestroy里面调用单例，导致创建新对象报错
static bool isapplicationIsQuit = false;
static T GetInsance()
{
//说明是第一次访问
if (_ins == null && !isapplicationIsQuit)
{
string name = "Instance_" + typeof(T);
_ins = new GameObject(name).AddComponent<T>();
GameObject.DontDestroyOnLoad(_ins.gameObject);
}
return _ins;
}
protected void OnApplicationQuit()
{
isapplicationIsQuit = true;
}
protected void OnDestroy()
{
isapplicationIsQuit = true;
}
}
具体的单例子类 ：（比如是监听游戏输入的单例 GameInputManager.cs）
using UnityEngine;
public class GameInputManager:GameSingleInstance<GameInputManager>
{
//私有化构造函数，避免外界实例化
private GameInputManager() { }
private void Awake()
{
Debug.Log("Awake...");
if (_ins != null)
{
Debug.LogError("游戏中只允许存在一个该脚本，已存在，不允许再次添加");
GameObject.Destroy(this);
return;
}
_ins = this;
GameObject.DontDestroyOnLoad(gameObject);
}
private void Update()
{
if(Input.GetMouseButtonDown(0))
Debug.Log("鼠标左键按下");
}
}
Awake里面的判断，是为了防止在游戏内添加或者拖拽多个该单例脚本。
外界调用：
GameInputManager.ins.xxx;
这样，既能实现单例的功能，又能减少代码量。
单例模式的优点
- 提供了对唯一实例的受控访问。因为单例类封装了它的唯一实例，所以它可以严格控制客户怎样以及何时访问它，并为设计及开发团队提供了共享的概念。
- 由于在系统内存中只存在一个对象，因此可以节约系统资源，对于一些需要频繁创建和销毁的对象，单例模式无疑可以提高系统的性能。
- 允许可变数目的实例。我们可以基于单例模式进行扩展，使用与单例控制相似的方法来获得指定个数的对象实例。
单例模式的缺点
- 由于单例模式中没有抽象层，因此单例类的扩展有很大的困难。
- 单例类的职责过重，在一定程度上违背了“单一职责原则”。因为单例类既充当了工厂角色，提供了工厂方法，同时又充当了产品角色，包含一些业务方法，将产品的创建和产品的本身的功能融合到一起。
扫一扫
516
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
