java 双重检查锁失效_如何解决Java中的“双重检查锁定已损坏”声明？

今天药忘吃喽~ 2022-11-08 11:30 111阅读 0赞

![e375dea99d50627bfa6b050afa556be9.png][]

眼眸繁星

使用ThreadLocal的DCL作者：Brian Goetz @ JavaWorldDCL有什么问题？DCL依赖于资源字段的不同步使用。这似乎无害，但事实并非如此。要了解为什么，请想象线程A在同步块内部，执行语句resource = new Resource();。而线程B刚刚进入getResource()。考虑此初始化对内存的影响。新资源对象的内存将被分配；Resource的构造函数将被调用，初始化新对象的成员字段；并且SomeClass的字段资源将被分配一个对新创建对象的引用。class SomeClass \{  private Resource resource = null;  public Resource getResource() \{    if (resource == null) \{      synchronized \{        if (resource == null)           resource = new Resource();      \}    \}    return resource;  \}\}但是，由于线程B不在同步块内执行，因此它们看到这些内存操作的顺序可能与一个线程A的执行顺序不同。B可能会按照以下顺序看到这些事件(并且编译器还可以自由地重新排列这样的指令)：分配内存，分配对资源的引用，调用构造函数。假设线程B在分配了内存并设置了资源字段之后但在调用构造函数之前出现。它看到资源不为空，跳过同步块，并返回对部分构造的Resource的引用！不用说，结果既不是预期的也不是期望的。ThreadLocal可以帮助修复DCL吗？我们可以使用ThreadLocal来实现DCL习惯用法的明确目标-延迟初始化，而无需在公共代码路径上进行同步。考虑以下(线程安全)DCL版本：清单2.使用ThreadLocal的DCLclass ThreadLocalDCL \{  private static ThreadLocal initHolder = new ThreadLocal();  private static Resource resource = null;  public Resource getResource() \{    if (initHolder.get() == null) \{      synchronized \{        if (resource == null)           resource = new Resource();        initHolder.set(Boolean.TRUE);      \}    \}    return resource;  \}\}我认为; 这里每个线程将一次进入SYNC块以更新threadLocal值；那么它不会。因此，ThreadLocal DCL将确保线程仅在SYNC块内进入一次。同步到底是什么意思？Java将每个线程视为在其具有自己的本地内存的处理器上运行，每个线程都与共享的主内存通信并与之同步。即使在单处理器系统上，由于内存高速缓存的影响以及使用处理器寄存器存储变量的影响，该模型还是有意义的。当线程修改其本地内存中的位置时，该修改最终还将显示在主内存中，并且JMM定义了JVM必须何时在本地和主内存之间传输数据的规则。Java架构师意识到，过于严格的内存模型会严重破坏程序性能。他们试图设计一种内存模型，该内存模型将使程序在现代计算机硬件上运行良好，同时仍提供保证，以允许线程以可预测的方式进行交互。Java可预测地呈现线程之间的交互的主要工具是synced关键字。许多程序员在强制执行互斥信号量(mutex)时严格考虑同步，以防止一次由多个线程执行关键部分。不幸的是，这种直觉不能完全描述同步的含义。同步的语义确实的确包括基于信号量状态的相互排斥执行，但是它们还包括有关同步线程与主内存交互的规则。特别是，获取或释放锁会触发内存屏障，即线程的本地内存和主内存之间的强制同步。(某些处理器(例如Alpha)具有用于执行内存屏障的显式机器指令。)当线程退出同步块时，它将执行写屏障-在释放之前，必须将在该块中修改的所有变量清除到主内存中锁。同样，进入同步块时，它执行读取屏障操作-好像本地存储器已失效，并且它必须从主存储器中获取将在该块中引用的所有变量。

[e375dea99d50627bfa6b050afa556be9.png]: /images/20221023/bd5996c48dde4dfb8eb4b4bd7af5cdd0.png