探索设计形式-单例模式

探索设计模式--单例模式

关键字：?设计模式?,singleton?,单例

转自：http://www.iteye.com/topic/575052

各种构造模式之间可以互相比较，但是没有优劣好坏之分，只有确定了上下文环境，才能谈应用什么模式学习设计模式我觉得也没有必要去强背一些代码模版，应当去理解每种模式的出现的原因和解决的问题当你发现你的设计需要更大灵活性时，设计便会向着合适的模式演化，这时候你就真正的掌握了设计模式

?

目的：

希望对象只创建一个实例，并且提供一个全局的访问点。

场景：

Kerrigan对于Zerg来说是个至关重要的灵魂人物，无数的Drone、Zergling、Hydralisk……可以被创造、被牺牲，但是Kerrigan得存在关系到Zerg在这局游戏中的生存，而且Kerrigan是不允许被多次创造的，必须有且只有一个虫族刀锋女王的实例存在，这不是游戏规则，但这是个政治问题。

分析：

如前面一样，我们还是尝试使用代码来描述访问Kerrigan的过程，看看下面的UML图，简单得我都不怎么好意思放上来占版面。

?

图6.1?单例模式的UML图

结构是简单的，只是我们还有一些小小的要求如下：

1.最基本要求：每次从getInstance()都能返回一个且唯一的一个Kerrigan对象。

2.稍微高一点的要求：Kerrigan很忙，很多人找，所以希望这个方法能适应多线程并发访问。

3.再提高一点的要求：Zerg是讲究公务员效率的社会，希望找Kerrigan的方法性能尽可能高。

4.最后一点要求是Kerrigan自己提出的：体谅到Kerrigan太累，希望多些睡觉时间，因此Kerrigan希望实现懒加载（Lazy Load），在需要的时候才被构造。

5.原本打算说还提要处理多ClassLoader、多JVM等情况，不过还是不要把情况考虑的太复杂了，暂且先放过作者吧（-_-#）。

?

我们第一次写的单例模式是下面这个样子的：

1. /**?
2. ?*?实现单例访问Kerrigan的第一次尝试?
3. ?*/??
4. public?class?SingletonKerriganA?{??
5. ???
6. ????/**?
7. ?????*?单例对象实例?
8. ?????*/??
9. ????private?static?SingletonKerriganA?instance?=?null;??
10. ???
11. ????public?static?SingletonKerriganA?getInstance()?{??
12. ????????if?(instance?==?null)?{??????????????????????????????//line?A??
13. ????????????instance?=?new?SingletonKerriganA();??????????//line?B??
14. ????????}??
15. ????????return?instance;??
16. ????}??
17. } ?

?

?

这个写法我们把四点需求从上往下检测，发现第二点的时候就出了问题，假设这样的场景：两个线程并发调用SingletonKerriganA.getInstance()，假设线程一先判断完instance是否为null，既代码中的line A进入到line B的位置。刚刚判断完毕后，JVM将CPU资源切换给线程二，由于线程一还没执行line B，所以instance仍然是空的，因此线程二执行了new SignletonKerriganA()操作。片刻之后，线程一被重新唤醒，它执行的仍然是new SignletonKerriganA()操作，好了，问题来了，两个Kerrigan谁是李逵谁是李鬼

紧接着，我们做单例模式的第二次尝试：

1. /**?
2. ?*?实现单例访问Kerrigan的第二次尝试?
3. ?*/??
4. public?class?SingletonKerriganB?{??
5. ???
6. ????/**?
7. ?????*?单例对象实例?
8. ?????*/??
9. ????private?static?SingletonKerriganB?instance?=?null;??
10. ???
11. ????public?synchronized?static?SingletonKerriganB?getInstance()?{??
12. ????????if?(instance?==?null)?{??
13. ????????????instance?=?new?SingletonKerriganB();??
14. ????????}??
15. ????????return?instance;??
16. ????}??
17. } ?

?

?

比起第一段代码仅仅在方法中多了一个synchronized修饰符，现在可以保证不会出线程问题了。但是这里有个很大（至少耗时比例上很大）的性能问题。除了第一次调用时是执行了SingletonKerriganB的构造函数之外，以后的每一次调用都是直接返回instance对象。返回对象这个操作耗时是很小的，绝大部分的耗时都用在synchronized修饰符的同步准备上，因此从性能上说很不划算。

那继续把代码改成下面的样子：

1. /**?
2. ?*?实现单例访问Kerrigan的第三次尝试?
3. ?*/??
4. public?class?SingletonKerriganC?{??
5. ???
6. ????/**?
7. ?????*?单例对象实例?
8. ?????*/??
9. ????private?static?SingletonKerriganC?instance?=?null;??
10. ???
11. ????public?static?SingletonKerriganC?getInstance()?{??
12. ????????synchronized?(SingletonKerriganC.class)?{??
13. ????????????if?(instance?==?null)?{??
14. ????????????????instance?=?new?SingletonKerriganC();??
15. ????????????}??
16. ????????}??
17. ????????return?instance;??
18. ????}??
19. } ?

?

?

基本上，把synchronized移动到代码内部是没有什么意义的，每次调用getInstance()还是要进行同步。同步本身没有问题，但是我们只希望在第一次创建Kerrigan实例的时候进行同步，因此我们有了下面的写法——双重锁定检查（DCL）。

?

1. /**?
2. ?*?实现单例访问Kerrigan的第四次尝试?
3. ?*/??
4. public?class?SingletonKerriganD?{??
5. ???
6. ????/**?
7. ?????*?单例对象实例?
8. ?????*/??
9. ????private?static?SingletonKerriganD?instance?=?null;??
10. ???
11. ????public?color: #7f0055; background-color: inherit; font-weight: b