起因：每个游戏场景中都会有许多的游戏对象，而各个游戏场景之间也是同等的关系。如何去管理它们，是我们要解决的问题。
场景中各脚本间的直接访问，会在各脚本间形成一个巨大而又混乱的网络，这给以后代码的维护带来了极大的困难。为了避免这种因交互访问而带来的过度耦合情况，我们取消掉场景中各脚本间的直接交互，取而代之的是，让所有脚本都只与场景中的一个特定脚本交互。
在刚开始使用这种方法时，自己声明了一个场景中的全局脚本，然后把场景中所有其他需要交互的脚本声明为其成员，一旦脚本间要发生交互，就在脚本中声明一个全局脚本的对象，然后通过这个对象去访问其他的脚本，从而把直接交互变成了间接交互。这样做确实解决了脚本之间直接访问带来的高耦合度问题，但是在每个脚本中都要保存一个全局脚本的对象，这显然有些不太合适，浪费了资源。为了进一步解决这个问题，引入了单例模式的应用。
单例模式的定义是：保证一个类只有一个实例，并且提供一个访问它的全局访问点。单例对象的类必须保证只有一个实例存在。在我们的场景中，全局脚本的对象只会创建一次，保证单例，然后它（全局单例类）提供给各个脚本访问单例对象的方法，并且所有其他脚本的公共数据都会存储在全局单例脚本中。
private static GloSingleton _globalSingleton;
声明全局单例类自身类型的静态私有成员变量，作为单例对象使用。
public static GloSingletonGetSingleton() { …}
提供获取单例对象的类的静态方法。任何对单例对象的访问都要通过该方法来获取。
if (null ==_globalSingleton) {
lock(_globalSingleton) {
if(null == _globalSingleton) {
_globalSingleton=
(GloSingleton)GameObject.FindObjectOfType(typeof(GloSingleton));
}
}
}
单例模式的使用在多线程并发的情况下必须小心谨慎。因为当唯一实例尚未创建时，如果有两个线程同时调用创建方法，那么它们同时没有检测到唯一实例的存在，从而同时各自会创建一个实例，这违背了单例模式中实例唯一的原则。解决这个问题的办法是为指示类是否已经实例化的变量提供一个互斥锁。
如我们的代码所示，在方法内部，首先判断单例对象是否为空，为空的话说明单例对象还没有创建，需要实例化一个。反之直接返回单例对象。在准备首次创建单例对象时，设置了一个互斥锁。目的是为了在多线程并发的情况下也能保证单例。相关内容请参看我转载的另一篇博文《C#中的lock关键字》。互斥锁中的判空检测同样是为了保证单例而设的。如果没有二次的检测，当线程A进入lock代码块中，线程B等待时，刚开始单例对象还没有创建，线程A执行完毕离开lock代码块后，单例对象已被创建完毕，而此时原本等待的线程B会进到lock代码块中，再次创建单例对象，因此单例被破坏。二次检测则避免了这种情况的发生。当线程A从lock中离开时，单例对象已经存在，线程B进入lock，便不会再执行创建单例对象的代码了。
这种实现方式即遵守了单例模式，又不必在每次获取单例对象时进行互斥锁的判断，提高了效率。因为自己对单例模式的理解比较简单，若大家有更好的实现方法，欢迎交流讨论。