双重检察锁定及单例模式【转】

2012-11-03

双重检查锁定及单例模式【转】?? 单例创建模式是一个通用的编程习语。和多线程一起使用时，必需使用某种类型的

双重检查锁定及单例模式【转】

?? 单例创建模式是一个通用的编程习语。和多线程一起使用时，必需使用某种类型的同步。在努力创建更有效的代码时，Java 程序员们创建了双重检查锁定习语，将其和单例创建模式一起使用，从而限制同步代码量。然而，由于一些不太常见的 Java 内存模型细节的原因，并不能保证这个双重检查锁定习语有效。它偶尔会失败，而不是总失败。此外，它失败的原因并不明显，还包含 Java 内存模型的一些隐秘细节。这些事实将导致代码失败，原因是双重检查锁定难于跟踪。在本文余下的部分里，我们将详细介绍双重检查锁定习语，从而理解它在何处失效。

import java.util.*;class Singleton {private static Singleton instance;private Vector v;private boolean inUse;private Singleton() {v = new Vector();v.addElement(new Object());inUse = true;}public static Singleton getInstance() {if (instance == null) // 1instance = new Singleton(); // 2return instance; // 3}}

????? 此类的设计确保只创建一个 Singleton 对象。构造函数被声明为 private，getInstance() 方法只创建一个对象。这个实现适合于单线程程序。然而，当引入多线程时，就必须通过同步来保护 getInstance() 方法。如果不保护 getInstance() 方法，则可能返回 Singleton 对象的两个不同的实例。假设两个线程并发调用 getInstance() 方法并且按以下顺序执行调用：

getInstance()

instance

null

if

getInstance()

instance

null

if

Singleton

instance

Singleton

????? 结果是 getInstance() 方法创建了两个 Singleton 对象，而它本该只创建一个对象。通过同步 getInstance() 方法从而在同一时间只允许一个线程执行代码，这个问题得以改正，如清单 2 所示：

清单 2. 线程安全的 getInstance() 方法

public static synchronized Singleton getInstance(){  if (instance == null)          //1    instance = new Singleton();  //2  return instance;               //3}

???? 清单 2 中的代码针对多线程访问 getInstance() 方法运行得很好。然而，当分析这段代码时，您会意识到只有在第一次调用方法时才需要同步。由于只有第一次调用执行了 //2 处的代码，而只有此行代码需要同步，因此就无需对后续调用使用同步。所有其他调用用于决定 instance 是非 null 的，并将其返回。多线程能够安全并发地执行除第一次调用外的所有调用。尽管如此，由于该方法是 synchronized 的，需要为该方法的每一次调用付出同步的代价，即使只有第一次调用需要同步。为使此方法更为有效，一个被称为双重检查锁定的习语就应运而生了。这个想法是为了避免对除第一次调用外的所有调用都实行同步的昂贵代价。同步的代价在不同的 JVM 间是不同的。在早期，代价相当高。随着更高级的 JVM 的出现，同步的代价降低了，但出入 synchronized 方法或块仍然有性能损失。不考虑 JVM 技术的进步，程序员们绝不想不必要地浪费处理时间。

因为只有清单 2 中的 //2 行需要同步，我们可以只将其包装到一个同步块中，如清单 3 所示：

?清单 3. getInstance() 方法

public static Singleton getInstance(){  if (instance == null)  {    synchronized(Singleton.class) {      instance = new Singleton();    }  }  return instance;}

??? 清单 3 中的代码展示了用多线程加以说明的和清单 1 相同的问题。当 instance 为 null 时，两个线程可以并发地进入 if 语句内部。然后，一个线程进入 synchronized 块来初始化 instance，而另一个线程则被阻断。当第一个线程退出 synchronized 块时，等待着的线程进入并创建另一个 Singleton 对象。注意：当第二个线程进入 synchronized 块时，它并没有检查 instance 是否非 null。

?? 为处理清单 3 中的问题，我们需要对 instance 进行第二次检查。这就是“双重检查锁定”名称的由来。将双重查锁定习语应用到清单 3 的结果就是清单 4 。

清单 4. 双重检查锁定示例

public static Singleton getInstance(){  if (instance == null)  {    synchronized(Singleton.class) {  //1      if (instance == null)          //2        instance = new Singleton();  //3    }  }  return instance;}

???? 双重检查锁定背后的理论是：在 //2 处的第二次检查使（如清单 3 中那样）创建两个不同的 Singleton 对象成为不可能。假设有下列事件序列：

getInstance()

instance

null

synchronized

getInstance()

instance

null

Singleton

instance

synchronized

getInstance()

instance

null

instance

null

Singleton

??? 双重检查锁定背后的理论是完美的。不幸地是，现实完全不同。双重检查锁定的问题是：并不能保证它会在单处理器或多处理器计算机上顺利运行。

??? 双重检查锁定失败的问题并不归咎于 JVM 中的实现 bug，而是归咎于 Java 平台内存模型。内存模型允许所谓“无序写入”，这也是这些习语失败的一个主要原因。

mem = allocate(); //Allocate memory for Singleton object.instance = mem; //Note that instance is now non-null, but //has not been initialized.ctorSingleton(instance); //Invoke constructor for Singleton passing //instance.

这段伪代码不仅是可能的，而且是一些 JIT 编译器上真实发生的。执行的顺序是颠倒的，但鉴于当前的内存模型，这也是允许发生的。JIT 编译器的这一行为使双重检查锁定的问题只不过是一次学术实践而已。

为说明这一情况，假设有清单 5 中的代码。它包含一个剥离版的 getInstance() 方法。我已经删除了“双重检查性”以简化我们对生成的汇编代码（清单 6）的回顾。我们只关心 JIT 编译器如何编译 instance=new Singleton(); 代码。此外，我提供了一个简单的构造函数来明确说明汇编代码中该构造函数的运行情况。

清单 5. 用于演示无序写入的单例类

class Singleton{  private static Singleton instance;  private boolean inUse;  private int val;    private Singleton()  {    inUse = true;    val = 5;  }  public static Singleton getInstance()  {    if (instance == null)      instance = new Singleton();    return instance;  }}

清单 6 包含由 Sun JDK 1.2.1 JIT 编译器为清单 5 中的 getInstance() 方法体生成的汇编代码。

清单 6. 由清单 5 中的代码生成的汇编代码

;asm code generated for getInstance054D20B0   mov         eax,[049388C8]      ;load instance ref054D20B5   test        eax,eax             ;test for null054D20B7   jne         054D20D7054D20B9   mov         eax,14C0988h054D20BE   call        503EF8F0            ;allocate memory054D20C3   mov         [049388C8],eax      ;store pointer in                                            ;instance ref. instance                                             ;non-null and ctor                                           ;has not run054D20C8   mov         ecx,dword ptr [eax] 054D20CA   mov         dword ptr [ecx],1   ;inline ctor - inUse=true;054D20D0   mov         dword ptr [ecx+4],5 ;inline ctor - val=5;054D20D7   mov         ebx,dword ptr ds:[49388C8h]054D20DD   jmp         054D20B0

注: 为引用下列说明中的汇编代码行，我将引用指令地址的最后两个值，因为它们都以 054D20 开头。例如，B5 代表 test eax,eax。

???? 汇编代码是通过运行一个在无限循环中调用 getInstance() 方法的测试程序来生成的。程序运行时，请运行 Microsoft Visual C++ 调试器并将其附到表示测试程序的 Java 进程中。然后，中断执行并找到表示该无限循环的汇编代码。

?? B0 和 B5 处的前两行汇编代码将 instance 引用从内存位置 049388C8 加载至 eax 中，并进行 null 检查。这跟清单 5 中的 getInstance() 方法的第一行代码相对应。第一次调用此方法时，instance 为 null，代码执行到 B9。BE 处的代码为 Singleton 对象从堆中分配内存，并将一个指向该块内存的指针存储到 eax 中。下一行代码，C3，获取 eax 中的指针并将其存储回内存位置为 049388C8 的实例引用。结果是，instance 现在为非 null 并引用一个有效的 Singleton 对象。然而，此对象的构造函数尚未运行，这恰是破坏双重检查锁定的情况。然后，在 C8 行处，instance 指针被解除引用并存储到 ecx。CA 和 D0 行表示内联的构造函数，该构造函数将值 true 和 5 存储到 Singleton 对象。如果此代码在执行 C3 行后且在完成该构造函数前被另一个线程中断，则双重检查锁定就会失败。

????? 不是所有的 JIT 编译器都生成如上代码。一些生成了代码，从而只在构造函数执行后使 instance 成为非 null。针对 Java 技术的 IBM SDK 1.3 版和 Sun JDK 1.3 都生成这样的代码。然而，这并不意味着应该在这些实例中使用双重检查锁定。该习语失败还有一些其他原因。此外，您并不总能知道代码会在哪些 JVM 上运行，而 JIT 编译器总是会发生变化，从而生成破坏此习语的代码。
??

class Singleton{ private Vector v; private boolean inUse; private static Singleton instance = new Singleton(); private Singleton() { v = new Vector(); inUse = true; //... } public static Singleton getInstance() { return instance; }}

????? 清单 10 的代码没有使用同步，并且确保调用 static getInstance() 方法时才创建 Singleton。如果您的目标是消除同步，则这将是一个很好的选择。

private String str;//...str = new String("hello");

??? String 类应该是不变的。尽管如此，鉴于我们之前讨论的无序写入问题，那会在这里导致问题吗？答案是肯定的。考虑两个线程访问 String str。一个线程能看见 str 引用一个 String 对象，在该对象中构造函数尚未运行。事实上，清单 11 包含展示这种情况发生的代码。注意，这个代码仅在我测试用的旧版 JVM 上会失败。IBM 1.3 和 Sun 1.3 JVM 都会如期生成不变的 String。

清单 11. 可变 String 的例子

class StringCreator extends Thread{  MutableString ms;  public StringCreator(MutableString muts)  {    ms = muts;  }  public void run()  {    while(true)      ms.str = new String("hello");          //1  }}class StringReader extends Thread{  MutableString ms;  public StringReader(MutableString muts)  {    ms = muts;  }  public void run()  {    while(true)    {      if (!(ms.str.equals("hello")))         //2      {        System.out.println("String is not immutable!");        break;      }    }  }}class MutableString{  public String str;                         //3  public static void main(String args[])  {    MutableString ms = new MutableString();  //4    new StringCreator(ms).start();           //5    new StringReader(ms).start();            //6  }}

????? 此代码在 //4 处创建一个 MutableString 类，它包含了一个 String 引用，此引用由 //3 处的两个线程共享。在行 //5 和 //6 处，在两个分开的线程上创建了两个对象 StringCreator 和 StringReader。传入一个 MutableString 对象的引用。StringCreator 类进入到一个无限循环中并且使用值“hello”在 //1 处创建 String 对象。StringReader 也进入到一个无限循环中，并且在 //2 处检查当前的 String 对象的值是不是 “hello”。如果不行，StringReader 线程打印出一条消息并停止。如果 String 类是不变的，则从此程序应当看不到任何输出。如果发生了无序写入问题，则使 StringReader 看到 str 引用的惟一方法绝不是值为“hello”的 String 对象。

在旧版的 JVM 如 Sun JDK 1.2.1 上运行此代码会导致无序写入问题。并因此导致一个非不变的 String。

结束语

????? 为避免单例中代价高昂的同步，程序员非常聪明地发明了双重检查锁定习语。不幸的是，鉴于当前的内存模型的原因，该习语尚未得到广泛使用，就明显成为了一种不安全的编程结构。重定义脆弱的内存模型这一领域的工作正在进行中。尽管如此，即使是在新提议的内存模型中，双重检查锁定也是无效的。对此问题最佳的解决方案是接受同步或者使用一个 static field。

热点排行

软件架构设计

双重检察锁定及单例模式【转】