设计模式学习——单例模式

【转】设计模式学习（四）——单例模式

使用场景

开始介绍单例模式之前，必须要先描述下使用场景，以及自己在代码编写时遇到的痛点。

在很多时候，有些对象我们希望在整个程序只有一个实例，如线程池、数据库连接池、缓存、日志对象、注册表等。而最近，在我的实际工作中，在编写接口自动化代码时就遇到了下列两种场景：

1. 自动化所有用到的接口，在发送https请求时，都需要包含一个参数sessionId，该参数可以通过登录webserver的接口获取，我希望这个sessiondId是唯一的，且只需要获取一次。
2. 由于系统的webserver是支持高可用的，即如果一个active webserver挂了，另一个standby webserver就会立即投入工作，此时web host就需要切换。为了支持高可用，我在发送请求时加入了兼容代码：如果捕获了连接异常（ConnectException）就会去尝试switchWebHost。在多线程并发执行测试用例的时候，我希望这个switchWebHost操作只需要执行一次。而如果将整个代码块加入synchronized同步，会导致不能同时发送https请求，导致并发量降低。

借用单例模式或借鉴其思想就可以解决上述问题。

定义

单例模式确保一个类只有一个实例，并提供一个全局访问点。

经典单例模式

public class Singleton{
    private static Singleton uniqueInstance;
    private Singleton(){}
    public static Singleton getInstance(){
        if (null==uniqueInstance){
            uniqueInstance = new Singleton();
        }
        return uniqueInstance;
    }
}

Singleton类拥有一个静态变量uniqueInstance来记录Singleton的唯一实例，注意它的构造函数是private的，这就注定了只有Sinleton类内才可以使用该构造器。在其他类中我们无法通过new Singleton()的方式类获取一个Singleton的实例，只能通过Singleton.getInstance()的方式获取。并且由于uniqueInstance是一个静态变量，属于Singleton这个类，所以保证了其唯一性。

经典模式有个好处，就是它的对象的实例化只有等到getInstance方法被调用时才会被jvm加载，如果getInstance始终没有被调用，jvm就不会生成该实例。如果该对象的实例化需要消耗较多的资源，这种“延迟实例化”的方式可以减小jvm的开销。

但是，上述的实现方式很容易会想到存在一个严重的缺陷，就是“非线程安全”。当多个线程同时调用Singleton.getInstance()来获取实例时，uniqueInstance对象就可能被多次实例化。最简单的方式就是通过synchronized关键字来实现线程同步：

public static synchronized Singleton getInstance(){
    if (null==uniqueInstance){
        uniqueInstance = new Singleton();
    }
    return uniqueInstance;
}

“急切实例化”方式

在经典单例模式中加入了synchronized关键字后，我们可以发现整个getInstance方法是线程同步的操作，当一个线程在调用该方法时，其他所有线程都会被阻塞。如果getInstance方法的执行时间开销很小，那么我们是可以使用这种方式的。但是，如果getInstanc方法的执行时间开销很大，就会极大地降低并发效率。在这种情况下，可以考虑将实例化的操作提前到Singleton类加载的时候，即“急切实例化”方式：

public class Singleton{
    private static Singleton uniqueInstance= new Singleton();
    private Singleton(){}
    public static Singleton getInstance(){
        return uniqueInstance;
    }
}

利用这种方式，我们可以依赖jvm在加载这个类时马上创建此唯一的单例，jvm会保证在任何线程访问uniqueInstance静态变量之前，一定先创建此实例。

“双重检查加锁”方式

综合上述两种方式，为了平衡实例创建开销和并发量受限的代价，“双重检查加锁”通过部分同步的方式同时解决了两者的问题。

public class Singleton{
    private volatile static Singleton uniqueInstance;
    private Singleton(){}
    public Singleton getInstance(){
        if (null == uniqueInstance){
            synchronized (Singleton.class){
                if( null == uniqueInstance){
                    uniqueInstance = new Singleton();
                }
            }
        }
        return uniqueInstance;
    }
}

可以看到，这种方式也是将实例化延迟到了getInstance方法被调用时，区别于经典单例模式，该方式引入了“双重检查”，在多线程并行执行到同步代码块时，会再次判断uniqueInsance是否为null，有效防止了多次实例化的发生。并且这种方式并没有对整个getInstance方法加锁，只是在第一次生成Singleton的唯一实例时进行了一次同步，并没有降低程序的并发性。

volatile关键字

而对于volatile关键字的使用，查阅了《Thinking in Java》，作者的解释是“volatile定义的域在发生修改后，它会直接写到主存中，对其他任务可见”。

用volatile修饰的变量，线程在每次开始使用变量的时候，都会读取变量修改后的最新的值。但是这并不代表，使用volatile就可以实现线程同步，它只是在线程“开始使用”该变量时读取到该变量的最新值。当线程访问某一个对象时候值的时候，首先通过对象的引用找到对应在堆内存（主存）的变量的值，然后把堆内存变量的具体值load到线程本地内存（本地缓存）中，建立一个变量副本，之后线程就不再和对象在堆内存变量值有任何关系，而是直接修改副本变量的值，在修改完之后的某一个时刻（线程退出之前），自动把线程变量副本的值回写到对象在堆中变量。下面这幅流程图描述了一个共享变量在线程中被使用时其线程工作内存与主内存的交互方式。

图片转自博客：God is Coder

静态内部类方式

最后再介绍一下静态内部类的方式也可以实现同时满足性能和并发要求的单例模式。

public class Singleton{
    private static class Holder{
       private static Singleton INSTANCE = new Singleton();
    }
    private Singleton(){}
    public static final Singleton getInstance(){
        return Holder.INSTANCE;
    }
}

可以看到，该方式其实是第二种“急切实例化”方式的变种，该实例只有在jvm加载类Holder时会被实例化，并且可以保证在各个线程获取Holder.INSTANCE变量之前完成。在保证线程安全的同时，又可以延迟实例化，并且没有降低并发性。

问题解决

在介绍了几种单例模式后，现在来解决我们在“使用场景”中碰到的两个问题。

1.session获取

使用“静态内部类”方法创建SessionFactory类：

public class SessionFactory {
    private static String sessionId;
    private static BaseConfig baseConfig = BaseConfigFactory.getInstance();
private static class SessionidHolder{
    private final static SessionFactory INSTANCE = new SessionFactory();
}

public static final SessionFactory getInstance(){
    return SessionidHolder.INSTANCE;
}
private SessionFactory(){
    LoginApi api  = new LoginApi();
    String username = baseConfig.getLoginUsername();
    String password = baseConfig.getLoginPassword();
    sessionId= api.login(username, password).getValue("session.id");
}

public String getSessionId() {
    return sessionId;
}

}

使用Testng编写测试代码：

public class SessionTest {
    @Test(threadPoolSize=10, invocationCount=10)
    public void sessionTest(){
        SessionFactory sessionFactory = SessionFactory.getInstance();
        System.out.println("Thread id="+ Thread.currentThread().getId()+ 
        ", session.id=" + sessionFactory.getSessionId());
    }
}

测试结果:

Thread id=13, session.id=36afe1a1-19df-4400-8fbf-4687293d7294
Thread id=18, session.id=36afe1a1-19df-4400-8fbf-4687293d7294
Thread id=11, session.id=36afe1a1-19df-4400-8fbf-4687293d7294
Thread id=16, session.id=36afe1a1-19df-4400-8fbf-4687293d7294
Thread id=12, session.id=36afe1a1-19df-4400-8fbf-4687293d7294
Thread id=17, session.id=36afe1a1-19df-4400-8fbf-4687293d7294
Thread id=10, session.id=36afe1a1-19df-4400-8fbf-4687293d7294
Thread id=15, session.id=36afe1a1-19df-4400-8fbf-4687293d7294
Thread id=14, session.id=36afe1a1-19df-4400-8fbf-4687293d7294
Thread id=19, session.id=36afe1a1-19df-4400-8fbf-4687293d7294

可以看到，10个线程并发执行时，session.id是唯一的，说明sessionFactory是唯一的，只被实例化了一次。

或许你会问，能不能在SessionFactory中将getSessionId方法设为静态方法，直接调用SessionFactory.getSessionId()来获取sessionId？当然可以，但是前提是你还是必须要先通过调用SessionFactory.getInstance()方法来将SessionFactory类实例化，否则你会发现获取到的sessionId就是null，可以看出，jvm在加载一个类时，如果该类没有被实例化就不会去主动调用它的构造方法。

2.遇到webserver切换时，希望switchWebHost操作只需要执行一次

借用“双重检查，部分同步”的思想，可以设计伪代码逻辑如下（篇幅考虑使用伪代码代替）：

try {
    sendHttpsRequest();
}catch(ConnectException e){
    numRquestFail++;
    synchronized (BaseApi.class) {
        if (isWebHostChanged()){
            return;
        }
        switchWebHost();
    }
}

即，将切换webhost部分的代码进行同步，并且在切换时先通过调用isWebHostChanged()方法判断是否已经被其他线程切换。防止host多次发生切换。同时，这种方式不会影响到sendHttpsRequest方法的并发。

总结

其实，写到这里，从早上开始拿起手头的《Head First 设计模式》看单例模式，到翻书查资料理解相关的知识（volatile、jvm内存管理）
到重构自动化的代码，到反复测试各种条件下的程序执行情况，到写完整篇总结，已经花了一整天的时间，虽说花的时间有点多，但是知识的扫盲本身就不是一蹴而就的，尤其基础的东西理解地深刻我相信对以后的学习肯定是有帮助的。