1 通用单例写法带来的弊端
我们看到的单例模式通用写法，一般就是饿汉式单例的标准写法。饿汉式单例写法在类加载的时候立即初始化，并且创建单例对象。它绝对线程安全，在线程还没出现之前就实例化了，不可能存在访问安全问题。饿汉式单例还有另外一种写法，代码如下。
//饿汉式静态代码块单例模式 public class HungryStaticSingleton { private static final HungryStaticSingleton instance; static { instance = new HungryStaticSingleton(); } private HungryStaticSingleton(){} public static HungryStaticSingleton getInstance(){ return instance; } }这种写法使用静态代码块的机制，非常简单也容易理解。饿汉式单例模式适用于单例对象较少的情况。这样写可以保证绝对线程安全，执行效率比较高。但是它的缺点也很明显，就是所有对象类在加载的时候就实例化。这样一来，如果系统中有大批量的单例对象存在，而且单例对象的数量也不确定，则系统初始化时会造成大量的内存浪费，从而导致系统内存不可控。也就是说，不管对象用或不用，都占着空间，浪费了内存，有可能占着内存又不使用。那有没有更优的写法呢？我们继续分析。
2 还原线程破坏单例的事故现场为了解决饿汉式单例写法可能带来的内存浪费问题，于是出现了懒汉式单例的写法。懒汉式单例写法的特点是单例对象在被使用时才会初始化。懒汉式单例写法的简单实现LazySimpleSingleton如下。
//懒汉式单例模式在外部需要使用的时候才进行实例化 public class LazySimpleSingletion { //静态块，公共内存区域 private static LazySimpleSingletion instance; private LazySimpleSingletion(){} public static LazySimpleSingletion getInstance(){ if(instance == null){ instance = new LazySimpleSingletion(); } return instance; } }但这样写又带来了一个新的问题，如果在多线程环境下，则会出现线程安全问题。先来模拟一下，编写线程类ExectorThread。
public class ExectorThread implements Runnable{ @Override public void run() { LazySimpleSingleton singleton = LazySimpleSingleton.getInstance(); System.out.println(Thread.currentThread().getName() + ":" + singleton); } }编写客户端测试代码如下。
public class LazySimpleSingletonTest { public static void main(String[] args) { Thread t1 = new Thread(new ExectorThread()); Thread t2 = new Thread(new ExectorThread()); t1.start(); t2.start(); System.out.println("End"); } }我们反复多次运行程序上的代码，发现会有一定概率出现两种不同结果，有可能两个线程获取的对象是一致的，也有可能两个线程获取的对象是不一致的。下图是两个线程获取的对象不一致的运行结果。
下图是两个线程获取的对象一致的结果。
显然，这意味着上面的单例存在线程安全隐患。那么这个结果是怎么产生的呢？我们来分析一下，如下图所示，如果两个线程在同一时间同时进入getInstance()方法，则会同时满足if(null == instance)条件，创建两个对象。如果两个线程都继续往下执行后面的代码，则有可能后执行的线程的结果覆盖先执行的线程的结果。如果打印动作发生在覆盖之前，则最终得到的结果就是一致的；如果打印动作发生在覆盖之后，则得到两个不一样的结果。
当然，也有可能没有发生并发，完全正常运行。下面通过调试方式来更深刻地理解一下。这里教大家一种新技能，用线程模式调试，手动控制线程的执行顺序来跟踪内存的变化。先把ExectorThread类打上断点，如下图所示。
单击右键点击断点，切换为Thread模式，如下图所示。
然后把LazySimpleSingleton类也打上断点，同样标记为Thread模式，如下图所示。