(1)单例模式

最新推荐文章于 2025-10-11 18:42:00 发布

转载最新推荐文章于 2025-10-11 18:42:00 发布 · 199 阅读

设计模式专栏收录该内容

2 篇文章

订阅专栏

原文：https://blog.csdn.net/zhangliangzi/article/details/52438401

http://www.importnew.com/18872.html

单例模式是一种很基础的设计模式，在面试时可能会被要求手写不同类型的单例模式代码，主要有三种模式：

1、饿汉模式：

[java]view plain copy
//饿汉模式，很饿很着急，所以类加载时即创建实例对象  
public class Singleton1 {  
      
    private static Singleton1 singleton = new Singleton1();  
      
    private Singleton1(){  
          
    }  
      
    public static Singleton1 getInstance(){  
        return singleton;  
    }  
}  

2、饱汉模式：

[java]view plain copy
//饱汉模式，很饱不着急，延迟加载，啥时候用啥时候创建实例，存在线程安全问题  
public class Singleton2 {  
  
    private static Singleton2 singleton;  
      
    private Singleton2(){  
          
    }  
      
    public static synchronized Singleton2 getInstance(){  
        if(singleton == null)   
            singleton = new Singleton2();  
        return singleton;  
    }  
}  

3、双重锁模式：

[java]view plain copy
//饱汉模式的双重锁模式，提高效率  
public class Singleton3 {  
    private static Singleton3 singleton;  
  
    private Singleton3(){ 
    }  
      
    public static Singleton3 getInstance(){  
        if(singleton == null){  
            synchronized(Singleton3.class){  
                if(singleton == null){  
                    singleton = new Singleton3();  
                }  
            }  
        }  
        return singleton;  
    }  
}  

几种模式的比较：

1、饿汉模式是线程安全的，因为实例对象在类加载过程中就会被创建，在getInstance()方法中只是直接返回对象引用。之所以被称为“饿汉”，是因为这种模式创建实例对象比较“急”，真的是饿坏了……

好处：简单明了，无需关注线程安全问题。

缺点：这样做的好处是编写简单，但是无法做到延迟创建对象。但是我们很多时候都希望对象可以尽可能地延迟加载，从而减小负载

2、饱汉模式不是线程安全的，因为是在需要的时候才会产生实例对象，生产之前会判断对象引用是否为空，这里，如果多个线程同时进入判断，就会生成多个实例对象，这是不符合单例的思想的。所以饱汉模式为了保证线程安全，就用synchronized关键字标识了方法。之所以被称为“饱汉”，因为它很饱，不急着生产实例，在需要的时候才会生产。

好处：延时加载，用的时候才会生产对象。

缺点：线程不安全。如果有两条线程同时调用getSingleton()方法，就有很大可能导致重复创建对象。

3、双重锁模式，是饱汉模式的优化，进行双重判断，当已经创建过实例对象后就无需加锁，提高效率。这种写法被称为“双重检查锁”，顾名思义，就是在getSingleton()方法中，进行两次null检查。看似多此一举，但实际上却极大提升了并发度，进而提升了性能。为什么可以提高并发度呢？就像上文说的，在单例中new的情况非常少，绝大多数都是可以并行的读操作。因此在加锁前多进行一次null检查就可以减少绝大多数的加锁操作，执行效率提高的目的也就达到了。

=========================

那么，这种写法是不是绝对安全呢？前面说了，从语义角度来看，并没有什么问题。但是其实还是有坑。说这个坑之前我们要先来看看volatile这个关键字。其实这个关键字有两层语义。第一层语义相信大家都比较熟悉，就是可见性。可见性指的是在一个线程中对该变量的修改会马上由工作内存（Work Memory）写回主内存（Main Memory），所以会马上反应在其它线程的读取操作中。顺便一提，工作内存和主内存可以近似理解为实际电脑中的高速缓存和主存，工作内存是线程独享的，主存是线程共享的。volatile的第二层语义是禁止指令重排序优化。大家知道我们写的代码（尤其是多线程代码），由于编译器优化，在实际执行的时候可能与我们编写的顺序不同。编译器只保证程序执行结果与源代码相同，却不保证实际指令的顺序与源代码相同。这在单线程看起来没什么问题，然而一旦引入多线程，这种乱序就可能导致严重问题。volatile关键字就可以从语义上解决这个问题。

注意，前面反复提到“从语义上讲是没有问题的”，但是很不幸，禁止指令重排优化这条语义直到jdk1.5以后才能正确工作。此前的JDK中即使将变量声明为volatile也无法完全避免重排序所导致的问题。所以，在jdk1.5版本前，双重检查锁形式的单例模式是无法保证线程安全的。

静态内部类法

那么，有没有一种延时加载，并且能保证线程安全的简单写法呢？我们可以把Singleton实例放到一个静态内部类中，这样就避免了静态实例在Singleton类加载的时候就创建对象，并且由于静态内部类只会被加载一次，所以这种写法也是线程安全的：

   
         public 
         class 
         Singleton {
        
         private 
         static 
         class 
         Holder {
        
         private 
         static 
         Singleton singleton = 
         new 
         Singleton();
        
         }
        
         private 
         Singleton(){}
        
         public 
         static 
         Singleton getSingleton(){
        
         return 
         Holder.singleton;
        
         }
        
         }

但是，上面提到的所有实现方式都有两个共同的缺点：

都需要额外的工作(Serializable、transient、readResolve())来实现序列化，否则每次反序列化一个序列化的对象实例时都会创建一个新的实例。
可能会有人使用反射强行调用我们的私有构造器（如果要避免这种情况，可以修改构造器，让它在创建第二个实例的时候抛异常）。

枚举写法

当然，还有一种更加优雅的方法来实现单例模式，那就是枚举写法：

   
         public 
         enum 
         Singleton {
        
         INSTANCE;
        
         private 
         String name;
        
         public 
         String getName(){
        
         return 
         name;
        
         }
        
         public 
         void 
         setName(String name){
        
         this
         .name = name;
        
         }
        
         }