据我所知，引用分配在64位JVM中是原子的。现在，我假设JVM在内部不使用原子指针来建模，因为否则就不需要原子引用了。所以我的问题是：Java/Scala的“规范”中的原子引用赋值是否保证会发生，或者它只是一个幸运的巧合，大多数时候都是这样？原子引用分配是否暗示了编译到JVM字节码的任何语言（例如，clojure、Groovy、JRuby、JPython......等）？如果不在内部使用原子指针，如何使引用赋值原子化？
yftpprvb1#
首先，引用分配是原子的，因为规范是这样规定的。除此之外，JVM实现者满足这个约束没有障碍，因为64位引用通常只在64位架构上使用，在那里原子64位分配是免费的。您的主要困惑来自于附加的“原子引用”特性的假设，由于它的名称，它就是这个意思。但是AtomicReference类提供了更多的功能，因为它封装了volatile引用，在多线程执行中具有更强的内存可见性保证。原子引用更新并不意味着阅读引用的线程也会看到通过该引用可到达的对象的 * 字段 * 的一致值。它所保证的是，您将读取null引用或对某个线程实际存储的现有对象的有效引用。如果您想要更多的保证，您需要像同步这样的结构。volatile指涉或AtomicReference。AtomicReference还提供了类似compareAndSet或getAndSet的 * 原子更新 * 操作。这些操作对于使用内置语言构造的普通引用变量是不可能的（但只有在特殊类如AtomicReferenceFieldUpdater或VarHandle中才有）。
AtomicReference
volatile
null
compareAndSet
getAndSet
AtomicReferenceFieldUpdater
VarHandle
kcrjzv8t2#
原子参考分配在规范中。对引用的写入和读取始终是原子的，无论它们是实现为32位值还是64位值。引自 *JSR-133：Java（TM）内存模型和线程规范 *，第12节 * double和long的非原子处理 *，http://www.cs.umd.edu/~pugh/java/memoryModel/jsr133.pdf。
double
long
e5nszbig3#
如other answer所述，Java内存模型声明读/写引用是原子的。当然，这是Java * 语言 * 内存模型。另一方面：无论我们谈论的是Java、Scala、Kotlin还是......最后所有内容都被编译成字节码。Java没有特殊的字节码指令，Scala最终使用的是完全相同的指令。导致：该内存模型的属性必须在VM平台内部实现。因此，它们 * 必须 * 也适用于在该平台上运行的其他语言。
3条答案
按热度按时间yftpprvb1#
首先，引用分配是原子的，因为规范是这样规定的。除此之外，JVM实现者满足这个约束没有障碍，因为64位引用通常只在64位架构上使用，在那里原子64位分配是免费的。
您的主要困惑来自于附加的“原子引用”特性的假设，由于它的名称，它就是这个意思。但是
AtomicReference类提供了更多的功能，因为它封装了volatile引用，在多线程执行中具有更强的内存可见性保证。原子引用更新并不意味着阅读引用的线程也会看到通过该引用可到达的对象的 * 字段 * 的一致值。它所保证的是，您将读取
null引用或对某个线程实际存储的现有对象的有效引用。如果您想要更多的保证，您需要像同步这样的结构。volatile指涉或AtomicReference。AtomicReference还提供了类似compareAndSet或getAndSet的 * 原子更新 * 操作。这些操作对于使用内置语言构造的普通引用变量是不可能的（但只有在特殊类如AtomicReferenceFieldUpdater或VarHandle中才有）。kcrjzv8t2#
原子参考分配在规范中。
对引用的写入和读取始终是原子的，无论它们是实现为32位值还是64位值。
引自 *JSR-133：Java（TM）内存模型和线程规范 *，第12节 *
double和long的非原子处理 *，http://www.cs.umd.edu/~pugh/java/memoryModel/jsr133.pdf。e5nszbig3#
如other answer所述，Java内存模型声明读/写引用是原子的。
当然，这是Java * 语言 * 内存模型。另一方面：无论我们谈论的是Java、Scala、Kotlin还是......最后所有内容都被编译成字节码。
Java没有特殊的字节码指令，Scala最终使用的是完全相同的指令。
导致：该内存模型的属性必须在VM平台内部实现。因此，它们 * 必须 * 也适用于在该平台上运行的其他语言。