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

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

    首先回顾一下单例模式（Singleton）

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

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

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

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

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

    [java] view plaincopy
     
    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 plaincopy
     
    1. public static synchronized Singleton getInstance() {  
    2.         if (instance == null) {  
    3.             instance = new Singleton();  
    4.         }  
    5.         return instance;  
    6.     }  

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

    [java] view plaincopy
     
    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;
  • 相关阅读:
    哈希算法原理和一致性哈希算法
    负载均衡之轮循算法
    Mybatis的使用
    Spring与SpringMVC的整合
    编程式事务与声明式事务
    八大排序方法及对Arrays类的排序实现探讨
    单例模式的线程安全性
    HotSpot对象的创建及内存布局
    逃逸分析、栈上分配、标量替换、同步替换
    java编译器和解释器
  • 原文地址：https://www.cnblogs.com/zhouyf/p/4583411.html
Copyright © 2020-2023  润新知