Double Check Locking -- Java并发

the double-check locking broken  主要解释下内存模型相关的这篇文章

http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

 

 

// Broken multithreaded version
// "Double-Checked Locking" idiom
class Foo { 
  private Helper helper = null;
  public Helper getHelper() {
    if (helper == null) 
      synchronized(this) {
        if (helper == null) 
          helper = new Helper();
      }    
    return helper;
    }
  // other functions and members...
  }

 

双检查锁，应用范围很广，很多开源项目，spring，tomcat都能找到。但以上算法是有问题。

出现问题的原因之一：暴露未构造完整的对象。由于编译器或者cpu指令优化，可能导致出现，将未构造完整的Helper对象

引用赋值给 helper字段。假设Helper有个int 属性id = 100。就是说客户端获取到的这个helper，id的值可能是0（没有被正确初始化，即未被构造完整）。解决方法是加volatile。volatile有效防止reorder，从而保证赋值前对象是完整构造过的。

评论

13 楼 Silverside 2011-08-08  

jilen 写道

skzr.org 写道

以下内容是我当时学习时整理的双检查：

1. 延迟实例化：使用正确的双检查模式，需要new Instance的的必须如此操作

实例：

public static T getInstance() {
        if (instance == null) {
                synchronized (T) {
                        if (instance == null) instance = new T();
                }
        }
        return instance;
}
问题： instance = new T(); 当new的时候，做了两个操作
第一步申请内存，并且把引用给instance(此时instance!=null)
第二步调用构造器，初始化数据
所以：其他线程可能使用了这个不完整的实例（虽然new已经分配了内存，从而instance!=null, 但可能此对象还在构造，所以说instance实例还不完整)
解决：

public static T getInstance() {
        if (instance == null) {
                synchronized (T) {
                        if (instance == null) {
                                T t = new T();
                                instance = t;//<----解决办法
                        }
                }
        }
        return instance;
}
注意：其他非instacne = new T()这样的，可以不用这么处理，比如: instance = existObj.getT();也就是任何非new的都不会出问题

我想你可能有些误解 Object t = new Object（）；这个表达式做文法分析的时候很显然是先构造后赋值的。之所以出现先赋值后构造，是编译器或者cpu指令优化（smp）才出现的偶然情况，而且发生之概率也是很低的。如果编译器发现构造器没有抛出任何异常，也没有任何同步，则可能因为优化指令等原因进行reorder，打乱赋值和初始化顺序。即使编译器指令正常，现代CPU也可能会在这些指令执行时reorder造成乱序。我想你的fix不能真的fix这个问题。

这个时候构造器会报什么异常呢？

12 楼 jilen 2011-05-28  

scanfprintf123 写道

jilen 写道

skzr.org 写道

以下内容是我当时学习时整理的双检查：

1. 延迟实例化：使用正确的双检查模式，需要new Instance的的必须如此操作

实例：

public static T getInstance() {
        if (instance == null) {
                synchronized (T) {
                        if (instance == null) instance = new T();
                }
        }
        return instance;
}
问题： instance = new T(); 当new的时候，做了两个操作
第一步申请内存，并且把引用给instance(此时instance!=null)
第二步调用构造器，初始化数据
所以：其他线程可能使用了这个不完整的实例（虽然new已经分配了内存，从而instance!=null, 但可能此对象还在构造，所以说instance实例还不完整)
解决：

public static T getInstance() {
        if (instance == null) {
                synchronized (T) {
                        if (instance == null) {
                                T t = new T();
                                instance = t;//<----解决办法
                        }
                }
        }
        return instance;
}
注意：其他非instacne = new T()这样的，可以不用这么处理，比如: instance = existObj.getT();也就是任何非new的都不会出问题

我想你可能有些误解 Object t = new Object（）；这个表达式做文法分析的时候很显然是先构造后赋值的。之所以出现先赋值后构造，是编译器或者cpu指令优化（smp）才出现的偶然情况，而且发生之概率也是很低的。如果编译器发现构造器没有抛出任何异常，也没有任何同步，则可能因为优化指令等原因进行reorder，打乱赋值和初始化顺序。即使编译器指令正常，现代CPU也可能会在这些指令执行时reorder造成乱序。我想你的fix不能真的fix这个问题。

如果出现了重排序，导致先赋值后进行构造了，即使加了volatile，能避免吗？

从Happen-before 关系并不能推出这个， 即使是从http://gee.cs.oswego.edu/dl/jmm/cookbook.html 中所写防止reorder关系，也推不出来，

    // Broken multithreaded version  
    // "Double-Checked Locking" idiom  
    class Foo {   
      private volatile Helper helper = null;  
      public Helper getHelper() {  
        if (helper == null)   
          synchronized(this) {  
            if (helper == null)   
              helper = malloc(); // other thread can see the reference but not the status of helper, since constructor haven't happened yet.
              //constructor happens here
          }      
        return helper;  
        }  
      // other functions and members...  
      }  

JDK5 and later extends the semantics for volatile so that the system will not allow a write of a volatile to be reordered with respect to any previous read or write, and a read of a volatile cannot be reordered with respect to any following read or write.
不会发生reorder，所以构造总是在赋值之前。

11 楼 scanfprintf123 2011-05-27  

jilen 写道

skzr.org 写道

以下内容是我当时学习时整理的双检查：

1. 延迟实例化：使用正确的双检查模式，需要new Instance的的必须如此操作

实例：

public static T getInstance() {
        if (instance == null) {
                synchronized (T) {
                        if (instance == null) instance = new T();
                }
        }
        return instance;
}
问题： instance = new T(); 当new的时候，做了两个操作
第一步申请内存，并且把引用给instance(此时instance!=null)
第二步调用构造器，初始化数据
所以：其他线程可能使用了这个不完整的实例（虽然new已经分配了内存，从而instance!=null, 但可能此对象还在构造，所以说instance实例还不完整)
解决：

public static T getInstance() {
        if (instance == null) {
                synchronized (T) {
                        if (instance == null) {
                                T t = new T();
                                instance = t;//<----解决办法
                        }
                }
        }
        return instance;
}
注意：其他非instacne = new T()这样的，可以不用这么处理，比如: instance = existObj.getT();也就是任何非new的都不会出问题

我想你可能有些误解 Object t = new Object（）；这个表达式做文法分析的时候很显然是先构造后赋值的。之所以出现先赋值后构造，是编译器或者cpu指令优化（smp）才出现的偶然情况，而且发生之概率也是很低的。如果编译器发现构造器没有抛出任何异常，也没有任何同步，则可能因为优化指令等原因进行reorder，打乱赋值和初始化顺序。即使编译器指令正常，现代CPU也可能会在这些指令执行时reorder造成乱序。我想你的fix不能真的fix这个问题。

如果出现了重排序，导致先赋值后进行构造了，即使加了volatile，能避免吗？

从Happen-before 关系并不能推出这个， 即使是从http://gee.cs.oswego.edu/dl/jmm/cookbook.html 中所写防止reorder关系，也推不出来，

    // Broken multithreaded version  
    // "Double-Checked Locking" idiom  
    class Foo {   
      private volatile Helper helper = null;  
      public Helper getHelper() {  
        if (helper == null)   
          synchronized(this) {  
            if (helper == null)   
              helper = malloc(); // other thread can see the reference but not the status of helper, since constructor haven't happened yet.
              //constructor happens here
          }      
        return helper;  
        }  
      // other functions and members...  
      }  

10 楼 jilen 2011-05-22  

Object t = new Object();
another = t;这样的语句在做语义分析后产生的文法树，跟
another = new Object()很可能是一样的。所以我想你看的书或许有些问题

9 楼 jilen 2011-05-22  

注意，编译器可能会对构造方法调用做内联（inline）所以很可能不是通过堆栈做初始化，而是直接将初始化指令内联到代码中。所以这个时候出现reorder的情况是有可能的

8 楼 jilen 2011-05-22  

skzr.org 写道

以下内容是我当时学习时整理的双检查：

1. 延迟实例化：使用正确的双检查模式，需要new Instance的的必须如此操作

实例：

public static T getInstance() {
        if (instance == null) {
                synchronized (T) {
                        if (instance == null) instance = new T();
                }
        }
        return instance;
}
问题： instance = new T(); 当new的时候，做了两个操作
第一步申请内存，并且把引用给instance(此时instance!=null)
第二步调用构造器，初始化数据
所以：其他线程可能使用了这个不完整的实例（虽然new已经分配了内存，从而instance!=null, 但可能此对象还在构造，所以说instance实例还不完整)
解决：

public static T getInstance() {
        if (instance == null) {
                synchronized (T) {
                        if (instance == null) {
                                T t = new T();
                                instance = t;//<----解决办法
                        }
                }
        }
        return instance;
}
注意：其他非instacne = new T()这样的，可以不用这么处理，比如: instance = existObj.getT();也就是任何非new的都不会出问题

我想你可能有些误解 Object t = new Object（）；这个表达式做文法分析的时候很显然是先构造后赋值的。之所以出现先赋值后构造，是编译器或者cpu指令优化（smp）才出现的偶然情况，而且发生之概率也是很低的。如果编译器发现构造器没有抛出任何异常，也没有任何同步，则可能因为优化指令等原因进行reorder，打乱赋值和初始化顺序。即使编译器指令正常，现代CPU也可能会在这些指令执行时reorder造成乱序。我想你的fix不能真的fix这个问题。

7 楼 skzr.org 2011-05-21  

以下内容是我当时学习时整理的双检查：

1. 延迟实例化：使用正确的双检查模式，需要new Instance的的必须如此操作

实例：

public static T getInstance() {
        if (instance == null) {
                synchronized (T) {
                        if (instance == null) instance = new T();
                }
        }
        return instance;
}
问题： instance = new T(); 当new的时候，做了两个操作
第一步申请内存，并且把引用给instance(此时instance!=null)
第二步调用构造器，初始化数据
所以：其他线程可能使用了这个不完整的实例（虽然new已经分配了内存，从而instance!=null, 但可能此对象还在构造，所以说instance实例还不完整)
解决：

public static T getInstance() {
        if (instance == null) {
                synchronized (T) {
                        if (instance == null) {
                                T t = new T();
                                instance = t;//<----解决办法
                        }
                }
        }
        return instance;
}
注意：其他非instacne = new T()这样的，可以不用这么处理，比如: instance = existObj.getT();也就是任何非new的都不会出问题

6 楼 skzr.org 2011-05-21  

class Foo {  
  private Helper helper = null; 
  public Helper getHelper() { 
    if (helper == null)  
      synchronized(this) { 
        if (helper == null)  
         Helper tmp = new Helper(); 
          helper = tmp;
      }     
    return helper; 
    } 
  // other functions and members... 
  }
从class字节码是看不出问题的，这个问题是运行时才会可能发生。

这个双检查可能导致的问题确实是 暴露未构造完整的对象，因为new操作和构造器调用的时序有点小问题。getHelper()可能获得的是一个未构造完整的对象。


注意看上面的代码： Helper tmp = new Helper(); 
          helper = tmp;
传说中是可以保证正确构造的。记得有本书介绍这个双检查时提到了怎样解决这个问题。

5 楼 skzr.org 2011-05-21  

class Foo {  
  private Helper helper = null; 
  public Helper getHelper() { 
    if (helper == null)  
      synchronized(this) { 
        if (helper == null)  
          helper = new Helper(); 
      }     
    return helper; 
    } 
  // other functions and members... 
  } 

4 楼 Technoboy 2011-05-20  

jilen 写道

Technoboy 写道

因为JMM的原因，helper可能在constructor被调用之前就被存储，如果此时另外一个thread调用getHelper方法且在helper的constructor调用前，那么就有这种id为0的可能。加volatile关键字，问题可以解决，但是helper会被初始化一次以上。

我想不会初始化一次以上不论如何能进入synchronized块得线程只能有一个，这个线程执行期间其他试图进入synchronized块线程都阻塞，当线程执行完毕释放锁时，其他试图进入synchronized块得线程可以获得锁，但此时helper已经不是null了

恩，不好意思，我表述错了，你说的对，我和你是一个意思，我想解释在不加volatile关键字的情形，结果说返了，sorry

3 楼 jilen 2011-05-20  

Technoboy 写道

因为JMM的原因，helper可能在constructor被调用之前就被存储，如果此时另外一个thread调用getHelper方法且在helper的constructor调用前，那么就有这种id为0的可能。加volatile关键字，问题可以解决，但是helper会被初始化一次以上。

我想不会初始化一次以上不论如何能进入synchronized块得线程只能有一个，这个线程执行期间其他试图进入synchronized块线程都阻塞，当线程执行完毕释放锁时，其他试图进入synchronized块得线程可以获得锁，但此时helper已经不是null了

2 楼 Technoboy 2011-05-20  

因为JMM的原因，helper可能在constructor被调用之前就被存储，如果此时另外一个thread调用getHelper方法且在helper的constructor调用前，那么就有这种id为0的可能。加volatile关键字，问题可以解决，但是helper会被初始化一次以上。

1 楼 witcheryne 2011-05-20  

从来没意识到过这种问题....

volatile 这个关键字, 还是最近在 《Effective Java》  中看到的