Java线程/内存模型的缺陷和增强 - 编程入门网
| 动态调整指令的执行次序，以更好的进行并行运算并且把运算结果与主内存同步。这样的代码次序调整也可能导致DCL失效。回想一下前面对Java内存模型的介绍，我们这里可以把Main Memory看作系统的物理内存，把Thread Working Memory认为是CPU内部的Cache和寄存器，没有synchronized的保护，Cache和寄存器的内容就不会及时和主内存的内容同步，从而导致一条线程无法看到另一条线程对一些变量的改动。
结合代码3来举例说明，假设Resource类的实现如下： Class Resource{ Object obj;} 即Resource类有一个obj成员变量引用了Object的一个实例。假设2条线程在运行，其状态用如下简化图表示：
图2 现在Thread-1构造了Resource实例，初始化过程中改动了obj的一些内容。退出同步代码段后，因为采取了同步机制，Thread-1所做的改动都会反映到主存中。接下来Thread-2获得了新的Resource实例变量res，由于没有使用synchronized保护所以Thread-2不会进行刷新工作内存的操作。假如之前Thread-2的工作内存中已经有了obj实例的一份拷贝，那么Thread-2在对obj执行use操作的时候就不会去执行load操作,这样一来就无法看到Thread-1对obj的改变，这显然会导致错误的运算结果。此外，Thread-1在退出同步代码段的时刻对ref和obj执行的写入主存的操作次序也是不确定的，所以即使Thread-2对obj执行了load操作，也有可能只读到obj的初试状态的数据。(注：这里的load/use均指JMM定义的操作) 有很多人不死心，试图想出了很多精妙的办法来解决这个问题，但最终都失败了。事实上，无论是目前的JMM还是已经作为JSR提交的JMM模型的增强，DCL都不能正常使用。在William Pugh的论文《Fixing the Java Memory Model》中详细的探讨了JMM的一些硬伤，更尝试给出一个新的内存模型，有兴趣深入研究的读者可以参见文后的参考资料。 如果你设计的对象在程序中只有一个实例，即singleton的，有一种可行的解决办法来实现其LazyLoad：就是利用类加载器的LazyLoad特性。代码如下： Class ResSingleton {public static Resource res = new Resource();}
这里ResSingleton只有一个静态成员变量。当第一次使用ResSingleton.res的时候，JVM才会初始化一个Resource实例，并且JVM会保证初始化的结果及时写入主存，能让其他线程看到，这样就成功的实现了LazyLoad。 除了这个办法以外，还可以使用ThreadLocal来实现DCL的方法，但是由于ThreadLocal的实现效率比较低，所以这种解决办法会有较大的性能损失，有兴趣的读者可以参考文后的参考资料。 最后要说明的是，对于DCL是否有效，个人认为更多的是一种带有学究气的推断和讨论。而从纯理论的角度来看，存取任何可能共享的变量（对象引用）都需要同步保护，否则都有可能出错，但是处处用synchronized又会增加死锁的发生几率，苦命的程序员怎么来解决这个矛盾呢？事实上，在很多Java开源项目（比如Ofbiz/Jive等）的代码中都能找到使用DCL的证据，我在具体的实践中也没有碰到过因DCL而发生的程序异常。个人的偏好是：不妨先大胆使用DCL，等出现问题再用synchronized逐步排除之。也许有人偏于保守，认为稳定压倒一切，那就不妨先用synchronized同步起来，我想这是一个见仁见智的问题，而且得针对具体的项目具体分析后才能决定。还有一个办法就是写一个测试案例来测试一下系统是否存在DCL现象，附带的光盘中提供了这样一个例子，感兴趣的读者可以自行编译测试。不管结果怎样，这样的讨论有助于我们更好的认识JMM，养成用多线程的思路去分析问题的习惯，提高我们的程序设计能力。 Java线程/内存模型的缺陷和增强(4)时间:2007-11-05三、Java线程同步增强包 相信你已经了解了Java用于同步的3板斧：synchronized/wait/notify，它 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
