概述
单例模式确保一个类只有一个实例，而且自行实例化并向整个系统提供整个实例，这个类称为单例类，它提供全局访问的方法。单例模式是一种对象创建型模式。单例模式有三个要点：一是某个类只能有一个实例；二是它必须自行创建这个实例；三是它必须自行向整个系统提供这个实例。
单例模式结构图中只包含一个单例角色：
Singleton（单例）：在单例类的内部实现只生成一个实例，同时它提供一个静态的getInstance()工厂方法，让客户可以访问它的唯一实例；为了防止在外部对其实例化，将其构造函数设计为私有；在单例类内部定义了一个Singleton类型的静态对象，作为外部共享的唯一实例。
一个简单的单例模式如下：
以上单例无法保证线程安全，当多个线程同时调用时，由于实例尚未创建成功，仍为null，因此new LogManager()会被执行多次，最终导致创建多个实例对象，这违背了单例模式的初衷，也导致系统运行发生错误。为了解决该问题，有以下几种方式：
实现方式
饿汉式单例类
当类被加载时，静态变量logManager就会被初始化，单例类的唯一实例将被创建。无论多个线程调用，都保证了实例的唯一性，确保线程安全。
懒汉式单例类
懒汉式单例在第一次调用getInstance()方法时实例化，在类加载时并不自行实例化，这种技术又称为延迟加载(Lazy Load)技术，即需要的时候再加载实例，为了避免多个线程同时调用getInstance()方法，我们可以使用关键字synchronized，代码如下所示：
问题貌似得以解决，事实并非如此。如果使用以上代码来实现单例，还是会存在单例对象不唯一。原因如下：
假如在某一瞬间线程A和线程B都在调用getInstance()方法，此时instance对象为null值，均能通过instance == null的判断。由于实现了synchronized加锁机制，线程A进入synchronized锁定的代码中执行实例创建代码，线程B处于排队等待状态，必须等待线程A执行完毕后才可以进入synchronized锁定代码。但当A执行完毕时，线程B并不知道实例已经创建，将继续创建新的实例，导致产生多个单例对象，违背单例模式的设计思想，因此需要进行进一步改进，在synchronized中再进行一次(instance == null)判断，这种方式称为双重检查锁定(Double-Check Locking)。使用双重检查锁定实现的懒汉式单例类完整代码如下所示：
需要注意的是，如果使用双重检查锁定来实现懒汉式单例类，需要在静态成员变量instance之前增加修饰符volatile，被volatile修饰的成员变量可以确保多个线程都能够正确处理，且该代码只能在JDK 1.5及以上版本中才能正确执行。由于volatile关键字会屏蔽Java虚拟机所做的一些代码优化，可能会导致系统运行效率降低，因此即使使用双重检查锁定来实现单例模式也不是一种完美的实现方式。
饿汉式单例类与懒汉式单例类比较
饿汉式单例类在类被加载时就将自己实例化，它的优点在于无须考虑多线程访问问题，可以确保实例的唯一性；从调用速度和反应时间角度来讲，由于单例对象一开始就得以创建，因此要优于懒汉式单例。但是无论系统在运行时是否需要使用该单例对象，由于在类加载时该对象就需要创建，因此从资源利用效率角度来讲，饿汉式单例不及懒汉式单例，而且在系统加载时由于需要创建饿汉式单例对象，加载时间可能会比较长。
懒汉式单例类在第一次使用时创建，无须一直占用系统资源，实现了延迟加载，但是必须处理好多个线程同时访问的问题，特别是当单例类作为资源控制器，在实例化时必然涉及资源初始化，而资源初始化很有可能耗费大量时间，这意味着出现多线程同时首次引用此类的机率变得较大，需要通过双重检查锁定等机制进行控制，这将导致系统性能受到一定影响。
有没有一种方法，能够将两种单例的缺点都克服，而将两者的优点合二为一呢？答案是：Yes！下面我们来学习这种更好的被称之为Initialization Demand Holder (IoDH)的技术。在IoDH中，我们在单例类中增加一个静态(static)内部类，在该内部类中创建单例对象，再将该单例对象通过getInstance()方法返回给外部使用，实现代码如下所示：
由于静态单例对象没有作为LogManager的成员变量直接实例化，因此类加载时不会实例化LogManager，第一次调用getInstance()时将加载内部类HolderClass，在该内部类中定义了一个static类型的变量instance，此时会首先初始化这个成员变量，由Java虚拟机来保证其线程安全性，确保该成员变量只能初始化一次。由于getInstance()方法没有任何线程锁定，因此其性能不会造成任何影响。
通过使用IoDH，我们既可以实现延迟加载，又可以保证线程安全，不影响系统性能，不失为一种最好的Java语言单例模式实现方式（其缺点是与编程语言本身的特性相关，很多面向对象语言不支持IoDH）。
单例模式被破坏
克隆、反射和反序列化会对传统的单例模式破坏。
在其他创建型设计模式的学习中，我们已经了解，除了直接通过new和使用工厂来创建对象以外，还可以通过克隆、反射和反序列化等方式来创建对象。但是用这些方式来创建对象时有可能会导致单例对象的不唯一，如何解决这些问题呢？
(1) 为了防止客户端使用克隆方法来创建对象，单例类不能实现Cloneable接口，即不能支持clone()方法。
(2) 由于反射可以获取到类的构造函数，包括私有构造函数，因此反射可以生成新的对象。【如何解决：采用枚举实现】
采用一些传统的实现方法都不能避免客户端通过反射来创建新对象，此时，我们可以通过枚举单例对象的方式来解决该问题。
(3) 在原型模式中，我们可以通过反序列化实现深克隆，反序列化也会生成新的对象。具体来说就是每调用一次readObject()方法，都将会返回一个新建的实例对象，这个新建的实例对象不同于类在初始化时创建的实例对象。
那么，如何防止反序列化创建对象呢？解决方法一是类不能实现Serializable接口，即不允许该类支持序列化，这将导致类的应用受限制（有时候我们还是需要对一个对象进行持久化处理）；解决方法二就是本文将要详细介绍的枚举实现。
简单实现
下面我们分析如何使用枚举Enum来实现单例模式。
Google 首席 Java 架构师、《Effective Java》一书作者、Java集合框架的开创者Joshua Bloch在Effective Java一书中提到：
单元素的枚举类型已经成为实现Singleton的最佳方法。在这种实现方式中，既可以避免多线程同步问题；还可以防止通过反射和反序列化来重新创建新的对象。在很多优秀的开源代码中，我们经常可以看到使用枚举方式来实现的单例类。
下面我们来详细分析如何使用枚举实现单例模式。
枚举是在JDK1.5以及以后版本中增加的一个“语法糖”，它主要用于维护一些实例对象固定的类。例如一年有四个季节，就可以将季节定义为一个枚举类型，然后在其中定义春、夏、秋、冬四个季节的枚举类型的实例对象。 按照Java语言的命名规范，通常，枚举的实例对象全部采用大写字母定义，这一点与Java里面的常量是相同的。
首先我们来看一下最简单的单例模式枚举实现。
因为Java虚拟机会保证枚举对象的唯一性，因此每一个枚举类型和定义的枚举变量在JVM中都是唯一的。
最简单的实现方式如下代码所示：
在main()函数中，我们通过Singleton.INSTANCE获得两个对象s1和s2，然后比较s1是否等于s2，最后输出true，说明s1和s2是同一个对象，所得到的对象具有唯一性。由于单例模式的枚举实现代码比较简单，而且又可以利用枚举的特性来解决线程安全和单一实例的问题，还可以防止反射和反序列化对单例的破坏，因此在很多书和文章中都强烈推荐将该方法作为单例模式的最佳实现方法。
单例模式总结
单例模式作为一种目标明确、结构简单、理解容易的设计模式，在软件开发中使用频率相当高，在很多应用软件和框架中都得以广泛应用。
主要优点
单例模式的主要优点如下：
(1) 单例模式提供了对唯一实例的受控访问。因为单例类封装了它的唯一实例，所以它可以严格控制客户怎样以及何时访问它。
(2) 由于在系统内存中只存在一个对象，因此可以节约系统资源，对于一些需要频繁创建和销毁的对象单例模式无疑可以提高系统的性能。
(3) 允许可变数目的实例。基于单例模式我们可以进行扩展，使用与单例控制相似的方法来获得指定个数的对象实例，既节省系统资源，又解决了单例单例对象共享过多有损性能的问题。
主要缺点
单例模式的主要缺点如下：
(1) 由于单例模式中没有抽象层，因此单例类的扩展有很大的困难。
(2) 单例类的职责过重，在一定程度上违背了“单一职责原则”。因为单例类既充当了工厂角色，提供了工厂方法，同时又充当了产品角色，包含一些业务方法，将产品的创建和产品的本身的功能融合到一起。
(3) 现在很多面向对象语言(如Java、C#)的运行环境都提供了自动垃圾回收的技术，因此，如果实例化的共享对象长时间不被利用，系统会认为它是垃圾，会自动销毁并回收资源，下次利用时又将重新实例化，这将导致共享的单例对象状态的丢失。
适用场景
在以下情况下可以考虑使用单例模式：
(1) 系统只需要一个实例对象，如系统要求提供一个唯一的序列号生成器或资源管理器，或者需要考虑资源消耗太大而只允许创建一个对象。如：ServletContext，ServletConfig，ApplicationContext，DBPool，ThreadPool等。
(2) 客户调用类的单个实例只允许使用一个公共访问点，除了该公共访问点，不能通过其他途径访问该实例。
