问题标签 [double-checked-locking]

如果一个线程看到另一个线程写入的指针，它可能看不到新创建的 some_resource 实例，从而导致对 do_something() 的调用对不正确的值进行操作。这是 C++ 标准定义为数据竞争的竞争条件类型的示例，因此被指定为未定义的行为。

问题> 我已经看到上述解释为什么代码有导致竞争条件的双重检查锁定问题。但是，我仍然难以理解问题所在。也许一个具体的双线程分步工作流程可以帮助我真正理解上述代码的竞争问题。

书中提到的解决方案之一如下：

欢迎任何评论 - 谢谢

我在 java 中看到了一些示例，它们在代码块上进行同步以更改某些变量，而该变量最初被声明为 volatile .. 我在单例类的示例中看到了，他们将唯一实例声明为 volatile 并同步了该块初始化那个实例......我的问题是为什么我们在同步它时声明它是易失的，为什么我们需要同时做这两个？是不是其中一个对另一个就足够了？

提前致谢。

Java内存模型中提到：当线程退出同步块作为释放关联监视器的一部分时，JMM要求将本地处理器缓存刷新到主内存。同样，作为在进入同步块时获取监视器的一部分，本地缓存无效，以便后续读取将直接进入主内存而不是本地缓存。

那么为什么在该代码中我必须将实例声明为易失性，因为当第二个线程进入同步块时将直接进入主内存？

我的意思是当另一个线程进入同步块并进行第二次检查时，它应该如上所述从主内存更新。

休闲条款取自 jetbrains.net 在阅读了这篇文章和网络上的其他一些文章后，我仍然不明白在第一个线程进入锁之后如何返回 null。有人理解它可以请帮助我并以更人性化的方式解释它吗？

“考虑以下代码：

鉴于上述代码，初始化 Foo 实例的写入可能会延迟到实例值的写入，从而产生实例返回处于未初始化状态的对象的可能性。

为了避免这种情况，必须将实例值设为易失性。"

我使用 java 大约一个月了，并且通常仍然是编程的业余爱好者，所以如果我有错误，请随时纠正我。也许我会提供一些多余的细节，但我现在很困惑，我无法决定什么是重要的。

所以，我一直在开发多线程客户端-服务器应用程序。所有线程都使用同一个对象，其中存储了某些配置值和共享记录器；此对象在服务器线程中初始化，然后作为参数传递给客户端线程类构造函数。首先假设该对象的字段仅在服务器启动时更改一次，因此无需担心并发访问，但是现在需要在修改配置文件时从配置文件中重新读取某些配置值，而不必重新启动服务器。

经过一些研究后想到的第一个想法是创建一个同步方法，当请求类中的某些值时将调用该方法，如果自上次访问以来我们的配置文件发生更改，它将重新读取这些值，否则立即返回，例如这个：

（上面的代码没有经过测试，我只是想大致了解一下）。

但是我只是不喜欢每次请求值时都阻塞的想法，因为这看起来很昂贵，而且我的应用程序将来可能会变得非常高负载，并且有很多线程。所以我有一个“好”的想法——在锁定之前检查文件是否被修改，然后再次在锁定的方法中，尽可能避免锁定：

十分钟后，我了解到它被称为双重检查锁定，再过十分钟后，我的世界在阅读了这篇文章后两次崩溃：第一次是我了解到它可能由于内部 CPU 缓存而无法工作，第二次是我读到关于 long 的操作/float 类型不是原子的。或者它毕竟会工作，因为不涉及对象创建？而且，由于 long 上的操作是非原子的，将“lastModified”声明为 volatile 真的就足够了吗？如果可能的话，我希望能正确解释它为什么会/不会起作用。先感谢您。

PS：我知道类似的问题已经回答了几次，也许最好停止吹毛求疵并同步整个“getValue”方法而不是“ReReadConfig”，但我正在努力学习更多关于线程安全编程和在我自己的代码中查看陷阱，以避免将来出现类似的情况。我也为任何可能的语法和拼写错误道歉，我不太懂英语。

编辑：首先，我修正了最后一个“if”子句中的错字。第二 - 警告，上面的代码不是线程安全的，不要使用它！在方法

如果文件在 if-check 和返回值之间的时间跨度内更新，线程 B 可以在线程 A 开始返回值之前启动 ReReadConfig，从而导致对必要数据的危险部分更改。似乎在不过度阻塞的情况下做我需要的正确方法是使用 ReentrantReadWriteLock，但是，我仍然想使用双重检查来避免过度（并且昂贵，文件被假定为大型 XML）配置重新读取：

现在它至少看起来是线程安全的，但是在检查时取决于易失性“lastModified”变量的问题仍然存在：我在某处读到易失性变量不能保证非原子操作的任何内容，以及“长”类型读取/写入是非原子的。

在针对双重检查锁定场景的乱序写入提到的示例中（参考： IBM 文章和Wikipedia 文章）

我无法理解为什么在构造函数完全初始化之前 Thread1 会出现同步块的简单原因。根据我的理解，创建“new”和调用构造函数应该按顺序执行，并且在所有工作未完成之前不应释放同步锁。

请让我知道我在这里缺少什么。

在使用双锁方法进行同步的单例中，为什么将单个实例声明为 volatile ？我可以在不将其声明为 volatile 的情况下实现相同的功能吗？

我已经阅读了不同的文章，例如Double-checked locking: Clever, but broken并且我理解以下代码在多线程使用中被破坏的原因。

然而，根据它的解释，当一个线程退出一个同步块时，它会执行一个写屏障——它必须在释放锁之前将该块中修改的所有变量刷新到主内存。因此，当线程 A 运行到同步块时，然后依次执行以下过程：

1. 将为新的 Resource 对象分配内存；
2. 将调用 Resource 的构造函数，
3. 初始化新对象的成员字段；
4. SomeClass 的字段资源将被分配对新创建对象的引用

最后，在线程 A 退出同步块之前，它会将其本地资源对象写回主存，然后线程 B 将在运行到同步块时从主内存中读取这个新创建的资源。

为什么线程 B 看到这些内存操作的顺序可能与线程 A 执行的顺序不同？我认为线程 B 不会知道资源对象已创建，直到线程 A 从同步块退出时将其本地内存刷新到主内存，因为线程 B 只能从可共享的主内存中读取资源对象？

请纠正我的理解......谢谢。

原始双重检查锁定模式的问题已得到充分证明：C++ 和双重检查锁定的风险。我经常看到这个话题出现在关于 SO 的问题中。

我想出了一个版本，在我看来，它似乎解决了原始模式的竞争条件问题，但你觉得还可以吗？

在下面的代码中，我假设 LOCK 是正确实现的互斥锁类型，它会在锁定/解锁时导致内存屏障，并且我不会尝试处理实例的释放，因为这不是模式的一部分。

我知道做单例的其他可能方法，但这不是我要的。我特别询问模式 - 是否通过在互斥锁之外进行分配来解决竞争条件？

我已经阅读了许多考虑线程安全双重检查锁定的问题（对于单例或惰性初始化）。在某些线程中，答案是模式完全被破坏，其他人提出了解决方案。

所以我的问题是：有没有办法在 C++ 中编写一个完全线程安全的双重检查锁定模式？如果是这样，它看起来如何。

如果这使事情变得更容易，我们可以假设 C++11。据我所知，C++11 改进了可以产生所需改进的内存模型。

我确实知道在 Java 中可以通过使仔细检查保护变量 volatile 来实现。由于 C++11 从 Java 中借用了大部分内存模型，所以我认为这是可能的，但是如何呢？