第六章：单利模式，懒汉式，饿汉式以及静态内部类，双重检查

大家好，又见面了，我是你们的朋友全栈君。

文章转自：https://blog.csdn.net/u012453843/article/details/73743997

单例模式，最常见的就是饥饿模式和懒汉模式，一个直接实例化对象，一个在调用方法时进行实例化对象。

大家见的最多的莫过于下面这种单例模式了，这种模式是懒汉模式，就是说只有你调用getInstance方法的时候，它才会创建实例。但是这种方式有个非常致命的问题就是在多线程的情况下不能正常工作。

[html]
view plain
 copy
     
public class Singleton {    
    private static Singleton instance;    
    private Singleton (){}    
    
    public static Singleton getInstance() {    
       if (instance == null) {    
          instance = new Singleton();    
       }    
       return instance;    
    }    
}   

懒汉模式要想线程安全，大家第一想到的便是下面这种方式，就是在getInstance方法加上synchronized关键字，但是这种方式也有致命的缺点，那就是并发率太低。

[html]
view plain
 copy
     
public class Singleton {    
    private static Singleton instance;    
    private Singleton (){}    
    public static synchronized Singleton getInstance() {    
       if (instance == null) {    
          instance = new Singleton();    
       }    
       return instance;    
    }    
}  

上面是懒汉模式，下面我们再看下饿汉模式，如下所示。饿汉模式是典型的空间换取时间，当类装载的时候就会创建类的实例，不管你用不用，先创建出来，然后每次调用的时候就不需要再判断了，节省了运行时间。但如果一直没有人调用，这种浪费的空间就不值得，特别是在空间不足的情况下。

[html]
view plain
 copy
     
public class Singleton {    
    private static Singleton instance = new Singleton();    
    private Singleton (){}    
    public static Singleton getInstance() {    
       return instance;    
    }    
}   

在多线程模式中，考虑到性能和线程安全问题，我们一般选择下面两种比较经典的单例模式，在性能提高的同时，又保证了线程安全。

第一种方式：静态内部类

这种方式是最好的单例模式，而且还是线程安全的，为何这么说呢，静态内部类Singleton在初始化过程中是不会被加载的，只有当用户调用共用的getInstance方法时才会加载内部类Singleton并且实例化Singleton实例，也就是说，静态内部类这种方式也属于懒汉模式，只是实现方式不一样而已。之所以是线程安全的，是因为Singleton是静态的，静态内部类只会被实例化一次，也就是说不管有多少线程，大家拿到的是同一个实例，不会再去进行多次实例化，从而达到了线程安全的目的。由于没有加锁，所以并发性特别高，线程还安全，所以大家以后碰到单例模式，用静态内部类最为合适。如下图所示。

代码如下：

[html]
view plain
 copy
     
package com.internet.singleton;  
  
public class InnerSingleton {  
    private static class Singleton{  
        private static InnerSingleton single = new InnerSingleton();  
    }  
      
    public static InnerSingleton getInstance(){  
        return Singleton.single;  
    }  
}  

第二种方式：双重检查

首先，我说一下这种设计的初衷是什么，我们看到了getDs()方法中添加了类锁(synchronized (DubbleSingleton.class))，这种锁直接把整个类都锁住了，其它线程访问这个类的任何方法都要排队等候，设计者目的是当第一个线程访问getDs()方法时，它把整个类锁住，然后它把这个类实例化，然后后面的线程进入getDs()方法后一判断发现ds已经不是null了，于是便把第一个线程实例化好的实例返回。这样后续的线程无论并发有多少都没有问题，也不用再排队，直接拿取实例化好的实例即可。既然这样，为何在synchronized (DubbleSingleton.class)当中再判断一次ds是否为null呢？这个其实也好理解，synchronized上面不是模拟了一下初始化对象的准备时间吗？这个模拟是很有必要的，当第一个线程进入getDs()方法后，判断了一下df是否为null，发现是null，然后它就进入初始化对象的准备工作中去了，这个过程可能需要几秒钟，注意这时第一个线程还没有执行到synchronized这一行代码，也就是说还没有加上类锁，在这个过程当中假如又有多个线程要调用getDs()方法，它们便可以同时访问这个方法，这些线程判断ds依然是null，因此会进入到if判断里面，这些线程也进入到初始化对象的准备过程，等到第一个线程初始化对象准备完毕之后，它进入到synchronized这块代码处，给整个类加上了锁，这时后续再有线程的话，就要排队等候调用getDs()了。等第一个线程执行完实例化代码之后，刚才那些趁第一个线程没有锁住类的间隙偷偷摸进来的线程便也都进入到synchronized代码处，这些线程会依次锁住类进入到synchronized代码块中，这时如果代码块中不加一层if判断的话，就会再实例化一次DubbleSingleton类并返回，有几个这样偷溜进来的线程便会实例化几次Dubblesingleton实例。除了这些偷溜进来的线程之外，再来访问的线程由于在类外等待第一个线程执行完之后才有机会进入到方法体中，这时ds早已经实例化过了，因此第一个if判断便不成立，于是直接把当前Dubblesingleton实例返回。也就是说，后面的线程便可以高并发了，不用受锁的限制了。而如果在synchronized锁内再加一层判断的话，由于第二个线程进入锁内时，第一个线程肯定已经执行完了（synchronized这时扮演的是类锁），因此这时ds肯定不是null了，第二个线程一判断，发现ds不为null了，便直接把第一个线程实例化好的实例返回了，同理，其它线程也把第一个线程实例化好的实例返回。从而保证了线程安全。

双重检查与懒汉加锁模式最大的区别在于，双重检查加锁只是一瞬间的事儿，后续无论有多少个线程都可以自由访问，没有线程安全问题。而懒汉加锁模式由于每个线程都要排队访问getInstance方法，因此效率太低。这就是他们之间的区别。双重检查的代码类如下图所示。

第六章：单利模式，懒汉式，饿汉式以及静态内部类，双重检查

代码如下：

[html]
view plain
 copy
     
package com.internet.singleton;  
  
public class DubbleSingleton {  
      
    private static DubbleSingleton ds;  
      
    public static DubbleSingleton getDs(){  
        if(ds == null){  
            try {  
                //模拟初始化对象的准备时间…  
                Thread.sleep(3000);  
            } catch (Exception e) {  
                e.printStackTrace();  
            }  
            synchronized (DubbleSingleton.class) {  
                if(ds == null){  
                    ds = new DubbleSingleton();  
                }  
            }  
        }  
        return ds;  
    }  
      
    public static void main(String[] args){  
        Thread t1 = new Thread(new Runnable() {  
              
            @Override  
            public void run() {  
                System.out.println(DubbleSingleton.getDs().hashCode());  
            }  
        },”t1″);  
          
        Thread t2 = new Thread(new Runnable() {  
              
            @Override  
            public void run() {  
                System.out.println(DubbleSingleton.getDs().hashCode());  
            }  
        },”t2″);  
          
                Thread t3 = new Thread(new Runnable() {  
              
            @Override  
            public void run() {  
                System.out.println(DubbleSingleton.getDs().hashCode());  
            }  
        },”t3″);  
          
                t1.start();  
                t2.start();  
                t3.start();  
    }  
}  