深入理解Java内存模型（JMM）中的可见性

　　可见性是指当一个线程修改了某个共享变量的值时，其他线程是否能够立即知道这个修改。显然，对于串行程序来说，可见性问题是不存在的。因为你在任何一个操作步骤中修改了某个变量的值，在后续的步骤中读取这个变量的值时，读取的一定是修改后的新值。
　　但是这个问题存在于并行程序中。如果一个线程修改了某个全局变量的值，那么其他线程未必可以马上知道这个改动。图1。14展示了发生可见性问题的一种可能。如果在CPU1和CPU2上各运行了一个线程，它们共享变量t，由于编译器优化或者硬件优化的缘故，在CPU1上的线程将变量t进行了优化，然后将其缓存在cache中或者寄存器里。在这种情况下，如果在CPU2上的某个线程修改了变量t的实际值，那么CPU1上的线程可能无法知道这个改动，依然会读取cache中或者寄存器里的数据。因此，就产生了可见性问题。外在表现为：变量t的值被修改，但是CPU1上的线程依然会读到一个旧值。可见性问题也是并行程序开发中需要重点关注的问题之一。
　　图1。14发生可见性问题的一种可能
　　可见性问题是一个综合性问题。除上面提到的缓存优化或者硬件优化（有些内存读写可能不会立即触发，而会先进入一个硬件队列等待）会导致可见性问题，指令重排（这个问题将在下一节中详细讨论）及编辑器的优化，也有可能导致一个线程的修改不会立即被其他线程察觉。
　　下面来看一个简单的例子：Thread1Thread2
　　1：r2A；3：r1B；
　　2：B1；4：A2；
　　上述两个线程并行执行，分别有1、2、3、4四条指令。其中指令1、2属于线程1，而指令3、4属于线程2。
　　从指令的执行顺序上看，r22并且r11似乎是不可能出现的。但实际上，我们并没有办法从理论上保证这种情况不出现。因为编译器可能将指令重排成：Thread1Thread2
　　B1；r1B；
　　r2A；A2；
　　在这种执行顺序中，就有可能出现刚才看似不可能出现的r22并且r11的情况。
　　这个例子就说明，在一个线程中观察另外一个线程的变量，它们的值是否能观测到、何时能观测到是没有保证的。
　　再来看一个稍微复杂一些的例子：Thread1Thread2
　　r1p；r6p；
　　r2r1。x；r6。x3；
　　r3q；
　　r4r3。x；
　　r5r1。x；
　　这里假设在初始时，pq并且p。x0。对于大部分编译器来说，可能会对线程1进行向前替换的优化，也就是r5r1。x这条指令会被直接替换成r5r2。由于它们都读取了r1。x，又发生在同一个线程中，因此，编译器很可能认为第2次读取是完全没有必要的。因此，上述指令可能会变成：Thread1Thread2
　　r1p；r6p；
　　r2r1。x；r6。x3；
　　r3q；
　　r4r3。x；
　　r5r2；
　　现在思考这么一种场景。假设线程2中的r6。x3发生在r2r1。x和r4r3。x之间，而编译器又打算重用r2来表示r5，那么就有可能出现非常奇怪的现象。你看到的r2是0，r4是3，但是r5还是0。因此，如果从线程1来看就是：p。x的值从0变成了3（因为r4是3），接着又变成了0（这是不是算一个非常怪异的问题呢？）。
　　内容摘自《实战Java高并发程序设计（第3版）》，本书适合：所有java从业人员，所有数据库工程师阅读。
　　逻辑顺畅。全书脉络清晰，从Java高并发程序的设计基础开始由底层原理落实到具体案例，环环相扣，完整流畅。结构严谨。总体上循序渐进，逐步提升。每一章都各自有鲜明的侧重点，有利于读者快速抓住重点。
　　实用性强。本书注重实战，采用了理论结合实践的编写方法，给重要的知识点都安排了代码实例，帮助读者在工作中实战应用。