问题标签 [volatile]

我什么时候应该使用 volatile/Thread.MemoryBarrier() 来保证线程安全？

假设我有以下代码

标记为 volatile 的已修改字段，其值不依赖于先前的状态。所以，这是正确的多线程代码（暂时不要为Service实现而烦恼）。

据我所知，从内存可见性的角度来看，读取 volatile 变量就像进入锁一样。这是因为普通变量的读取不能通过读取 volatile 变量重新排序。

这是否意味着以下代码是正确的？

我目前有这个代码：

有没有办法避免函数调用中的强制转换？

我的问题是关于使用 ReentrantLock 是否能保证字段的可见性与 synchronized 关键字提供的相同。

例如，在下面的类A中，字段sharedData不需要声明为 volatile，因为使用了 synchronized 关键字。

然而，对于下一个使用 ReentrantLock 的示例，字段上的 volatile 关键字是否必要？

我知道无论如何使用 volatile 关键字只会对性能造成很小的影响，但我仍然想正确编码。

我正在阅读 Joe Duffy 的关于Volatile 读写和及时性的帖子，并且我试图了解有关帖子中最后一个代码示例的一些信息：

当执行第二个 CMPXCHG 操作时，它是否使用内存屏障来确保 m_state 的值确实是写入它的最新值？还是只使用已经存储在处理器缓存中的一些值？（假设m_state未声明为 volatile）。
如果我理解正确，如果 CMPXCHG 不使用内存屏障，那么整个锁获取过程将不公平，因为第一个获取锁的线程很可能是获取所有锁的线程以下锁。我是否理解正确，或者我在这里错过了什么？

编辑：主要问题实际上是在尝试读取 m_state 的值之前调用 CompareExchange 是否会导致内存障碍。因此，当他们再次尝试调用 CompareExchange 时，是否所有线程都可以看到分配 0。

我有一个多 R/W 锁类，它保持读、写和挂起的读、挂起的写计数器。互斥体保护它们免受多个线程的影响。

我的问题是我们是否仍然需要将计数器声明为 volatile 以便编译器在进行优化时不会搞砸它。

或者编译器是否考虑到计数器由互斥锁保护。

我知道互斥锁是一种用于同步的运行时机制，而“volatile”关键字是编译时指示编译器在进行优化时做正确的事情。

问候，-杰。

阅读一些线程（常见并发问题、易失关键字、内存模型）我对 Java 中的并发问题感到困惑。

我有很多由多个线程访问的字段。我应该检查它们并将它们都标记为易失性吗？

在构建一个类时，我不知道是否有多个线程会访问它，所以让任何字段不可变肯定是不安全的，所以根据我的理解，你不会使用它的情况很少。它是否正确？

对我来说，这是特定于 1.5 版 JVM 及更高版本的，但不限于回答我的具体设置。

程序存储器中存储的易失性变量在哪里（在哪个部分）？

换句话说，我可以用普通变量和 Interlocked 类无法解决的 volatile 变量做一些事情吗？

假设我有一个由 100 个字节组成的结构。我对以下代码有什么保证？

内存模型是否保证放置内存屏障后 100 字节的复制将完成？还是内存屏障仅适用于处理器架构大小的类型？（32 位为 4 个字节，64 位为 8 个字节）。
这就是volatile关键字仅适用于原始类型的原因吗？（如果我将一个 8 字节的成员声明为 volatile，这意味着将使用互锁的 instrinct 来更改它的值？[因为在 32 位机器上不能保证大于 4 字节的类型的原子性]）。

我希望我足够清楚.. :)
谢谢