（一）单例模式详解

            作者：zuoxiaolong8810（左潇龙），转载请注明出处。

            上一章，我们学习了设计模式的概念，以及为什么要学习设计模式，还有在进行系统设计时应当遵守的六大原则，本章我们就来开始一一的学习GOF当中的二十三钟设计模式。

            我一直在思考如何去诠释这么多设计模式，因为网上有很多现成的，可供学习的资料，我在想有什么地方可以让各位跟着我的节奏去学习，而不是网上的那些资料，优势在哪里，思考很久，我觉得唯一的优势，或者说我能有的优势，就是简单通俗易懂。

            遵循着中心思想通俗易懂，我们首先来回顾一下单例模式为何要出现，又或者说什么样的类可以做成单例的。

            在我的工作过程中，我发现所有可以使用单例模式的类都有一个共性，那就是这个类没有自己的状态，换句话说，这些类无论你实例化多少个，其实都是一样的，而且更重要的一点是，这个类如果有两个或者两个以上的实例的话，我的程序竟然会产生程序错误或者与现实相违背的逻辑错误。

            这样的话，如果我们不将这个类控制成单例的结构，应用中就会存在很多一模一样的类实例，这会非常浪费系统的内存资源，而且容易导致错误甚至一定会产生错误，所以我们单例模式所期待的目标或者说使用它的目的，是为了尽可能的节约内存空间，减少无谓的GC消耗，并且使应用可以正常运作。

            我稍微总结一下，一般一个类能否做成单例，最容易区别的地方就在于，这些类，在应用中如果有两个或者两个以上的实例会引起错误，又或者我换句话说，就是这些类，在整个应用中，同一时刻，有且只能有一种状态。

            一般实践当中，有很多应用级别的资源会被做成单例，比如配置文件信息，逻辑上来讲，整个应用有且只能在同在时间有一个，当然如果你有多个，这可能并不会引起程序级别错误，这里指的错误特指异常或者ERROR。但是当我们试图改变配置文件的时候，问题就出来了。

            你有两种选择，第一种，将所有的实例全部更新成一模一样的状态。第二种，就是等着出现问题。

            然而出现的问题大部分是逻辑层次上的错误，个人觉得这是比程序错误更加严重的错误，因为它不会告诉你空指针，不会告诉你非法参数，很多时候要等到影响到客户使用时才会被发现。

            下面，我们就来看一下做成单例的几种方式。

            第一种方式，我们来看一下最标准也是最原始的单例模式的构造方式。

public class Singleton {

	//一个静态的实例
	private static Singleton singleton;
	//私有化构造函数
	private Singleton(){}
	//给出一个公共的静态方法返回一个单一实例
	public static Singleton getInstance(){
		if (singleton == null) {
			singleton = new Singleton();
		}
		return singleton;
	}
}

            这是在不考虑并发访问的情况下标准的单例模式的构造方式，这种方式通过几个地方来限制了我们取到的实例是唯一的。

            1.静态实例，带有static关键字的属性在每一个类中都是唯一的。

            2.限制客户端随意创造实例，即私