用happen-before守则重新审视DCL

用happen-before规则重新审视DCL

转载自 ---- http://lifethinker.iteye.com/blog/260515

?

????? 编写Java多线程程序一直以来都是一件十分困难的事，多线程程序的bug很难测试，DCL(Double Check Lock)就是一个典型，因此对多线程安全的理论分析就显得十分重要，当然这决不是说对多线程程序的测试就是不必要的。传统上，对多线程程序的分析是通过分析操作之间可能的执行先后顺序，然而程序执行顺序十分复杂，它与硬件系统架构，编译器，缓存以及虚拟机的实现都有着很大的关系。仅仅为了分析多线程程序就需要了解这么多底层知识确实不值得，况且当年选择学Java就是因为不用理会烦人的硬件和操作系统，这导致了许多Java程序员不愿也不能从理论上分析多线程程序的正确性。虽然99%的Java程序员都知道DCL不对，但是如果让他们回答一些问题，DCL为什么不对？有什么修正方法？这个修正方法是正确的吗？如果不正确，为什么不正确？对于此类问题，他们一脸茫然，或者回答也许吧，或者很自信但其实并没有抓住根本。

?

幸好现在还有另一条路可走，我们只需要利用几个基本的happen-before规则就能从理论上分析Java多线程程序的正确性，而且不需要涉及到硬件和编译器的知识。接下来的部分，我会首先说明一下happen-before规则，然后使用happen-before规则来分析DCL，最后我以我自己的例子来说明DCL的问题其实很常见，只是因为对DCL的过度关注反而忽略其问题本身，当然其忽略是有原因的，因为很多人并不知道DCL的问题到底出在哪里。

?

?

Ｈappen-Before规则

?

我们一般说一个操作happen-before另一个操作，这到底是什么意思呢？当说操作A happen-before操作B时，我们其实是在说在发生操作B之前，操作A对内存施加的影响能够被观测到。所谓“对内存施加的影响”就是指对变量的写入，“被观测到”指当读取这个变量时能够得到刚才写入的值（如果中间没有发生其它的写入）。听起来很绕口？这就对了，请你保持耐心，举个例子来说明一下。线程Ⅰ执行了操作A：x=3，线程Ⅱ执行了操作Ｂ：y=x。如果操作Ａhappen-before操作B，线程Ⅱ在执行操作B之前就确定操作"x=3"被执行了，它能够确定，是因为如果这两个操作之间没有任何对x的写入的话，它读取x的值将得到3，这意味着线程Ⅱ执行操作B会写入y的值为3。如果两个操作之间还有对x的写入会怎样呢？假设线程Ⅲ在操作A和B之间执行了操作C: x=5，并且操作C和操作B之前并没有happen-before关系(后面我会说明时间上的先后并不一定导致happen-before关系)。这时线程Ⅱ执行操作B会讲到x的什么值呢？3还是5?答案是两者皆有可能，这是因为happen-before关系保证一定能够观测到前一个操作施加的内存影响，只有时间上的先后关系而并没有happen-before关系可能但并不保证能观测前一个操作施加的内存影响。如果读到了值3，我们就说读到了“陈旧”的数据。正是多种可能性导致了多线程的不确定性和复杂性，但是要分析多线程的安全性，我们只能分析确定性部分，这就要求找出happen-before关系，这又得利用happen-before规则。

?

下面是我列出的三条非常重要的happen-before规则，利用它们可以确定两个操作之间是否存在happen-before关系。

同一个线程中，书写在前面的操作happen-before书写在后面的操作。这条规则是说，在单线程中操作间happen-before关系完全是由源代码的顺序决定的，这里的前提“在同一个线程中”是很重要的，这条规则也称为单线程规则。这个规则多少说得有些简单了，考虑到控制结构和循环结构，书写在后面的操作可能happen-before书写在前面的操作，不过我想读者应该明白我的意思。对锁的unlock操作happen-before后续的对同一个锁的lock操作。这里的“后续”指的是时间上的先后关系，unlock操作发生在退出同步块之后，lock操作发生在进入同步块之前。这是条最关键性的规则，线程安全性主要依赖于这条规则。但是仅仅是这条规则仍然不起任何作用，它必须和下面这条规则联合起来使用才显得意义重大。这里关键条件是必须对“同一个锁”的lock和unlock。如果操作A happen-before操作B，操作B happen-before操作C，那么操作A happen-before操作C。这条规则也称为传递规则。

?

现在暂时放下happen-before规则，先探讨一下“一个操作在时间上先于另一个操作发生”和“一个操作happen-before另一个操作之间”的关系。两者有关联却并不相同。关联部分在第2条happen-before规则中已经谈到了，通常我们得假定一个时间上的先后顺序然后据此得出happen-before关系。不同部分体现在，首先，一个操作在时间上先于另一个操作发生，并不意味着一个操作happen-before另一个操作。看下面的例子：

private?Map?selectSqls?=?Collections.synchronizedMap(new?HashMap())?????public?Map?executeSelect(final?TableConfig?tableConfig,?Map?keys)??{??????PreparedSql?psql?=?null;??????synchronized(selectSqls)?{??????????if?(selectSqls.get(tableConfig.getId())?==?null)?{??????????????selectSqls.put(tableConfig.getId(),?constructSelectSql(tableConfig));??????????}??????????psql?=?(PreparedSql)?selectSqls.get(tableConfig.getId());??????}????????List?result?=?executeSql(...);??????????????????return?result.isEmpty()???null?:?(Map)?result.get(0);?????}??

我对selectSqls使用了同步Map，如果它只被这个方法使用，这就不是必须的。作为一种防范措施，虽然这会稍微降低性能，即便当它被其它方法使用了也能够保护它的内部结构不被破坏。并且由于Map的内部锁是非竞争性锁，根据官方说法，这对性能影响很小，可以忽略不计。这里我有意无意地提到了编写高性能的两个原则，尽量减少同步块的作用域，以及使用细粒度的锁，关于细粒度锁的最经典例子莫过于读写锁了。这两个原则要慎用，除非你能保证你的程序是正确的。

?

?

结束语

?

在这篇文章中我主要讲到happen-before规则，并运用它来分析DCL问题，最后我用例子来说明DCL问题并不只是理论上的讨论，在实际程序中其实很常见。我希望读者能够明白用happen-before规则比使用时间的先后顺序来分析线程安全性要有效得多，作为对比，你可以看看这篇经典的文章中是如何分析DCL的线程安全性的。它是否讲明白了呢？如果它讲明白了，你是否又能理解？我想答案很可能是否定的，不然的话就不会出现这么多对DCL的误解了。当然我也并不是说要用happen-before规则来分析所有程序的线程安全性，如果你试着分析几个程序就会发现这是件很困难的事，因为这个规则实在是太底层了，要想更高效的分析程序的线程安全性，还得总结和利用了一些高层的经验规则。关于这些经验规则，我在文中也谈到了一些，很零碎也不完全。