设计模式之单例模式（创建型）

单例模式
单例就是单个例子，一个例子就是指一个对象，单例就是指只创建一种对象，想法设法能够保证程序中只存在这么一个对象，是唯一的，那么这种方式就称为单例模式。

为什么需要单例模式呢？

那是因为我们见过的许多程序都是存在多线程环境的。每个线程之间都是相互独立的，在使用一些公共资源的时候会发生许许多多的问题。

举个例子，有个仓库存放着公司的一些后勤资源（公共资源），这些资源呢，公司的每个人都可以使用。刚开始的时候，大家都各自去仓库中拿自己需要的东西，刚开始去的人少，使用完以后也就重新放回去了，也没出现什么问题。

可是当去仓库取东西的人增多的时候（多线程访问），就出现几个问题（单例产生的背景），

1. 有的人借出去了东西，也没人负责登记，通知，导致后面的人过来借用的时候发现借不了，耽误了事情，就跑去跟领导反应；
2. 或是有好几个人都要用同一个东西，都是需要用的，但是改让谁先使用呢？这就又产生了矛盾，一群人又找领导反应；
3. 还有的人把东西用坏了，也不说一声，悄悄的放回去了，后面人用的时候发现是坏的，耽误了手头的事情，也是很生气，也去找领导告状。

你说领导那么大的官，管的事也挺多的，哪有精力管仓库这些事，那就得想个解决办法，不然天天来找他，还干不干其他事了。
于是，身边的军师就给他出谋划策说，“您可以派一个人去管理仓库（创建单例），让其他人有啥事找他就可以了（职责细分）。遇见什么重大问题，再交由您处理，不是挺好的么？”（这就是单例模式产生的由来，将职责细分，不要把所有的任务都交给领导，增加一个仓库主管，统筹仓库管理）

领导恍然大悟，马上安排了一个心腹，让他去管理仓库，所有人使用东西都必须通过他，所有资源的借出，归还，损坏，丢失，等等他都必须清楚。
这样就多了一个管理者，分担了领导的工作压力，提高协同工作的效率（单例模式的好处）

创建单例模式有好几种方法,还是延续上面的例子，如何指派一位库房主管：

1. 饿汉式： 公司刚成立之初就招聘了一位仓库主管，尽管公司还没有建成仓库，但是先把主管的人选确定下来，等仓库建起来的时候，这个人就可以直接去上任了，其他人使用库房的东西直接找他就可以了。

分析：其实这种方式，职责是清晰了，但是对公司不太好，因为招了人就的发工资，前期这个主管有名无实，没干活，还白拿工资，公司多了一份额外开支。

2. 懒汉式：公司刚成立之初，仓库还没有建成，那仓库主管的人选就暂且搁置，等建好了再招聘人去，仓库建好以后，人们需要使用仓库的资源了，但是找谁呢？没有仓库主管，只能是找领导，每个人都跑去问领导仓库主管是谁？第一个问的人，领导发现没有仓库主管，就招聘了一个人去，但是后面再来问的，领导得跟每个人都得重复一遍“已经派了仓库主管了”， 来一个人问就得回答一次，问的多了烦也被烦死了，而且也间接降低了整个公司的工作效率。

分析：虽说前期不用指派仓库主管，公司省了一笔钱，但是大家都不知道是不是分配了仓库主管，所以都需要来向领导询问，占用了领导的时间，降低了大家的工作效率。

3. 双重校验模式：经过懒汉式的事件，领导发布了一则通告，『所有人必须先去找仓库主管，如果没有仓库主管，再来找我，不要动不动就跑到我跟前来，而且来的人，要通知后面的人要等着安排仓库主管，有一人来就行，别一堆人都来』。

分析：这种方式就解决了前面两种模式出现的问题，公司既不会多掏工资，领导又不会被过多的打扰，nice。

4. 静态内部类: 经过这么多变革，领导也学精了，我心里先由一个人选，但是不对外声张，等需要仓库主管的时候，直接任命。

分析：这就属于老板心里想什么，员工永远不清楚，提前任命了还得给发工资了，所以老板心里都已经准备好人选了，等需要的时候再任命，如果一直不需要，那就一直留在老板的心里，只要不从嘴里说出来，一切都是未知数。

这个属于我个人的理解，其实单例模式还有许多更深层次的思考，等写完这些普及性的文章后，可能会针对每种模式再做精细化的分析。

如果，大家觉得的文章对自己有帮助的话，可以关注一下我的公众号，有啥好的不好的话，都可以在公众号里面留言，交个朋友。