深入解析单例线程安全问题的迷思

时间:2022-10-31 17:38:33

原创文章,转载请注明:转载自 听风居士的博客http://www.cnblogs.com/zhouyf/

首先回顾一下单例模式(Singleton

单例对象(Singleton)是一种常用的设计模式。在Java应用中,单例对象能保证在一个JVM中,该对象只有一个实例存在。这样的模式有几个好处:

1、某些类创建比较频繁,对于一些大型的对象,这是一笔很大的系统开销。

2、省去了new操作符,降低了系统内存的使用频率,减轻GC压力。

3、有些类如交易所的核心交易引擎,控制着交易流程,如果该类可以创建多个的话,系统完全乱了。(比如一个军队出现了多个司令员同时指挥,肯定会乱成一团),所以只有使用单例模式,才能保证核心交易服务器独立控制整个流程。

首先我们写一个简单的单例类:

 

[java]  view plain copy
 
  1. public class Singleton {  
  2.   
  3.     /* 持有私有静态实例,防止被引用,此处赋值为null,目的是实现延迟加载 */  
  4.     private static Singleton instance = null;  
  5.   
  6.     /* 私有构造方法,防止被实例化 */  
  7.     private Singleton() {  
  8.     }  
  9.   
  10.     /* 静态工程方法,创建实例 */  
  11.     public static Singleton getInstance() {  
  12.         if (instance == null) {  
  13.             instance = new Singleton();  
  14.         }  
  15.         return instance;  
  16.     }  
  17.   
  18.     /* 如果该对象被用于序列化,可以保证对象在序列化前后保持一致 */  
  19.     public Object readResolve() {  
  20.         return instance;  
  21.     }  
  22. }  


这个类可以满足基本要求,但是,像这样毫无线程安全保护的类,如果我们把它放入多线程的环境下,肯定就会出现问题了,如何解决?我们首先会想到对getInstance方法加synchronized关键字,如下:

[java]  view plain copy
 
  1. public static synchronized Singleton getInstance() {  
  2.         if (instance == null) {  
  3.             instance = new Singleton();  
  4.         }  
  5.         return instance;  
  6.     }  

但是,synchronized关键字锁住的是这个对象,这样的用法,在性能上会有所下降,因为每次调用getInstance(),都要对对象上锁,事实上,只有在第一次创建对象的时候需要加锁,之后就不需要了,所以,这个地方需要改进。我们改成下面这个:

 

[java]  view plain copy
 
  1. public static Singleton getInstance() {  
  2.         if (instance == null) {  
  3.             synchronized (instance) {  
  4.                 if (instance == null) {  
  5.                     instance = new Singleton();  
  6.                 }  
  7.             }  
  8.         }  
  9.         return instance;  
  10.     }   

 

 

原创文章,转载请注明:转载自 周岳飞博客(http://zhou-yuefei.iteye.com/)

 

不幸的是,这个代码在优化编译器或共享内存的多处理器下就会有问题。

第一个问题:

同步代码块中对象的初始化,和赋值操作的顺序是未知的(不清楚的可以看这篇文章http://zhou-yuefei.iteye.com/blog/2219228),也就是说有可能JVM会为新的Singleton实例分配空间,然后直接赋值给instance成员,然后再去初始化这个Singleton实例。这样就可能出错了,我们以A、B两个线程为例:

a>A、B线程同时进入了第一个if判断

b>A首先进入synchronized块,由于instance为null,所以它执行instance = new Singleton();

c>由于JVM内部的优化机制,JVM先画出了一些分配给Singleton实例的空白内存,并赋值给instance成员(注意此时JVM没有开始初始化这个实例),然后A离开了synchronized块。

d>B进入synchronized块,由于instance此时不是null,因此它马上离开了synchronized块并将结果返回给调用该方法的程序。

e>此时B线程打算使用Singleton实例,却发现它没有被初始化,(Singleton的构造方法未执行,导致其中的字段值不是构造方法的中指定的值)

 
于是,很多人做了改进使用类似下面的代码

 // (Still) Broken multithreaded version

// "Double-Checked Locking" idiom
class Foo { 
  private Helper helper = null;
  public Helper getHelper() {
    if (helper == null) {
      Helper h;
      synchronized(this) {
        h = helper;
        if (h == null) 
            synchronized (this) {
              h = new Helper();
            } // release inner synchronization lock
        helper = h;
        } 
      }    
    return helper;
    }
  // other functions and members...
  }

 

此代码将Helper对象构建放到内部的同步块中,。在这里,直观的想法是,在离开同步代码块的时候,有一个内存屏障,并应防止Helper对象初始化和变量赋值操作的重排序。

然而,sychronized 操作只保证在释放锁前,同步代码块中的操作被执行,并不保证已经完成,所以,上面的问题还会出现

 

还有一个问题:

关于java内存可见性,每个线程都要自己的本地内存,每个线程对变量的更新操作,其他线程不能立即感知到,线程A将helper的值更新了,可是线程B检查还是null,从而又创建了个对象,

解决办法加上volatile 关键字

 

  private volatile  Helper helper = null;