单例模式

单例模式定义及应用场景

单例模式（Singleton Pattern）是指确保一个一个类在任何情况下都绝对只有一个实例，并提供一个全局访问点。单例模式是创建型模式。单例模式在显示生活中应用也非常广泛，ServletContext，Spring框架应用中，数据库的连接池等也都是单例模式

饿汉式单例模式

饿汉式单例模式在类加载的时候就立即初始化，并且创建单例对象。它绝对线程安全，在线程还没出现以前就实例化了，不可能存在访问安全问题。

接下来看饿汉单例的标准代码：

/**
 * 饿汉单例模式
 * 缺点：所有类都在类加载的时候就初始化好，造成了大量的内存的浪费。这个对象可能用不到
 */
public class HungrySingleton {

    /**
     * JVM加载时就创建好了HungrySingleton对象，这里也可以用静态代码块生成实例
     */
    private static final HungrySingleton HUNGRY_SINGLETON = new HungrySingleton();

    /**
     * 单例必须线程私有化
     */
    private HungrySingleton(){

    }

    /**
     * 返回创建好的实体类
     * @return
     */
    public static HungrySingleton getInstance(){
        return HUNGRY_SINGLETON;
    }
}

还有另外一种写法，就是利用静态代码块的机制：

```java
/**
 * 饿汉单例模式
 * 缺点：所有类都在类加载的时候就初始化好，造成了大量的内存的浪费。这个对象可能用不到
 */
public class HungrySingleton {

    /**
     * JVM加载时就创建好了HungrySingleton对象，这里也可以用静态代码块生成实例
     */
    private static final HungrySingleton HUNGRY_SINGLETON = null;

    /**
     * 单例必须线程私有化
     */
    private HungrySingleton(){
        HUNGRY_SINGLETON = new HungrySingleton();
    }

    /**
     * 返回创建好的实体类
     * @return
     */
    public static HungrySingleton getInstance(){
        return HUNGRY_SINGLETON;
    }
}

这两种写法都非常简单，也非常好理解，饿汉式单例模式适用于单例对象较少的情况。这样写可以保证绝对线程安全，指向效率比较高。但是它的缺点也很明显，就是所有对象类加载的时候就实例化。这样一来，如果系统中有大批量的单例对象存在，那系统初始化是就会导致大量的内存浪费。也就是说，不管对象用与不用都占用空间，浪费了内存，有可能"占着茅坑不拉屎"。那有没有更优的写法呢？

懒汉式单例模式

为了解决饿汉式单例可能带来的内存浪费问题，于是就出现了懒汉式单例的写法，懒汉式单例模式的特点是，单例对象要在被使用时才会初始化，下面看懒汉式单例模式的简单实现

public class LazySimpleSingleton {

    private static LazySimpleSingleton lazy = null;

    /**
     * 构造方法私有化
     */
    private LazySimpleSingleton(){}

    /**
     * 实例化LazySimpleSingleton对象
     * @return
     */
    public static LazySimpleSingleton getInstance(){
        //判断是否是第一次获取对象，如果是就new对象返回，如果不是第一次就直接返回
        if (lazy==null){
            lazy = new LazySimpleSingleton();
        }
        return lazy;
    }
}

但这样写又带来了一个新的问题，如果在多线程环境下，就会出现线程安全问题。我先来模拟一下，编写线程类ExectorThread：

public class ExectorThread implements Runnable{

    @Override
    public void run() {
        LazySimpleSingleton lazySimpleSingleton = LazySimpleSingleton.getInstance();
        System.out.println(Thread.currentThread().getName()+":"+lazySimpleSingleton);
    }
}

客户端测试代码如下：

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.print("End");
    }
}

结果： 但是经过多次试验，会出现不同结果，如下图： 这意味着上面的单例模式存在线程安全隐患。

如何解决这个问题，使得懒汉式单例模式在多线程环境下安全呢？给getInstance()加上synchronized关键字，使这个方法变成线程同步方法：

public class LazySimpleSingleton {

    private static LazySimpleSingleton lazy = null;

    /**
     * 构造方法私有化
     */
    private LazySimpleSingleton(){}

    /**
     * 实例化LazySimpleSingleton对象
     * @return
     */
    public synchronized static LazySimpleSingleton getInstance(){
        //判断是否是第一次获取对象，如果是就new对象返回，如果不是第一次就直接返回
        if (lazy==null){
            lazy = new LazySimpleSingleton();
        }
        return lazy;
    }
}

这时候，我们运行代码

这个时候不管我们怎么运行代码，地址都是不会变的，线程安全的问题解决了。但是，用synchronized加锁时，在线程数量比较多的情况下，如果CPU分配压力上升，则会导致大批线程阻塞，从而导致程序性能大幅下降。那么，有没有一种更好的方式，既能兼顾线程安全又能提升程序性能呢？答案是肯定的。我们来看双重检查锁的单例模式：

public class LazySimpleSingleton {

    private static LazySimpleSingleton lazy = null;

    /**
     * 构造方法私有化
     */
    private LazySimpleSingleton(){}

    /**
     * 实例化LazySimpleSingleton对象
     * @return
     */
    public static LazySimpleSingleton getInstance(){
        //判断是否是第一次获取对象，如果是就new对象返回，如果不是第一次就直接返回
        if (lazy==null){
            synchronized(LazySimpleSingleton.class){
                if (lazy==null){
                    lazy = new LazySimpleSingleton(); 
                }
                
            }
        }
        return lazy;
    }
}

当第一个线程调用getInstance()方法时，第二个线程也可以调用。当第一个线程执行到synchronized时会上锁，第二个线程就会变成MONITOR状态，出现阻塞。此时，阻塞并不是基于整个LazySimpleSingleton类的阻塞，而是在getInstance()方法内部阻塞，只要逻辑不太复杂，对于调用者而言感知不到。

但是，用到synchronized关键字总归要上锁，对程序性能还是存在一定影响的。难道就真的没有更好的方案了么？当然有，我们可以从类初始化的角度来考虑，看下面的代码，采用静态内部类的方式：

public class LazySimpleSingleton {

    private static LazySimpleSingleton lazy = null;

    /**
     * 构造方法私有化
     */
    private LazySimpleSingleton(){}

    /**
     * 实例化LazySimpleSingleton对象
     * @return
     */
    public static LazySimpleSingleton getInstance(){
        //判断是否是第一次获取对象，如果是就new对象返回，如果不是第一次就直接返回
        return LazyHolder.LAZY;
    }

    private static class LazyHolder{
        private static final LazySimpleSingleton LAZY = new LazySimpleSingleton();
    }
}

这种方法兼顾了饿汉式单例模式的内存浪费问题和synchronized的性能问题。内部类一定是要在方法调用之前初始化，巧妙的避免了线程安全问题。由于这种方式比较简单，我们就不带大家一步一步调试了。但是，金无足赤，人无完人，单例模式亦如此。

反射破坏单例

上面介绍的单例模式的构造方法除了加上private关键字，没有做任何处理。如果我们使用反射来调用其构造方法，再调用getInstance()方法，应该有两个不同的实例。现在来看一段测试代码，以LazySimpleSingleton为例：

public class Test {

    public static void main(String[] args) {
        try {
            //在很无聊的情况下，进行破坏
            Class<?> clazz = LazySimpleSingleton.class;

            //通过反射获取私有的构造方法
            Constructor c = clazz.getDeclaredConstructor(null);
            //强制访问
            c.setAccessible(true);

            //暴力初始化
            Object o1 = c.newInstance();

            //调用了两次构造方法，相当于"new"了两次，犯了原则性错误
            Object o2 = c.newInstance();

            System.out.println(o1 == o2);
        }catch (Exception e){
            e.printStackTrace();
        }
    }
}

结果：

显然，创建了两个不同的实例，那怎么办呢？我们来做一次优化。现在，我们在其构造方法中做一些限制，一旦出现多次重复创建，则直接抛出异常。来看优化后的代码：

public class LazySimpleSingleton {

    private static LazySimpleSingleton lazy = null;

    /**
     * 构造方法私有化
     */
    private LazySimpleSingleton(){
        if (LazyHolder.LAZY!=null){
            throw new RuntimeException("不允许创建多个实例");
        }
    }

    /**
     * 实例化LazySimpleSingleton对象
     * @return
     */
    public static LazySimpleSingleton getInstance(){
        //判断是否是第一次获取对象，如果是就new对象返回，如果不是第一次就直接返回
        return LazyHolder.LAZY;
    }

    private static class LazyHolder{
        private static final LazySimpleSingleton LAZY = new LazySimpleSingleton();
    }

结果： 至此，自认为史上最牛的单例模式的实现方式便大功告成。但是，上面看似完美的单例写法还是有可能被破坏。

序列化破坏单例

一个单例对象创建好后，有时候需要将对象序列化然后写入磁盘，下次使用时再从磁盘中读取对象并进行反序列化，将其转化为内存对象。反序列化后的对象会重新分配内存，即重新创建。如果序列化的目标对象为单例对象，就违背了单例模式的初衷，相当于破坏了单例，来看一段代码：

public class SerializableSingleton implements Serializable {

    public final static SerializableSingleton INSTANCE = new SerializableSingleton();


    private SerializableSingleton(){}

    public static SerializableSingleton getInstance(){
        return INSTANCE;
    }
}

编写测试代码：

public class SerializableSingletonTest {

    public static void main(String[] args) {
        SerializableSingleton s1 = null;
        SerializableSingleton s2 = SerializableSingleton.getInstance();

        FileOutputStream fos = null;

        try {
            fos = new FileOutputStream("SerializableSingleton.obj");
            ObjectOutputStream oos = new ObjectOutputStream(fos);
            oos.writeObject(s2);
            oos.flush();
            oos.close();

            FileInputStream fis = new FileInputStream("SerializableSingleton.obj");
            ObjectInputStream ois = new ObjectInputStream(fis);
            s1 = (SerializableSingleton) ois.readObject();
            ois.close();

            System.out.println(s1);
            System.out.println(s2);
            System.out.println(s1 == s2);

        }catch (Exception e){
            e.printStackTrace();
        }
    }
}

从运行结果可以看出，反序列化后的对象和手动创建的对象还是不一致的，实例化两次，违背了设计模式的初衷。那么，我们如何保证在序列化的情况下也能够实现单例模式呢？其实很简单，只需要增加readResolve()方法即可。来看优化后的代码：

public class SerializableSingleton implements Serializable {

    public final static SerializableSingleton INSTANCE = new SerializableSingleton();


    private SerializableSingleton(){}

    public static SerializableSingleton getInstance(){
        return INSTANCE;
    }

    private Object readResolve(){
        return INSTANCE;
    }
}

大家一定会想：这是什么原因呢？为什么要这样写？看上去很神奇的样子，也让人有些费解。不如我们一起来看看JDK的源码实现以了解清楚。我们进行ObjectInputStream类的readObject()方法，代码如下：

public final Object readObject()
        throws IOException, ClassNotFoundException
    {
        if (enableOverride) {
            return readObjectOverride();
        }

        // if nested read, passHandle contains handle of enclosing object
        int outerHandle = passHandle;
        try {
            Object obj = readObject0(false);
            handles.markDependency(outerHandle, passHandle);
            ClassNotFoundException ex = handles.lookupException(passHandle);
            if (ex != null) {
                throw ex;
            }
            if (depth == 0) {
                vlist.doCallbacks();
            }
            return obj;
        } finally {
            passHandle = outerHandle;
            if (closed && depth == 0) {
                clear();
            }
        }
    }

我们发现，在readObject()方法中又调用了重写的readObject0()方法。进入readObject0()方法，代码如下：

private Object readObject0(boolean unshared) throws IOException {
        boolean oldMode = bin.getBlockDataMode();
        if (oldMode) {
            int remain = bin.currentBlockRemaining();
            if (remain > 0) {
                throw new OptionalDataException(remain);
            } else if (defaultDataEnd) {
                /*
                 * Fix for 4360508: stream is currently at the end of a field
                 * value block written via default serialization; since there
                 * is no terminating TC_ENDBLOCKDATA tag, simulate
                 * end-of-custom-data behavior explicitly.
                 */
                throw new OptionalDataException(true);
            }
            bin.setBlockDataMode(false);
        }

        byte tc;
        while ((tc = bin.peekByte()) == TC_RESET) {
            bin.readByte();
            handleReset();
        }

        depth++;
        totalObjectRefs++;
        try {
            switch (tc) {
                case TC_NULL:
                    return readNull();

                case TC_REFERENCE:
                    return readHandle(unshared);

                case TC_CLASS:
                    return readClass(unshared);

                case TC_CLASSDESC:
                case TC_PROXYCLASSDESC:
                    return readClassDesc(unshared);

                case TC_STRING:
                case TC_LONGSTRING:
                    return checkResolve(readString(unshared));

                case TC_ARRAY:
                    return checkResolve(readArray(unshared));

                case TC_ENUM:
                    return checkResolve(readEnum(unshared));

                case TC_OBJECT:
                    return checkResolve(readOrdinaryObject(unshared));

                case TC_EXCEPTION:
                    IOException ex = readFatalException();
                    throw new WriteAbortedException("writing aborted", ex);

                case TC_BLOCKDATA:
                case TC_BLOCKDATALONG:
                    if (oldMode) {
                        bin.setBlockDataMode(true);
                        bin.peek();             // force header read
                        throw new OptionalDataException(
                            bin.currentBlockRemaining());
                    } else {
                        throw new StreamCorruptedException(
                            "unexpected block data");
                    }

                case TC_ENDBLOCKDATA:
                    if (oldMode) {
                        throw new OptionalDataException(true);
                    } else {
                        throw new StreamCorruptedException(
                            "unexpected end of block data");
                    }

                default:
                    throw new StreamCorruptedException(
                        String.format("invalid type code: %02X", tc));
            }
        } finally {
            depth--;
            bin.setBlockDataMode(oldMode);
        }
    }

其中发现，有一段：

case TC_OBJECT:
   return checkResolve(readOrdinaryObject(unshared));

我们看到TC_OBJECT中调用了ObjectInputStream的readOrdinaryObject()方法，看源码：

private Object readOrdinaryObject(boolean unshared)
        throws IOException
    {
        if (bin.readByte() != TC_OBJECT) {
            throw new InternalError();
        }

        ObjectStreamClass desc = readClassDesc(false);
        desc.checkDeserialize();

        Class<?> cl = desc.forClass();
        if (cl == String.class || cl == Class.class
                || cl == ObjectStreamClass.class) {
            throw new InvalidClassException("invalid class descriptor");
        }

        Object obj;
        try {
            obj = desc.isInstantiable() ? desc.newInstance() : null;
        } catch (Exception ex) {
            throw (IOException) new InvalidClassException(
                desc.forClass().getName(),
                "unable to create instance").initCause(ex);
        }

        passHandle = handles.assign(unshared ? unsharedMarker : obj);
        ClassNotFoundException resolveEx = desc.getResolveException();
        if (resolveEx != null) {
            handles.markException(passHandle, resolveEx);
        }

        if (desc.isExternalizable()) {
            readExternalData((Externalizable) obj, desc);
        } else {
            readSerialData(obj, desc);
        }

        handles.finish(passHandle);

        if (obj != null &&
            handles.lookupException(passHandle) == null &&
            desc.hasReadResolveMethod())
        {
            Object rep = desc.invokeReadResolve(obj);
            if (unshared && rep.getClass().isArray()) {
                rep = cloneArray(rep);
            }
            if (rep != obj) {
                // Filter the replacement object
                if (rep != null) {
                    if (rep.getClass().isArray()) {
                        filterCheck(rep.getClass(), Array.getLength(rep));
                    } else {
                        filterCheck(rep.getClass(), -1);
                    }
                }
                handles.setObject(passHandle, obj = rep);
            }
        }

        return obj;
    }

我们发现调用了ObjectStreamClass的isInstantiable()方法，而isInstantiable()方法的代码如下：

boolean isInstantiable() {
        requireInitialized();
        return (cons != null);
    }

上述代码非常简单，就是判断一下构造方法是否为空，构造方法不为空就返回true。这意味着只要有无参构造方法就会实例化。

这个时候其实我们还没有找到readResolve()方法就避免了单例模式被破坏的真正原因。再回到ObjectInputStream的readOrdinaryObject()方法，继续往下看，判断无参构造方法是否存在之后，又调用了hasReadResolveMethod()方法，来看代码：

desc.hasReadResolveMethod())

判断无参数构造方法是否存在之后，又调用了hasReadResolveMethod()方法，来看代码：

boolean hasReadResolveMethod() {
  requireInitialized();
  return (readResolveMethod != null);
}

上述描述逻辑非常简单，就是判断readResolveMethod是否为空，不为空就返回true。那么readResolveMethod是在哪里赋值的呢？通过全局查找知道，在私有方法ObjectStreamClass()中给readResolveMethod进行了赋值，来看代码：

 readResolveMethod = getInheritableMethod(
                        cl, "readResolve", null, Object.class);

上面的逻辑其实就是通过反射找到一个无参的readResolve()方法，并且保存下来。现在回到ObjectInputStream的readOrdinaryObject()方法继续往下看，如果readResolve()方法存在则调用invokeReadResolve()方法，来看代码：

Object invokeReadResolve(Object obj)
        throws IOException, UnsupportedOperationException
    {
        requireInitialized();
        if (readResolveMethod != null) {
            try {
                return readResolveMethod.invoke(obj, (Object[]) null);
            } catch (InvocationTargetException ex) {
                Throwable th = ex.getTargetException();
                if (th instanceof ObjectStreamException) {
                    throw (ObjectStreamException) th;
                } else {
                    throwMiscException(th);
                    throw new InternalError(th);  // never reached
                }
            } catch (IllegalAccessException ex) {
                // should not occur, as access checks have been suppressed
                throw new InternalError(ex);
            }
        } else {
            throw new UnsupportedOperationException();
        }
    }

我们可以看到，在invokeReadResolve()方法中用反射调用了readResolveMethod方法。

通过JDK源码分析我们可以看出，虽然增加readResolve()方法返回实例解决了单例模式被破坏的问题，但是实际上实例化了两次，只不过新创建的对象没有被返回而已。如果创建对象的动作发生频率加快，就意味着内存分配开销也会随之增大，难道真的就没有办法从根本上解决问题么？下面来看一下注册式单例。

注册式单例模式

注册式单例模式又称为登记式单例模式，就是将每一个实例都登记到某一个地方，使用唯一的标识获取实例。注册式单例模式有两种：一种为枚举式单例模式，另一种容器式单例模式。

枚举式单例模式

public enum  EnumSingleton {
    INSTANCE;
    private Object data;

    public Object getData(){
        return data;
    }

    public void setData(Object data){
        this.data = data;
    }

    public static EnumSingleton getInstance(){
        return INSTANCE;
    }
}

测试：

public class EnumSingletonTest {

    public static void main(String[] args) {
        EnumSingleton instance1 = null;
        EnumSingleton instance2 = EnumSingleton.getInstance();
        instance2.setData(new Object());

        FileOutputStream fos = null;

        try {
            fos = new FileOutputStream("EnumSingleton.obj");
            ObjectOutputStream oos = new ObjectOutputStream(fos);
            oos.writeObject(instance2);
            oos.flush();
            oos.close();

            FileInputStream fis = new FileInputStream("EnumSingleton.obj");
            ObjectInputStream ois = new ObjectInputStream(fis);
            instance1 = (EnumSingleton) ois.readObject();
            ois.close();

            System.out.println(instance1.getData());
            System.out.println(instance2.getData());
            System.out.println(instance1.getData() == instance2.getData());

        }catch (Exception e){
            e.printStackTrace();
        }
    }
}

没有做任何处理，我们发现运行结果和预期的一样。那么枚举式单例模式如此神奇，它的神秘之处在哪里体现呢？点个关注收藏，之后会单出一篇文章来讲。

容器式单例

其实枚举式单例，虽然写法优雅，但是也有一些问题。因为它在类加载之时就将所有的对象初始化放在类内存中，这其实和饿汉式并无差别，不适合大量创建单例对象的场景。那么，接下来看注册式单例的另一种写法，容器式单例模式，创建ContainerSingleton类：

public class ContainerSingleton {

    private ContainerSingleton(){}

    private static Map<String , Object> ioc =  new ConcurrentHashMap<>();

    public static Object getBean(String className){
        synchronized (ioc){
            if (!ioc.containsKey(className)){
                Object obj = null;
                try {
                    obj = Class.forName(className).newInstance();
                    ioc.put(className , obj);
                }catch (Exception e){
                    e.printStackTrace();
                }
                return obj;
            }else{
                return ioc.get(className);
            }
        }
    }
}

容器式单例模式适用于大量创建单例对象的场景，便于管理。但它是非线程安全的。