blocks|key|1098818|text|JMM给出的保证是-如果线程1写入易失性变量，并且在线程2读取相同的易失性变量之后，则线程2的被保证在写入易失性变量(包括对非易失性变量所做的更改)之前查看线程1所做的所有更改()。这是一个强有力的保证，每个人都同意。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|1098819|但是，该保证仅适用于Thread+2看到的内容。您可能还有另一个线程Thread3，它可能看不到由Thread1设置的非易失性字段的最新值(线程3可能具有并被允许缓存这些非易失性字段的值)。只有在线程3读取相同的易失性后，才能保证看到来自线程1的非易失性写入|1098820|entityMap^0|1B|1Q|0|0|1X|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|P|8|@]|D|@]|E|$]]]|I|$]]

The guarantee that the JMM gives is - if Thread 1 writes a volatile variable and after that Thread 2 reads that same volatile variable, then Thread 2 is guaranteed to see all changes made by Thread 1 prior to writing the volatile variable (including changes made to non-volatile variables). This is a strong guarantee that exists and everyone agrees to.

However, the guarantee applies only to what Thread 2 sees. You may still have another thread, Thread 3, which may NOT see up-to-date values for the non-volatile fields set by Thread 1 (Thread 3 may have, and is allowed to, cache values for those non-volatile fields). Only after Thread 3 reads the same volatile is it guaranteed to see non-volatile writes from Thread 1

blocks|key|3322230|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3322231|在上面的例子中，我们写一个易失性变量，这会导致一个mfence，然后它会将所有挂起的存储缓冲区/加载缓冲区刷新到主缓存中...|blockquote|3322232|3322233|3322234|这是正确的。|3322235|正在使其他缓存线无效的|3322236|。|3322237|3322238|3322239|这是不正确的，或者至少是误导性的。使其它高速缓存线无效的不是写存储器屏障。它是在其他处理器中运行的读内存屏障，它使每个处理器的高速缓存线无效。内存同步是线程写入和从volatile变量读取的其他线程之间的协同操作。|offset|length|style|CODE|3322240|Java内存模型实际上保证了只有对写入的相同变量的读取才能保证更新该变量。实际情况是，在跨越写存储器屏障时，所有存储器高速缓存线都会被刷新，并且当跨越读存储器屏障时，所有存储器高速缓存线都会失效--而不管正在访问的变量是什么。|3322241|3322242|然而，非易失性字段可以被优化并存储在寄存器中，例如？那么，我们如何才能确保写入到易失性变量之前的所有状态更改都是可见的呢？如果我们改变1000件事呢？|3322243|3322244|3322245|根据this+documentation+(和其他人)的说法，内存屏障还会导致编译器生成刷新寄存器的代码。引述如下：|3322246|3322247|+...当使用barrier()时，编译器必须丢弃当前缓存在任何机器寄存器中的所有内存位置的值。|3322248|3322249|entityMap|0|LINK|mutability|MUTABLE|url|https://www.kernel.org/doc/Documentation/memory-barriers.txt^0|0|0|0|0|0|0|0|0|0|2A|8|0|0|0|0|0|0|2|I|0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|1E|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|1F|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|1G|7|@]|8|@]|9|$]]|$1|E|3|-4|4|5|6|1H|7|@]|8|@]|9|$]]|$1|F|3|G|4|5|6|1I|7|@]|8|@]|9|$]]|$1|H|3|I|4|5|6|1J|7|@]|8|@]|9|$]]|$1|J|3|K|4|C|6|1K|7|@]|8|@]|9|$]]|$1|L|3|-4|4|5|6|1L|7|@]|8|@]|9|$]]|$1|M|3|-4|4|5|6|1M|7|@]|8|@]|9|$]]|$1|N|3|O|4|5|6|1N|7|@$P|1O|Q|1P|R|S]]|8|@]|9|$]]|$1|T|3|U|4|5|6|1Q|7|@]|8|@]|9|$]]|$1|V|3|-4|4|5|6|1R|7|@]|8|@]|9|$]]|$1|W|3|X|4|C|6|1S|7|@]|8|@]|9|$]]|$1|Y|3|-4|4|5|6|1T|7|@]|8|@]|9|$]]|$1|Z|3|-4|4|5|6|1U|7|@]|8|@]|9|$]]|$1|10|3|11|4|5|6|1V|7|@]|8|@$P|1W|Q|1X|1|1Y]]|9|$]]|$1|12|3|-4|4|5|6|1Z|7|@]|8|@]|9|$]]|$1|13|3|14|4|C|6|20|7|@]|8|@]|9|$]]|$1|15|3|-4|4|5|6|21|7|@]|8|@]|9|$]]|$1|16|3|-4|4|5|6|22|7|@]|8|@]|9|$]]]|17|$18|$4|19|1A|1B|9|$1C|1D]]]]

<blockquote>
 In the above examples, we write to a volatile variable, which causes an mfence, which in turn flushes all pending store buffers/load buffers to main cache...
</blockquote>

This is correct.

<blockquote>
 invalidating other cache lines.
</blockquote>

This is not correct or at least is misleading. It is not the write memory-barrier which invalidates the other cache lines. It is the read memory-barrier running in the other processors which invalidates each processor's cache lines. Memory synchronization is cooperative action between the thread writing and the other threads reading from <code>volatile</code> variables.

The Java memory model actually guarantees that only a read of the same variable that was written to will the variable be guaranteed to be updated. The reality is that all memory cache lines are flushed upon a write memory barrier being crossed and all memory cache lines are invalidated when a read memory barrier is crossed – regardless of the variable being accessed.

<blockquote>
 However, the non-volatile fields could be optimized and be stored in registers for example? So how can we be sure that given a write to volatile variable ALL state changes prior to it will be visible? What if we change 1000 things?
</blockquote>

According to <a href="https://www.kernel.org/doc/Documentation/memory-barriers.txt" rel="nofollow noreferrer">this documentation</a> (and others), memory barriers also cause the compiler to generate code that flushes registers as well. To quote:

<blockquote>
 ... while with barrier() the compiler must discard the value of all memory locations that it has currently cached in any machine registers.
</blockquote>

blocks|key|1005816|text|编译器负责确保内存模型的语义被保留。在您的示例中，编译器将确保在易失性写入之前将任何跨线程可见的值写入内存(在x86上，普通存储就足以达到此目的)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1005817|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

The compiler is responsible for ensuring the semantics of the memory model are preserved. In your example, the compiler would ensure that any cross-thread visible values are written to memory prior to the volatile write (on x86 a plain store is sufficient for this purpose).

blocks|key|4790456|text|易失性变量共享synchronized的可见性特性，但没有原子性特性。这意味着线程将自动看到易失性变量的最新值。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4790457|只有在有限的情况下，才能使用易失性变量而不是锁。对于易失性变量，必须同时满足以下两个条件才能提供所需的线程安全性：|4790458|对变量的写入不依赖于它的当前值。|4790459|该变量不会与其他变量一起参与不变量。|4790460|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

Volatile variables share the visibility features of synchronized, but none of the atomicity features. This means that threads will automatically see the most up-to-date value for volatile variables.

You can use volatile variables instead of locks only under a restricted set of circumstances. Both of the following criteria must be met for volatile variables to provide the desired thread-safety:

Writes to the variable do not depend on its current value.

The variable does not participate in invariant with other variables.

After reading <a href="https://stackoverflow.com/questions/17108541/happens-before-relationships-with-volatile-fields-and-synchronized-blocks-in-jav">this question</a> and <a href="https://stackoverflow.com/questions/33472242/volatile-variable-and-non-volatile-reordering-visibility">this</a> (especially second answer) I am massively confused about volatile and its semantics with respect to memory barriers.

In the above examples, we write to a volatile variable, which causes an mfence, which in turn flushes all pending store buffers/load buffers to main cache, invalidating other cache lines.

However, the non-volatile fields could be optimized and be stored in registers for example? So how can we be sure that given a write to volatile variable ALL state changes prior to it will be visible? What if we cahnge 1000 things?

Volatile read and non-volatile fields

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

在阅读了和 (特别是第二个答案)之后，我对易失性及其在内存屏障方面的语义感到非常困惑。在上面的例子中，我们写入一个易失性变量，这会导致一个mfence，它会依次将所有挂起的存储缓冲区/加载缓冲区刷新到主缓存，从而使其他缓存线无效。然而，非易失性字段可以被优化并存储在寄存器中，例如？那么，我们如何才能确保写入到易失性变量...

问易失性读取和非易失性字段
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问易失性读取和非易失性字段EN