设计模式之单例模式

应用场景

一般一个类能否做成单例，最容易区别的地方就在于，这些类，在应用中如果有两个或者两个以上的实例会引起错误，又或者我换句话说，就是这些类，在整个应用中，同一时刻，有且只能有一种状态。
一般实践当中，有很多应用级别的资源会被做成单例，比如配置文件信息，逻辑上来讲，整个应用有且只能在同在时间有一个，当然如果你有多个，这可能并不会引起程序级别错误，这里指的错误特指异常或者ERROR。但是当我们试图改变配置文件的时候，问题就出来了。
你有两种选择，第一种，将所有的实例全部更新成一模一样的状态。第二种，就是等着出现问题。然而出现的问题大部分是逻辑层次上的错误，个人觉得这是比程序错误更加严重的错误，因为它不会告诉你空指针，不会告诉你非法参数，很多时候要等到影响到客户使用时才会被发现。

最原始的单例模式

public class Singleton {  
  
    //一个静态的实例  
    private static Singleton singleton;  
    //私有化构造函数  
    private Singleton(){}  
    //给出一个公共的静态方法返回一个单一实例  
    public static Singleton getInstance(){  
        if (singleton == null) {  
            singleton = new Singleton();  
        }  
        return singleton;  
    }  
}

这是在不考虑并发访问的情况下标准的单例模式的构造方式，这种方式通过几个地方来限制了我们取到的实例时唯一的。
1、静态实例，带有static关键字的属性在每一个类中都是唯一的。
2、限制客户端随意创造实例，即私有化构造方法，此为保证单例的最重要的一步。
3、给一个公共的获取实例的静态方法，注意，是静态方法，因为这个方法是在我们未获取到实例的时候就要提供给客户端调用的，所以如果是非静态的话，那就变成了一个矛盾体了，因为非静态的方法必须要拥有实例才可以调用。
4、判断只有持有的静态实例为null时才调用构造方法创造一个实例，否则就直接返回。
那么这样的单例设计模式是否就已经满足所有的情况了呢？
大家都知道并发情况，那么当同时有多个线程都去创建这个实例，是否会出现这样的问题呢？答案肯定是会的。
我来用代码说明

import java.util.Collections;  
import java.util.HashSet;  
import java.util.Set;  
import java.util.concurrent.ExecutorService;  
import java.util.concurrent.Executors;  
  
public class TestSingleton {  
      
    boolean lock ;  
      
    public boolean isLock() {  
        return lock;  
    }  
  
    public void setLock(boolean lock) {  
        this.lock = lock;  
    }  
      
    public static void main(String[] args) throws InterruptedException {  
        final Set<String> instanceSet = Collections.synchronizedSet(new HashSet<String>());  
        final TestSingleton lock = new TestSingleton();  
        lock.setLock(true);  
        ExecutorService executorService = Executors.newCachedThreadPool();  
        for (int i = 0; i < 100; i++) {  
            executorService.execute(new Runnable() {  
                  
                public void run() {  
                    while (true) {  
                        if (!lock.isLock()) {  
                            Singleton singleton = Singleton.getInstance();  
                            instanceSet.add(singleton.toString());  
                            break;  
                        }  
                    }  
                }  
            });  
        }  
        Thread.sleep(5000);  
        lock.setLock(false);  
        Thread.sleep(5000);  
        System.out.println("------并发情况下我们取到的实例------");  
        for (String instance : instanceSet) {  
            System.out.println(instance);  
        }  
        executorService.shutdown();  
    }  
}

我在程序中同时开启了100个线程，去访问getInstance方法，并且把获得实例的toString方法获得的实例字符串装入一个同步的set集合，set集合会自动去重，所以看结果如果输出了两个或者两个以上的实例字符串，就说明我们在并发访问的过程中产生了多个实例。
程序当中让main线程睡眠了两次，第一次是为了给足够的时间让100个线程全部开启，第二个是将锁打开以后，保证所有的线程都已经调用了getInstance方法。
为什么我们可以创建多个实例？
造成这种情况的原因是因为，当并发访问的时候，第一个调用getInstance方法的线程A，在判断完singleton是null的时候，线程A就进入了if块准备创造实例，但是同时另外一个线程B在线程A还未创造出实例之前，就又进行了singleton是否为null的判断，这时singleton依然为null，所以线程B也会进入if块去创造实例，这时问题就出来了，有两个线程都进入了if块去创造实例，结果就造成单例模式并非单例。

提高单例模式

为了避免这种情况，我们就要考虑并发的情况了，我们最容易想到的方式应该是下面这样的方式，直接将整个方法同步。

 public class BadSynchronizedSingleton {  
  
    //一个静态的实例  
    private static BadSynchronizedSingleton synchronizedSingleton;  
    //私有化构造函数  
    private BadSynchronizedSingleton(){}  
    //给出一个公共的静态方法返回一个单一实例  
    public synchronized static BadSynchronizedSingleton getInstance(){  
        if (synchronizedSingleton == null) {  
            synchronizedSingleton = new BadSynchronizedSingleton();  
        }  
        return synchronizedSingleton;  
    }  
      
}

上面的做法很简单，就是将整个获取实例的方法同步，这样在一个线程访问这个方法时，其它所有的线程都要处于挂起等待状态，倒是避免了刚才同步访问创造出多个实例的危险，但是我只想说，这样的设计实在是糟糕透了，这样会造成很多无谓的等待.
其实我们同步的地方只是需要发生在单例的实例还未创建的时候，在实例创建以后，获取实例的方法就没必要再进行同步控制了.

public class SynchronizedSingleton {  
  
    //一个静态的实例  
    private static SynchronizedSingleton synchronizedSingleton;  
    //私有化构造函数  
    private SynchronizedSingleton(){}  
    //给出一个公共的静态方法返回一个单一实例  
    public static SynchronizedSingleton getInstance(){  
        if (synchronizedSingleton == null) {  
            synchronized (SynchronizedSingleton.class) {  
                if (synchronizedSingleton == null) {  
                    synchronizedSingleton = new SynchronizedSingleton();  
                }  
            }  
        }  
        return synchronizedSingleton;  
    }  
}

二次判断synchronizedSingleton是否为null
假设我们去掉同步块中的是否为null的判断，有这样一种情况，假设A线程和B线程都在同步块外面判断了synchronizedSingleton为null，结果A线程首先获得了线程锁，进入了同步块，然后A线程会创造一个实例，此时synchronizedSingleton已经被赋予了实例，A线程退出同步块，直接返回了第一个创造的实例，此时B线程获得线程锁，也进入同步块，此时A线程其实已经创造好了实例，B线程正常情况应该直接返回的，但是因为同步块里没有判断是否为null，直接就是一条创建实例的语句，所以B线程也会创造一个实例返回，此时就造成创造了多个实例的情况。
如果我们深入到JVM中去探索上面这段代码，它就有可能（注意，只是有可能）是有问题的。
因为虚拟机在执行创建实例的这一步操作的时候，其实是分了好几步去进行的，也就是说创建一个新的对象并非是原子性操作。
创建新的对象分三步:

分配内存
初始化构造器

将对象指向分配的内存的地址
这种顺序在上述双重加锁的方式是没有问题的，因为这种情况下JVM是完成了整个对象的构造才将内存的地址交给了对象。但是如果2和3步骤是相反的（2和3可能是相反的是因为JVM会针对字节码进行调优，而其中的一项调优便是调整指令的执行顺序），就会出现问题了。
因为这时将会先将内存地址赋给对象，针对上述的双重加锁，就是说先将分配好的内存地址指给synchronizedSingleton，然后再进行初始化构造器，这时候后面的线程去请求getInstance方法时，会认为synchronizedSingleton对象已经实例化了，直接返回一个引用。如果在初始化构造器之前，这个线程使用了synchronizedSingleton，就会产生莫名的错误。

单例模式再进阶

标准的单例模式

 package com.oneinstance;  
  
public class Singleton {  
      
    private Singleton(){}  
      
    public static Singleton getInstance(){  
        return SingletonInstance.instance;  
    }  
      
    private static class SingletonInstance{  
          
        static Singleton instance = new Singleton();  
          
    }  
}

首先来说一下，这种方式为何会避免了上面莫名的错误，主要是因为一个类的静态属性只会在第一次加载类时初始化，这是JVM帮我们保证的，所以我们无需担心并发访问的问题。所以在初始化进行一半的时候，别的线程是无法使用的，因为JVM会帮我们强行同步这个过程。另外由于静态变量只初始化一次，所以singleton仍然是单例的。
最终就是采用了静态内部类，创建了单例，他保证了

Singleton最多只有一个实例，在不考虑反射强行突破访问限制的情况下。
保证了并发访问的情况下，不会发生由于并发而产生多个实例。
保证了并发访问的情况下，不会由于初始化动作未完全完成而造成使用了尚未正确初始化的实例。
一切在你没用到的时候都成了不在乎的东西，现在用到了，是不是觉得特别厉害。