单例模式(Singleton Pattern)
- 单例模式概述
定义：确保一个类只有一个实例，并提供一个全局访问点来访问这个实例
简单的说，就是你有且只有一个女朋友(有多个女朋友的模式不是这里~~)，并且你的女朋友很特殊，从来只听你的话，所以别人想和她交流(访问她)就必须通过你(全局访问点)来和她交流。
系统中用到单例模式的地方很多，比如windows系统点击开始只能出现一个开始界面，ctrl+alt+. 只能出现一个资源管理器，每个进程有且对应唯一一个进程id等等。单例模式是为了让资源得到最大化利用，不浪费资源。同时假如不采用此模式，就可能在不同时刻打开同一个界面，但界面中的内容又各不相同，因而用户极易产生误解，影响使用效率。因此单例模式在系统中的应用非常重要。
要点：a.某一个单例类只能有一个实例；
b.必须自行创建这个实例；
c.必须向系统提供这个实例;
- 单例模式的结构与实现
结构：
-
我们考虑一个问题，每一个类都会有它的默认构造函数，或者我们重写一个构造函数，这个函数都是在创建这个类的实例的时候自动调用的。即对对象进行初始化操作。所以我们每次new的时候都会有一个新的对象，当然这是不符合单例模式的要求的。因此为了满足单例模式的要求，就必须对类中的函数进行修改，怎么修改呢，一步一步来(个人觉得这个理解还是挺重要的)。
- 首先，我们类的实例化不能在外部进行(单例类自行提供这个实例)，即不能每次new都调用构造函数，因此将构造函数设为private类型
- 既然构造函数是private的，那怎么样调用呢？？通过公有方法可以调用private函数，返回实例
- 看到这里，或许有人就有疑问了，公有方法(public ... ....)是在类的对象生成后才可以调用的，但是对象的创建又必须通过构造函数，而这里构造函数又必须通过公有方法调用，不就形成了一个鸡生蛋，蛋孵鸡的问题了吗？？好了，谁先谁后，我们先辩论下吧.....其实，静态方法的使用，能很好的解决这个问题，将公有方法(函数)设为静态方法，我们就能通过类名.方法名去调用它，继而调用私有构造函数，产生对象。
- 再有，单例模式创建的女朋友只能是一个，那又怎么确定呢？怎么确定你的女朋友是唯一的而且你没有偷换呢？(~~皮一下)，我们就要为这个单例类添加一个变量了，用来确认是否唯一，由于创建的整个入口是静态公有方法，所以在那时就要判断是否唯一了，如果该单例类有了一个女朋友，判断后便不再创建，如果当前没有，则分配一个。而可以直接访问类的静态数据和函数成员，而访问非静态成员，必须通过对象名，这有陷入鸡和蛋的问题里了，所以，该变量设为静态变量就很方便了，它也满足为整个类服务的特性。
- 总结下步骤 ：(1)私有构造函数；(2)公有方法调用私有函数；(3)设为静态方法；(4)添加静态变量;(5)根据变量数判断是否生成女朋友(唯一的对象)；
- 上图中：↓↓↓↓↓
- singleton(单例)，在单例类的内部创建它的唯一实例
- getinstance(静态方法)，通过它产生唯一实例
- instance(静态变量)，判断是否可以产生实例
实现:
1 using system;
2 using system.collections.generic;
3 using system.linq;
4 using system.text;
5
6 namespace singleton
7 {
8 class singleton
9 {
10 private static singleton instance = null;//静态私有成员变量
11
12 //私有构造函数
13 private singleton()
14 {
15 console.writeline("恭喜你，获得一个女朋友~~");
16 }
17
18 //静态公有方法，返回实例
19 public static singleton getinstance()
20 {
21 if(instance == null)//没女朋友
22 instance = new singleton();//生成一个吧
23 return instance;//有就返回当前的，
24 }
25 }
26 class program
27 {
28 static void main(string[] args)
29 {
30 singleton s1 = singleton.getinstance();
31 singleton s2 = singleton.getinstance();
32 if (s1 == s2)
33 {
34 console.writeline("怎么能想要共有一个女朋友呢？s2 赶紧换一个吧...");
35 }
36 }
37 }
38 }
结果：
- 饿汉式单例和懒汉式单例
刚看到这两个单例的名字时还是有点好笑的，如此这么生动形象呢，就好像饿汉式单身(连温饱都满足不了，何来女朋友呢)，懒汉式(好吃懒做的，也很难...)不乱扯了，回主题。饿汉式单例正如饿汉一样，很饿很饿的人最想要的就是立即马上吃东西。因此饿汉式单例在定义静态变量时就实例化了单例类，因为实在太饿了啊，等不及了。
1 class eagetsingleton
2 {
3 private static eagetsingleton instance = new eagetsingleton();//静态变量实例化单例类
4
5 private eagetsingleton(){}
6
7 public static eagetsingleton getinstance()
8 {
9 return instance;
10 }
11 }
懒汉式单例类则是在类第一次被引用时将自己实例化，单例类被加载时不会实例化，所以这很符合懒汉的气质~但是在这里要注意的是，在定义静态变量时没有实例化单例类，而是在第一次调用静态方法时实例化单例类，这就会产生问题，高并发，多线程实现懒汉式单例时会创建多个对象，从而违背了单例模式的设计意图。也就是还是要对女朋友的个数进行判断。这要怎么办呢？在多线程的情况下，就要对该代码段进行控制，即每次只让一个线程进入并创建实例，也就是相当于现在的“共享女友”，帮你拍照啊，陪你去看电影啊 ，巴拉巴拉。但是，该“共享女友”有且只有一个，即单例类的唯一实例。所以，土豪们(各个线程)得一个一个租用，上一个用完了下一个才能租用。因此代码如下：
1 class lazytsingleton
2 {
3 private static lazytsingleton instance = null;
4 private static readonly object synroot = new object();//看做一个门。
5 //程序运行时创建只读辅助对象
6
7 private lazytsingleton(){}
8
9 public static lazytsingleton getinstance()
10 {
11 if(instance == null)//在房间外问：房间里有人吗 ？ 没人回应 ，可能没，可能下一秒有人进去 ，我却以为没人
12 {
13 lock(synroot)//第二次判断 //把门关了，外面线程进不来，只能里面的出来，外面的才能进
14 {
15 if(instance == null)//继续问，房间里有人吗？ 有就真的有，没有就真的没
16 {
17 instance = new lazytsingleton();//创建实例
18 }
19 }
20 }
21 }
22 }
二者比较：
- 饿汉式单例
优点：无需考虑多线程同时访问的问题，确保实例唯一性。调用速度和反应时间快于懒汉模式，因为饿汉一开始就创建，后面则直接拿来用就可以了。
缺点：不管单例对象是否需要，都会在类加载时创建，这样不如懒汉式单例，资源利用不高，且加载时间较长。如启动vs，eclipse等，需要loading许多可能要的可能不要的，要等啊...
- 懒汉式单例
优点：第一次使用时创建，不会一直占用资源，即延迟加载。
缺点：必须考虑多线程问题，特别是单例类作为资源控制器时，会涉及资源初始化，也会耗费许多时间，也会出现多线程同时首次引用此类，造成拥堵，导致系能性能降低
- 单例模式的优缺点和适用环境
- 单例模式的优点
- 提供唯一实例的受控访问，可以严格控制何时访问
- 由于只存在一个对象，可以节省系统资源
- 如果将单例模式的实例数目变为可变，即将单例模式进行扩展，即可获得指定数目的实例对象，即节省资源，又提高效率(相当于多例类)
- 单例模式的缺点
- 没有抽象层，扩展有较大困难
- 单例类职责过重，一定程度上违背了单一职责原则(单例类即提供业务方法，又提供了创建对象的方法(工厂方法)，对象创建和对象本身耦合在了一起)
- c#、java 拥有gc(自动垃圾回收机制) (可以去了解下) ，在实例化的对象长时间不被利用，会被误认为垃圾进行自动销毁，下次利用又要重新创建，导致共享的单例对象丢失(女朋友丢了可不好受啊..)
- 单例模式的适用环境
- 在系统只要一个实例对象(man只要一个girlfriend)/(资源管理器).....
- 客户调用类的单个实例只允许使用一个公共访问点，除了该点外，不允许其他途径来访问实例