在32位机器上的Java原子中的64位分配？ [英] Are 64 bit assignments in Java atomic on a 32 bit machine?

问题描述

如果我有这样的代码 -

If I have code like this -

long x;
x  = 0xFFFFFFFFL;

如果我在32位机器上运行这个代码，是原子的，还是有可能不同的线程读取x，可能得到一个不完整的/垃圾值？

If i run this code on a 32 bit machine is it guaranteed to be atomic or is it possible that a different thread reading x, might get an incomplete/garbage value?

推荐答案

简短摘要：

• 对于引用，读取/写入操作总是原子的（即使在64位实现中） / li>
  
• 对于 int ， char ， code>，，short ， boolean


• 对于 double 和 long ，如果它们 volatile ，则读取/写入总是原子



• For references, reads/writes are ALWAYS atomic (even in 64 bit implementations!)
• For int, char, byte, short, boolean, float, reads/writes are ALWAYS atomic
• For double and long, if they're volatile, reads/writes are ALWAYS atomic

因此只有读/写可能不是原子的异常：

Therefore there is only exception where reads/writes may not be atomic:

• 对于<$如果 声明为 volatile ，则 double 和 long code>，它们是
原子 。

• For double and long, if they're NOT declared volatile, they're NOT GUARANTEED to be atomic

读/写共享数据，您只需要 volatile 任何 double 或 long 。

So as far as atomicity of reading/writing shared data is concerned, you only need to make volatile any double or long. Everything else is already guaranteed to be atomic, regardless of how many bits are used in actual implementation.

以下是相关章节供您快速参考：

Here's the relevant section reproduced here for quick reference:




JLS 17.7 double 和 long

将64位 long 或 double 值上的单个写入操作分为对相邻32位值的两个写入操作。为了效率的缘故，这种行为是实现特定的; Java虚拟机可以以原子方式或两部分自由地执行对 long 和 double

JLS 17.7 Non-atomic Treatment of double and long

Some implementations may find it convenient to divide a single write action on a 64-bit long or double value into two write actions on adjacent 32 bit values. For efficiency's sake, this behavior is implementation specific; Java virtual machines are free to perform writes to long and double values atomically or in two parts.

出于Java编程语言内存模型的目的，单写一个非 - volatile long 或 double 值被视为两个单独的写入：每个32位一个。这可能导致线程看到来自一次写入的64位值的前32位和来自另一次写入的第二32位的情况。写入和读取 volatile long 和 double 值总是原子的。

For the purposes of the Java programming language memory model, a single write to a non-volatile long or double value is treated as two separate writes: one to each 32-bit half. This can result in a situation where a thread sees the first 32 bits of a 64 bit value from one write, and the second 32 bits from another write. Writes and reads of volatile long and double values are always atomic. Writes to and reads of references are always atomic, regardless of whether they are implemented as 32 or 64 bit values.

我们鼓励虚拟机实现者避免将其64位值分割开来，因此对引用的写入和读取总是原子性的，无论它们是实现为32位还是64位的值。在可能的情况。鼓励程序员将共享的64位值声明为 volatile 或正确同步其程序，以避免可能的并发症。

VM implementors are encouraged to avoid splitting their 64-bit values where possible. Programmers are encouraged to declare shared 64-bit values as volatile or synchronize their programs correctly to avoid possible complications.

另请参阅

• JLS 17.6 Word Tearing - guarantee eg byte 可以更新而不会产生邻居干扰。


• JLS 8.3.1.4 volatile 字段


• Java教程/基本类/并发/原子变量
  
  
  
  
  • 请注意，给定 int i; ， i ++ 是不是原子！
  
  

  See also

  • JLS 17.6 Word Tearing - guarantees e.g. a byte can be updated without neighbor interference
  • JLS 8.3.1.4 volatile Fields
  • Java Tutorials/Essential Classes/Concurrency/Atomic Variables
    • Note that given int i;, i++ is NOT atomic!
    
    
    • 使用volatile是否有任何意义？
    
    
    • 如何声明数组元素volatile in Java？
      
      
      
      
      • A volatile long [] 是 volatile 引用到 long
      的数组
      
      • long 元素本身不是 volatile
      
      
      • Is there any point in using a volatile long?
      • How to declare array elements volatile in Java?
        • A volatile long[] is volatile reference to an array of long
        • The long elements themselves are not volatile

        这篇关于在32位机器上的Java原子中的64位分配？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！