如何用JAVA语言分析双重检查锁定

这篇文章跟大家分析一下“如何用JAVA语言分析双重检查锁定”。内容详细易懂，对“如何用JAVA语言分析双重检查锁定”感兴趣的朋友可以跟着小编的思路慢慢深入来阅读一下，希望阅读后能够对大家有所帮助。下面跟着小编一起深入学习“如何用JAVA语言分析双重检查锁定”的知识吧。在程序开发中，有时需要推迟一些高开销的对象初始化操作，并且只有在使用这些对象时才进行初始化，此时可以采用双重检查锁定来延迟对象初始化操作。双重检查锁定是设计用来减少并发系统中竞争和同步开销的一种软件设计模式，在普通单例模式的基础上，先判断对象是否已经被初始化，再决定要不要加锁。尽管双重检查锁定解决了普通单例模式的在多线程环境中易出错和线程不安全的问题，但仍然存在一些隐患。下面以JAVA语言源代码为例，分析双重检查锁定缺陷产生的原因以及修复方法。双重检查锁定在单线程环境中并无影响，在多线程环境下，由于线程随时会相互切换执行，在指令重排的情况下，对象未实例化完全，导致程序调用出错。示例源于Samate Juliet Test Suite for Java v1.3 (https://samate.nist.gov/SARD/testsuite.php)，源文件名：CWE609_Double_Checked_Locking__Servlet_01.java。上述代码行23行-38行，程序先判断 stringBad 是否为 null，如果不是则直接返回该 String 对象，这样避免了进入 synchronized 块所需要花费的资源。当 stringBad 为 null 时，使用 synchronized 关键字在多线程环境中避免多次创建 String 对象。在代码实际运行时，以上代码仍然可能发生错误。对于第33行，创建 stringBad 对象和赋值操作是分两步执行的。但 JVM 不保证这两个操作的先后顺序。当指令重排序后，JVM 会先赋值指向了内存地址，然后再初始化 stringBad 对象。如果此时存在两个线程，两个线程同时进入了第27行。线程1首先进入了 synchronized 块，由于 stringBad 为 null，所以它执行了第33行。当 JVM 对指令进行了重排序，JVM 先分配了实例的空白内存，并赋值给 stringBad，但这时 stringBad 对象还未实例化，然后线程1离开了 synchronized 块。当线程2进入 synchronized 块时，由于 stringBad 此时不是 null ,直接返回了未被实例化的对象（仅有内存地址值，对象实际未初始化）。后续线程2调用程序对 stringBad 对象进行操作时，此时的对象未被初始化，于是错误发生。使用360代码卫士对上述示例代码进行检测，可以检出“双重检查锁定”缺陷，显示等级为中。在代码行第27行报出缺陷，如图1所示：
图1：“双重检查锁定”的检测示例使用360代码卫士对修复后的代码进行检测，可以看到已不存在“双重检查锁定”缺免费云主机域名陷。如图2：
要避免双重检查锁定，需要注意以下几点：（1）使用 volatile关键字避免指令重排序，但这个解决方案需要 JDK5 或更高版本，因为从JDK5 开始使用新的 JSR-133 内存模型规范，这个规范增强了 volatile的语义。（2）基于类初始化的解决方案。JVM在类的初始化阶段（即在Class被加载后，且被线程使用之前），会执行类的初始化。在执行类的初始化期间，JVM会去获取一个锁。这个锁可以同步多个线程对同一个类的初始化。
关于如何用JAVA语言分析双重检查锁定就分享到这里啦，希望上述内容能够让大家有所提升。如果想要学习更多知识，请大家多多留意小编的更新。谢谢大家关注一下云编程开发博客网站！

相关推荐: 数据防泄密行业标准

在数据泄露年代，数据防泄密产品被受宠爱。然而，面对形态各异的功能以及眼花缭乱的名称（数据防泄密、数据防泄露、数据防泄漏等等），让人感到迷茫，已无从判断与选择；那么问题来了，这些令人耳目一新的产品在本质上到底是什么？是否有行业标准？答案是肯定的，这些产品实质上都…