看了多方资料，整理下单例设计模式，有不少值得相互探究的地方，你就会发现就这一个小小的单例模式竟然映射出N多知识。我在这里把问题综述出来，一起相互探讨。
单例涉及到的相关文章如下：
反射、枚举与单例
序列化与单例
类加载器与单例
本文则主要是讲多线程与单例。
单例模式首先分为懒汉式和饿汉式。所谓饿汉式即一开始就创建出单例对象，懒汉式则为当需要使用的时候才会去创建出单例对象。
先看下饿汉式：
|
1 2 3 4 5 6 7 8 9 10 |
|
1 私有化构造器，使得别人无法再创建新对象。
问题1：即使私有化构造器，别人仍然可以通过反射机制来创建新对象，要是这样的话，下面的很多单例方法都不再是单例。然而枚举除外。
2 这种饿汉式的方式在类加载器加载Singleton的时候就会去初始化创建一个Singleton实例，类加载器加载Singleton时线程安全的，所以这种方式不存在线程安全问题。
懒汉式：有时候为了在使用的时候才去创建单例对象，就要采用懒汉式
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
这种方式即在需要的时候才会去创建单例对象。很明显，大家都知道这种方式引入了线程安全问题，所以要对getInstance方法加上锁，如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
这样的话，每个线程要执行getInstance方法时，synchronized对他们进行了同步，保证并发情况下只有一个线程在执行getInstance方法。这种做法的的确解决了线程安全问题，但是却造成了很大的性能开销。因为instance只需要在第一次创建时进行同步，创建后每次获取时不需要再进行同步，所以我们要进一步改进：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
这种方式即缩小了同步的范围，保证了在单例对象创建出来后，每次获取时不需要再进行同步，但是又造成了一个问题，即不能保证instance=new Singleton()只被执行一次，所以又要改进，需要在同步的代码中再次检查是否已经创建，如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
这就是所谓的双重检查机制。看似已经完美，实则不然。instance=new Singleton()实际上分为三个过程：
1 分配内存
2 对Singleton的一些初始化工作包括构造函数的执行
3 对instance变量赋值内存地址
然而对于第2步和第3步，不同的编译器由于执行了优化导致他们的执行顺序并不一致，即发生了重排序，对于重排序参见这篇infoq上的文章http://www.infoq.com/cn/articles/java-memory-model-2
也就是线程1当执行到第2步的时候，instance就已经有值了，此时线程2执行getInstance方法的最外层的if(instance==null)判断就会直接返回。然而该对象还没有真正的完成初始化，还不能正常使用。此时线程2如果去使用该对象，就会出问题了。
为了解决这个问题，就是不允许第2步和第3步进行重排序，使用volatile来解决，如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
|
只需要在Singleton instance变量上加上volatile修饰，就可以禁止重排序。我们知道synchronized 即保证可见性又保证了互斥性，而volatile则仅仅是保持了可见性，而这里volatile又起到禁止重排序的功能（我也不懂，留给大神们去研究）。
另一种解决方案是，基于类初始化的解决方案：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
|
这也是一种常见的懒汉式单例，接下来我们就要分析分析它是如何解决多线程问题的。
当多个线程执行SingletonHolder.instance时，会首先进行类的初始化，即多个线程可能同时去初始化同一个类，这方面对于jvm来说是进行了细致的同步，每个类都有一个初始化锁，来确保只能有一个线程来初始化类。当线程A获取了SingletonHolder类的初始化锁，线程B则需要等待，线程A就要去执行SingletonHolder的静态变量表达式、静态代码块等初始化工作，然后就能确保Singleton instance=new Singleton()只被一个线程来执行。
总的来说，此种方法是依靠jvm对类和接口的同步来实现单例线程安全的。具体jvm对于类和接口初始化的同步过程可以见这篇文章http://www.infoq.com/cn/articles/double-checked-locking-with-delay-initialization