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

原创文章，转载请注明:转载自 听风居士的博客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;

转载于:https://www.cnblogs.com/zhouyf/p/4583411.html