为了系统健壮成长，请慎用单例模式

        所谓的单例模式指的就是确保一个类只有一个实例，并为其提供一个全局访问入口。这在我们日常开发中很实用。

        在有些情况下，一个类如果有多个实例就不能正常运作。最常见的就是，这个类与一个维持着自身全局状态的外部系统进行交互的情况。比如一个封装了底层文件API的类。因为文件操作需要一定时间去完成，所以类将异步地处理。这意味着许多操作可以同时进行，所以它们必须相互协调。如果我们调用一个方法创建文件，又调用另外一个方法删除这个文件，那么我们的封装类就必须知悉，并确保它们不会相互干扰。为了实现这点，对封装类的调用必须能够知道之前的每一步操作。如果使用者能够自由地创建这个类的实例，那么一个实例就无法知道其他实例所做的操作。而单例模式，则提供了在编译期就能确保某个类只有一个实例的方法。

        单例模式的类结构图很简单

         它的实现方式就是把构造函数设置为私有，限制我们创建这个对象。然后提供一个对外访问的接口，只允许该类实例化一次，从而保证该实例的唯一性。

它的代码实现也很简单

class Singleton {
    /**核心 - 一个接收实例的静态成员 */
    private static _instance: Singleton;

    /**核心 - 私有构造函数 */
    private constructor() {

    }

    /**核心 - 获取实例 */
    public static getInstance(): Singleton {
        // Lazy initialize.真正需要的时候再去分配内存，节省不必要的内存开销
        if (this._instance == null) {
        this._instance = new Singleton();
        }
        return Singleton._instance;
    }
}

        下面是一个更简洁更现代的版本，也就是饿汉单例模式。它直接对局部静态变量进行赋值，由于静态变量在程序运行前就已经分配好内存，所以它的初始化只会进行一次，这样的实现可以保证线程安全。

class Singleton {
    /**核心 - 一个接收实例的静态成员 */
    private static _instance: Singleton = new Singleton();;

    /**核心 - 私有构造函数 */
    private constructor() {

    }

    /**核心 - 获取实例 */
    public static getInstance(): Singleton {
        return Singleton._instance;
    }
}

        我们还可以实现一个单例接口类用来继承。这是一个强大但是经常被忽视的特性。《Game Programming Patterns》一书中有一个关于跨平台文件系统的例子，通过继承一个单例接口类，保证了每一个平台不同的文件系统实现都是单例。

        单例模式很简单，也很常用。在短期内，单例模式相对有益处，但是随着开发周期的推进，项目组不同层次开发人员的滥用，最终会导致导致单例失控， 你定位BUG的过程也会变得复杂。全局变量有的缺点单例也逃不掉，因为它本身就是一个全局状态，唯一不同的就是他被封装到类中而已。

我们都知道全局变量是有害的，它有如下缺点

1.令代码晦涩难懂。

2.全局变量促进了耦合。

3.它对并发不友好。一个全局变量在并发环境下，会导致死锁、条件竞争和其他一些难以修复的线程同步的bug。

为了避免这些缺点，我们可以遵循如下几点：

1.如果一个类并不需要单例模式，那么尽量不对他使用单例模式。

2.将类限制为单一实例，这样我们就需要有一种方法来确保单例不提供全局访问。下面是一种实现方式:

class Singleton {
    private static _instantiated: boolean = false;

    private constructor() {
        assert(!Singleton._instantiated);
        Singleton._instantiated
    }
}

3.我们可以通过参数传递、在基类中获取它、通过其他全局对象访问它、通过服务定位器等这些方式来减少单例的使用。

参考:http://gameprogrammingpatterns.com/singleton.html