Java中单例模式的定义：“一个类有且仅有一个实例，并且自行实例化向整个系统提供。”
单例模式基本实现思路：
（1）构造器私有化，防止外界通过调用构造方法实例化对象，即 private方法。
（2）提供一个公有的静态方法，只有通过该类提供的静态方法才能得到该类的唯一实例，即 static方法。
单例的几种写法：
1.饿汉式（线程安全）【推荐】
优点：
这种写法比较简单，就是在类装载的时候就完成实例化。避免了线程同步问题。
缺点：
在类装载的时候就完成实例化，没有达到懒加载（延时加载）的效果。如果从始至终从未使用过这个实例，则会造成内存的浪费。
2、懒汉式（线程不安全）【不推荐】
优点：
这种实现方法与上一种实现比较，起到了懒加载（延时加载）的效果，
缺点：
存在局限性：这种实现只能在单线程的环境下使用。如果在多线程下，一个线程进入了if (singleton == null)判断语句块，还未来得及往下执行，另一个线程也通过了这个判断语句，这时便会产生多个实例。所以在多线程环境下不可使用这种方式，也不推荐大家使用。
3.懒汉式2.0（线程安全，同步方法）【不推荐】
优点：
为解决上一种实现方案线程不安全的问题，解决方案就是做个线程同步就可以了，于是就对getInstance()方法进行了线程同步，即对getInstance()方法加同步锁，这就保证了单例的唯一性。
缺点：
效率太低了，每个线程在想获得类的实例时候，执行getInstance()方法都要进行同步。
4、双重校验锁【不推荐】
优点：
Double-Check概念对于多线程开发者来说并不陌生，如代码中所示，我们进行了两次if (singleton == null)检查，这样就可以保证线程安全了。这样，实例化代码只用执行一次，后面再次访问时，判断if (singleton == null)，直接return实例化对象。这样即保证了线程的安全性，也大大提高了效率，还实现了懒加载的效果。
就这样，我们用一种很聪明的方式实现了单例模式。到此，一切看上去很完美。
5、双重校验锁（改进）【推荐】
在了解这个实现方式之前，必须提一下：volatile关键字，长篇大论的概念不在叙述，这里主要讲解volatile的两个特性：有序性+可见性。
在编译原理中有一个很重要的内容——编译器优化。所谓编译器优化是指，在不改变原来语义的情况下，通过调整语句顺序，来让程序运行的更快。
举个例子：创建变量需要哪些步骤呢？
1：申请一块内存，
2：调用构造方法进行初始化，
3：分配一个指针指向这块内存。
这些操作是否存在先后顺序呢？在JVM中其实并没有规定。那么我们是否可以这样假设：JVM是先开辟出一块内存，然后把指针指向这块内存，最后调用构造方法进行初始化。
那么这样的话，对于上面的实现方式：可能存在这样的情况：
线程A进入方法判断singleton == null，进入synchronized (Singleton.class) {}代码块，这时线程还没来得及进行第二次判断，时间片用完了，线程B得到CPU执行权限，它进入方法，进行判断，然后进入代码块，再次进行判断，确实为NULL(因为线程A 没有来得及进行new，时间片时间都到了)，那他进行new，new的过程可能存在下面的情况：
由于存在编译器优化的情况，我们想的是创建变量的步骤是 1-->2-->3,但是由于存在编译器优化啊，所以编译器编译的时候，可能出现的代码执行顺序是1-->3,还没来得及进行进行第二步(进行初始化)，线程B可能时间片用完，线程A又进来了，接着上次的顺序继续向下执行，进行第二次判断，发现singleton 不为null了，所以就返回(返回的是线程B new出来的实例，这个实例是没有进行初始化的，只不过是一个singleton指针指向这块内存区域而已)。
问题出现了，尽管singleton不为null，但它并没有构造完成。此时，如果B在A将singleton构造完成之前就是用了这个实例，程序就会出现对象未初始化错误了！
具体来说就是synchronized虽然保证了原子性，但却没有保证指令重排序的正确性。换句话说，我们的线程虽然可以保证原子性，但程序可能是在多核CPU上执行，从而可能导致这种情况的发生。
在JDK 1.5之后，Java使用了新的内存模型。volatile关键字有了明确的语义（在JDK1.5之前，volatile是个关键字，但是并没有明确的规定其用途），被volatile修饰的写变量不能和之前的读写代码调整，读变量不能和之后的读写代码调整！(学习java happen-before原则 / 内存模型)。因此，只要我们简单的把singleton加上volatile关键字就可以了，这样就完美解决问题了
6、静态内部类/登记式【推荐】
上面我们提到了volatile是在JDK 1.5之后定义的，然而在此之前又是如何实现的呢？其实就是接下来我们所要说的一种解决方案——静态内部类，这种方案并不会受JDK版本的影响。
静态内部类方式在Singleton类被装载时并不会立即实例化，而是在需要实例化时，调用getInstance方法，才会装载SingletonHolder类，从而完成Singleton的实例化。
类的静态属性只会在第一次加载类的时候初始化，所以在这里，JVM帮助我们保证了线程的安全性，在类进行初始化时，别的线程是无法进入的。这一技术是被JVM明确说明了的，因此不存在任何二义性。
7、枚举法【推荐】
public enum Singleton
{ INSTANCE; }
enum类也不能够被继承，在反编译中，我们会发现该类是final的。
enum有且仅有private的构造器，防止外部的额外构造，这恰好和单例模式吻合。
枚举单例进行但编译出来的结果是：
Class SingleTon extends enum{
Public static final SingleTon singleTon;
}
8.可以避免通过反射和反序列化来创建多个对象。线程安全。
问：Java 枚举是如何保证线程安全的？
答：因为 Java 类加载与初始化是 JVM 保证线程安全，而 Java enum 枚举在编译器编译后的字节码实质是一个 final 类，每个枚举类型是这个 final 类中的一个静态常量属性，其属性初始化是在该 final 类的 static 块中进行，而 static 的常量属性和代码块都是在类加载时初始化完成的，所以自然就是 JVM 保证了并发安全。
问：为什么有人说在一些场景下通过枚举实现的单例是最好的方式，原因是什么？
答：其实这个题目算是一箭双雕，既考察了 Java 枚举的实质特性又考察了单例模式的一些弊端问题。除过枚举实现的单例模式以外的其他实现方式都有一个比较大的问题是一旦实现了 Serializable 接口后就不再是单例了，因为每次调用 readObject() 方法返回的都是一个新创建出来的对象（当然可以通过使用 readResolve() 方法来避免，但是终归麻烦），而 Java 规范中保证了每一个枚举类型及其定义的枚举变量在 JVM 中都是唯一的，在枚举类型的序列化和反序列化上 Java 做了特殊处理，序列化时 Java 仅仅是将枚举对象的 name 属性输出到结果中，反序列化时则是通过 java.lang.Enum 的 valueOf 方法来根据名字查找枚举对象，同时禁用了 writeObject、readObject、readObjectNoData、writeReplace 和 readResolve 等方法。
9.单例模式的应用
1.中国只能有由中国共产党领导。(哈哈，开个玩笑)
2. Windows的Task Manager（任务管理器）就是很典型的单例模式（这个很熟悉吧），你可以想想，我们能打开两个任务管理器吗？不信你可以去试试。
3. windows的回收站也是典型的单例应用。在整个系统运行过程中，回收站一直维护着仅有的一个实例
4. 数据库连接池的设计一般也是采用单例模式，因为数据库连接是一种数据库资源。数据库软件系统中使用数据库连接池，主要是节省打开或者关闭数据库连接所引起的效率损耗，这种效率上的损耗还是非常昂贵的，因为何用单例模式来维护，就可以大大降低这种损耗。
5.多线程的线程池的设计一般也是采用单例模式，这是由于线程池要方便对池中的线程进行控制。
6. Web应用的配置对象的读取，一般也应用单例模式，这个是由于配置文件是共享的资源。
7.操作系统的文件系统，也是大的单例模式实现的具体例子，一个操作系统只能有一个文件系统。
