Java并发编程（三）并发三大特性-可见性

2020年1月15日 · 3290 字 · 7 分钟 · 可见性并发

可见性

当一个线程修改了共享变量的值，其他线程能够看到修改的值。Java 内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方法来实现可见性的。

如何保证可见性

通过 volatile 关键字保证可见性。
通过 内存屏障保证可见性。
通过 synchronized 关键字保证可见性。
通过 Lock保证可见性。
通过 final 关键字保证可见性

可见性问题深入分析


/**
 * -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -Xcomp
 */
public class VisibilityTest {
    private boolean flag = true;

    public void refresh() {
        flag = false;
        System.out.println(Thread.currentThread().getName() + "修改flag");
    }

    public void load() {
        System.out.println(Thread.currentThread().getName() + "开始执行.....");
        int i = 0;
        while (flag) {
            i++;
            //TODO  业务逻辑

        }
        System.out.println(Thread.currentThread().getName() + "跳出循环: i=" + i);
    }

    public static void main(String[] args) throws InterruptedException {
        VisibilityTest test = new VisibilityTest();

        // 线程threadA模拟数据加载场景
        Thread threadA = new Thread(test::load, "threadA");
        threadA.start();

        // 让threadA执行一会儿
        Thread.sleep(1000);
        // 线程threadB通过flag控制threadA的执行时间
        Thread threadB = new Thread(test::refresh, "threadB");
        threadB.start();

    }

    public static void shortWait(long interval) {
        long start = System.nanoTime();
        long end;
        do {
            end = System.nanoTime();
        } while (start + interval >= end);
    }
}

上面的例子存在可见性问题！

JMM的内存可见性保证

什么时候刷主内存，线程执行结束刷回主内存吗？还是一旦更新完之后就立马刷主内存？本地内存什么时候会没有？

按程序类型，Java程序的内存可见性保证可以分为下列3类：

单线程程序。单线程程序不会出现内存可见性问题。编译器、runtime和处理器会共同确保单线程程序的执行结果与该程序在顺序一致性模型中的执行结果相同。
正确同步的多线程程序。正确同步的多线程程序的执行将具有顺序一致性（程序的执行结果与该程序在顺序一致性内存模型中的执行结果相同）。这是JMM关注的重点，JMM通过限制编译器和处理器的重排序来为程序员提供内存可见性保证。
未同步/未正确同步的多线程程序。JMM为它们提供了最小安全性保障：线程执行时读取到的值，要么是之前某个线程写入的值，要么是默认值。
- 未同步程序在JMM中执行时，整体上是无序的，其执行结果无法预知。
- JMM不保证未同步程序的执行结果与该程序在顺序一致性模型中的执行结果一致。

未同步程序在两个模型中的执行特性有如下几个差异

顺序一致性模型保证单线程内的操作会按程序的顺序执行，而JMM不保证单线程内的操作会按程序的顺序执行，比如正确同步的多线程程序在临界区内的重排序。
顺序一致性模型保证所有线程只能看到一致的操作执行顺序，而JMM不保证所有线程能看到一致的操作执行顺序。
顺序一致性模型保证对所有的内存读/写操作都具有原子性，而JMM不保证对64位的long型和double型变量的写操作具有原子性（32位处理器）。

volatile

volatile的特性

可见性：对一个volatile变量的读，总是能看到（任意线程）对这个volatile变量最后的写入。
原子性：对任意单个volatile变量的读/写具有原子性，但类似于volatile++这种复合操作不具有原子性（基于这点，我们通过会认为volatile不具备原子性）。volatile仅仅保证对单个volatile变量的读/写具有原子性，而锁的互斥执行的特性可以确保对整个临界区代码的执行具有原子性。

64位的long型和double型变量，只要它是volatile变量，对该变量的读/写就具有原子性。

有序性：对volatile修饰的变量的读写操作**前后加上各种特定的内存屏障来禁止指令重排序**来保障有序性。

在JSR-133之前的旧Java内存模型中，虽然不允许volatile变量之间重排序，但旧的Java内存模型允许volatile变量与普通变量重排序。为了提供一种比锁更轻量级的线程之间通信的机制，JSR-133专家组决定增强volatile的内存语义：

严格限制编译器和处理器对volatile变量与普通变量的重排序，确保volatile的写-读和锁的释放-获取具有相同的内存语义。

volatile写-读的内存语义

当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量值刷新到主内存。
当读一个volatile变量时，JMM会把该线程对应的本地内存置为无效，线程接下来将从主内存中读取共享变量。

volatile可见性实现原理

JMM内存交互层面实现

volatile修饰的变量的read、load、use操作和assign、store、write必须是连续的，即修改后必须立即同步回主内存，使用时必须从主内存刷新，由此保证volatile变量操作对多线程的可见性。

硬件层面实现

通过lock前缀指令，会锁定变量缓存行区域并写回主内存，这个操作称为“缓存锁定”，缓存一致性机制会阻止同时修改被两个以上处理器缓存的内存区域数据。一个处理器的缓存回写到内存会导致其他处理器的缓存无效。

volatile在hotspot的实现

字节码解释器实现

JVM中的字节码解释器(bytecodeInterpreter)，用C++实现了JVM指令。

src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp文件：

if (cache->is_volatile()) {
    switch (tos_type) {
      case ztos:
        obj->release_byte_field_put(field_offset, (STACK_INT(-1) & 1)); // only store LSB
        break;
      case btos:
        obj->release_byte_field_put(field_offset, STACK_INT(-1));
        break;
      case ctos:
        obj->release_char_field_put(field_offset, STACK_INT(-1));
        break;
      case stos:
        obj->release_short_field_put(field_offset, STACK_INT(-1));
        break;
      case itos:
        obj->release_int_field_put(field_offset, STACK_INT(-1));
        break;
      case ftos:
        obj->release_float_field_put(field_offset, STACK_FLOAT(-1));
        break;
      case ltos:
        obj->release_long_field_put(field_offset, STACK_LONG(-1));
        break;
      case dtos:
        obj->release_double_field_put(field_offset, STACK_DOUBLE(-1));
        break;
      case atos: {
        oop val = STACK_OBJECT(-1);
        VERIFY_OOP(val);
        obj->release_obj_field_put(field_offset, val);
        break;
      }
      default:
        ShouldNotReachHere();
    }
    OrderAccess::storeload();
  }

模板解释器实现

模板解释器(templateInterpreter)，其对每个指令都写了一段对应的汇编代码，启动时将每个指令与对应汇编代码入口绑定，可以说是效率做到了极致。

src/hotspot/os_cpu 包含了不同cpu的方法实现

src/hotspot/cpu/x86/templateTable_x86.cpp

void TemplateTable::volatile_barrier(Assembler::Membar_mask_bits
                                     order_constraint) {
  // Helper function to insert a is-volatile test and memory barrier
  if (os::is_MP()) { // Not needed on single CPU
    __ membar(order_constraint);
  }
}

// 负责执行putfield或putstatic指令
void TemplateTable::putfield_or_static(int byte_no, bool is_static, RewriteControl rc) {
	// ...
	 // Check for volatile store
    __ testl(rdx, rdx);
    __ jcc(Assembler::zero, notVolatile);

    putfield_or_static_helper(byte_no, is_static, rc, obj, off, flags);
    volatile_barrier(Assembler::Membar_mask_bits(Assembler::StoreLoad |
                                                 Assembler::StoreStore));
    __ jmp(Done);
    __ bind(notVolatile);

    putfield_or_static_helper(byte_no, is_static, rc, obj, off, flags);

    __ bind(Done);
 }

src/hotspot/cpu/x86/assembler_x86.hpp

// Serializes memory and blows flags
void membar(Membar_mask_bits order_constraint) {
  // We only have to handle StoreLoad
  // x86平台只需要处理StoreLoad
  if (order_constraint & StoreLoad) {

    int offset = -VM_Version::L1_line_size();
    if (offset < -128) {
      offset = -128;
    }

    // 下面这两句插入了一条lock前缀指令: lock addl $0, $0(%rsp) 
    lock(); // lock前缀指令
    addl(Address(rsp, offset), 0); // addl $0, $0(%rsp) 
  }
}

在linux系统x86中的实现

x86处理器中利用lock实现类似内存屏障的效果。

inline void OrderAccess::loadload()   { compiler_barrier(); }
inline void OrderAccess::storestore() { compiler_barrier(); }
inline void OrderAccess::loadstore()  { compiler_barrier(); }
inline void OrderAccess::storeload()  { fence();            }

inline void OrderAccess::acquire()    { compiler_barrier(); }
inline void OrderAccess::release()    { compiler_barrier(); }

inline void OrderAccess::fence() {
   // always use locked addl since mfence is sometimes expensive
#ifdef AMD64
  __asm__ volatile ("lock; addl $0,0(%%rsp)" : : : "cc", "memory");
#else
  __asm__ volatile ("lock; addl $0,0(%%esp)" : : : "cc", "memory");
#endif
  compiler_barrier();
}

lock前缀指令的作用

确保后续指令执行的原子性。在Pentium及之前的处理器中，带有lock前缀的指令在执行期间会锁住总线，使得其它处理器暂时无法通过总线访问内存，很显然，这个开销很大。在新的处理器中，Intel使用缓存锁定来保证指令执行的原子性，缓存锁定将大大降低lock前缀指令的执行开销。
LOCK前缀指令具有类似于内存屏障的功能，禁止该指令与前面和后面的读写指令重排序。
LOCK前缀指令会等待它之前所有的指令完成、并且所有缓冲的写操作写回内存(也就是将store buffer中的内容写入内存)之后才开始执行，并且根据缓存一致性协议，刷新store buffer的操作会导致其他cache中的副本失效。

汇编层面volatile的实现

添加下面的jvm参数查看之前可见性Demo的汇编指令

-XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -Xcomp

343842034

验证了可见性使用了lock前缀指令

从硬件层面分析Lock前缀指令

《64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf》中有如下描述：

The 32-bit IA-32 processors support locked atomic operations on locations in system memory. These operations are typically used to manage shared data structures (such as semaphores, segment descriptors, system segments, or page tables) in which two or more processors may try simultaneously to modify the same field or flag. The processor uses three interdependent mechanisms for carrying out locked atomic operations:

• Guaranteed atomic operations

• Bus locking, using the LOCK# signal and the LOCK instruction prefix

• Cache coherency protocols that ensure that atomic operations can be carried out on cached data structures (cache lock); this mechanism is present in the Pentium 4, Intel Xeon, and P6 family processors

32位的IA-32处理器支持对系统内存中的位置进行锁定的原子操作。这些操作通常用于管理共享的数据结构(如信号量、段描述符、系统段或页表)，在这些结构中，两个或多个处理器可能同时试图修改相同的字段或标志。

处理器使用三种相互依赖的机制来执行锁定的原子操作:

有保证的原子操作
总线锁定，使用LOCK#信号和LOCK指令前缀
缓存一致性协议，确保原子操作可以在缓存的数据结构上执行(缓存锁);这种机制出现在Pentium 4、Intel Xeon和P6系列处理器中

Java并发编程（四）并发三大特性-有序性 Java并发编程（二）JMM&并发三大特性-原子性