标签：
可见性：一个线程对共享变量值的修改，能够及实地被其他线程看到。
共享变量：如果一个变量在多个线程的工作内存中都存在副本，那么这个变量就是这几个线程的共享变量。所
有的变量都存储在主内存中。
线程的工作内存：每个线程都有自己独立的工作内存，里面保存该线程使用到的变量的副本(主内存中该变量的
一份拷贝)。
多个线程对同一资源操作时，通常会产生进程，比如一个线程往消息队列插入数据，而另一个线程从消息队列取
出数据 当消息队列满时，插入消息的队列需要Sleep几个毫秒，把时间片让出给取消息的线程，当消息队列为空
时，取消息队列的线程需要Sleep几个毫秒，把时间片让给插入消息的线程。如果不这样做，则会出现某个线程独占
资源，最终导致另一个线程死等状态，会引发一些我问题。这其中就涉及到了数据争用问题。
Java内存模型(Java Memory Model)描述了Java程序中各种变量(线程共享变量)的大访问规则，以及在JVM中将
变量存储到内存和从内存中读取变量这样的底层细节。
JMM模型的工作流程：
其中有两条规定：
1)线程对共享变量的所有操作都必须在自己的工作内存中进行，不能直接从主存中读写。
2)不同线程之间无法直接访问其他线程工作内存中的变量，线程间变量值的传递需要通过主存来完成。
线程1对共享变量的修改要想被线程2及时看到，必须要经过如下两个步骤：
1)把工作内存1中更新过的共享变量刷新到主内存中。2)将主内存中最新的共享变量的值更新到工作内存2中。
我们来看一下这个流程：
要实现共享变量的的可见性，必须保证两点：
1)线程修改后的共享变量值能够及时从工作内存刷新到主内存中。
2)其他线程能够及时把共享变量的最新值从主内存更新到自己的工作内存中。
语言层面支持的可见性实现方式：
1)使用关键字synchronized
2)使用关键字volatile
Synchronized能够实现多线程的原子性(同步)和可见性。
JVM关于Synchronized的两条规定：
1)线程解锁前，必须把共享变量的最新值刷新到主内存中。
2)线程加锁时，将清空工作内存中共享变量的值，从而使用共享变量时需要从主内存中重新读取最新的值(注
意：加锁和解锁需要同一把锁)。
1)获得互斥锁
2)清空工作内存
3)从主内存拷贝变量的最新副本到工作内存
4)执行代码
5)将更改后的共享变量的值刷新到主内存
6)释放互斥锁
重排序：代码书写的顺序与实际执行的顺序不同，指令重排序是编译器或处理器为了提高程序性能而做的优化。
包括三种：
1)编译器优化的重排序(编译器优化)
2)指令级并行的重排序(处理器优化)
3)内存系统的重排序(处理器优化)
重排序的可能：
as-if-serial含义指的是无论如何重排序，程序执行的结果应该与代码顺序执行的结果一致(Java编译器、运行时和
处理器都会保证Java在单线程下遵循as-if-serial语义)。重排序不会给单线程带来内存可见性的问题。
我们来看一段程序的例子：
多线程中程序交错执行，重排序可能会造成内存可见性问题。
public class SynchronizedDemo {
//共享变量
private boolean ready = false;
private int result = 0;
private int number = 1;
//写操作
public void write(){
ready = true; //1.1
number = 2; //1.2
}
//读操作
public void read(){
if(ready){ //2.1
result = number*3; //2.2
}
System.out.println("result的值为：" + result);
}
//内部线程类
private class ReadWriteThread extends Thread {
//根据构造方法中传入的flag参数，确定线程执行读操作还是写操作
private boolean flag;
public ReadWriteThread(boolean flag){
this.flag = flag;
}
public void run() {
if(flag){
//构造方法中传入true，执行写操作
write();
}else{
//构造方法中传入false，执行读操作
read();
}
}
}
public static void main(String[] args){
SynchronizedDemo synDemo = new SynchronizedDemo();
//启动线程执行写操作
synDemo.new ReadWriteThread(true).start();
//启动线程执行读操作
synDemo.new ReadWriteThread(false).start();
}
}
运行结果：
在主线程中启动线程执行读、写操作。可见性分析：
如果线程程序正常执行那么结果为：6
第一种可能的执行顺序：
1.1—>2.1—>2.2—>1.2
result的值：3
第二种可能的执行顺序：
1.2—>2.1—>2.2—>1.1
result的值：0
也可能有其他的情况，就不再进行举例。导致共享变量在线程间不可见的原因：
1)线程的交叉执行。
2)重排序结合线程交叉执行。
3)共享变量更新后的值没有在工作内存与主内存间及时更新。
我们加入synchronized(this)同步代码块，当一个线程访问object的一个synchronized(this)同步代码块时，其他线
程对object中所有其它synchronized(this)同步代码块的访问将会被阻塞。
实现可见性改写后的代码：
可以在写线程和读线程之间加个休眠操作，让写线程执行完，读线程在执行，也可以使用wait和notify来控制线程
执行的顺序。
public static void main(String[] args){
SynchronizedDemo synDemo = new SynchronizedDemo();
//启动线程执行写操作
synDemo.new ReadWriteThread(true).start();
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
//启动线程执行读操作
synDemo.new ReadWriteThread(false).start();
}
或者给读操作和写操作的方法声明中加关键字synchronized修饰：
//写操作
public synchronized void write(){
ready = true; //1.1
number = 2; //1.2
}
//读操作
public synchronized void read(){
if(ready){ //2.1
result = number*3; //2.2
}
System.out.println("result的值为：" + result);
} 最后的结果为：
不可见原因： synchronized解决方案：
1)线程的交叉执行 —>原子性
2)重排序结合线程交叉执行 —>原子性
3)共享变量未及时更新 —>可见性
1)能够保证volatile变量的可见性
2)不能保证volatile变量复合操作的原子性
深入来说：通过加入内存屏障和禁止重排序优化来实现的。
1)对volatile变量执行写操作时，会在写操作后加入一条store屏障指令。
2)对volatile变量执行读操作时，会在读操作后加入一条load屏障指令。
通俗地讲：volatile变量在每次被线程访问时，都强迫从主内存中重读该变量的值，而当该变量发生变化时，又会
强迫线程将最新的值刷新到主内存，这样任何时刻，不同的线程总能看到该变量的最新值。
线程写volatile变量的过程：
1)改变线程工作内存中volatile变量副本的值。
2)将改变后的副本的值从工作内存刷新到主内存。
线程读volatile变量的过程：
1)从主内存中读取volatile变量的最新值到线程的工作内存中。
2)从工作内存中读取volatile变量的副本。
对于下面的一段程序的使用volatile和synchronized
private int number = 0;
number++;//不是原子操作
1读取number的值
2将number的值加1
3写入最新的number的值
//加入synchronized，变为原子操作
synchronized(thhis){
number++;
}
//变为volatile变量，无法保证原子性
private volatile int number = 0;
import java.util.*;
public class VolatileDemo {
private volatile int number = 0;
public int getNumber(){
return this.number;
}
public void increase(){
try {
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
this.number++;
}
public static void main(String[] args) {
final VolatileDemo volDemo = new VolatileDemo();
//在主线程中启动500个线程的++操作
for(int i = 0 ; i < 500 ; i++){
new Thread(new Runnable() {
public void run() {
volDemo.increase();
}
}).start();
}
//如果还有子线程在运行，主线程就让出CPU资源，
//直到所有的子线程都运行完了，主线程再继续往下执行
while(Thread.activeCount() > 1){
Thread.yield();
}
System.out.println("number : " + volDemo.getNumber());
}
}
输出的结果基本都接近500：
解决方案：
保证number自增操作的原子操作
1)使用synchronized关键字
2)JDK1.5以后使用ReentrantLock(java.util.concurrent.locks包下)
3)JDK1.5以后使用At.tomicIterger(java.util.concurrent.atomic包下)
使用synchronized关键字保证原子性修改后的代码：
private int number = 0;
public int getNumber(){
return this.number;
}
public void increase(){
try {
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized(this){
this.number++;
}
} 运行结果：
private Lock lock = new ReentrantLock();
private int number = 0;
public int getNumber(){
return this.number;
}
public void increase(){
try {
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
lock.lock();
try {
this.number++;
} finally {
lock.unlock();
}
运行结果：同上
要在多线程中安全使用volatile变量，必须同时满足：
1)对变量的写入操作不依赖其当前值
不满足：number++ count=count*5等
满足：boolean变量、记录温度变化的变量
2)该变量没有包含在具有其他变量的不变式中。不满足：不变式low<up
1)volatile比synchronized更轻量级。
2)volatile没有synchronized使用的广泛。
3)volatile不需要加锁，比synchronized更轻量级，不会哦阻塞线程。
4)从内存可见性角度看，volatile读相当于加锁，volatile写相当于解锁。
5)synchronized既能保证可见性，又能保证原子性，而volatile只能保证可见性，无法保证原子性。
6)volatile本身不保证获取和设置操作的原子性，仅仅保持修改的可见性。但是java的内存模型保证声明为
volatile的long和double变量的get和set操作是原子的。
共享数据的访问权限都必须定义为private。一般是考虑安全性，对数据提供保护，可以通过set()方法赋值，再
通过get()方法取值，这就是java封装的思想。
Java中对共享数据操作的并发控制是采用加锁技术。
Java中没有提供检测与避免死锁的专门机制，但应用程序员可以采用某些策略防止死锁的发生。
final也可以保证内存可见性。
对64位(long、double)变量的读写可能不是原子操作
Java内存模型允许JVM将没有被volatile修饰的64位数据类型的读写操作划分为两次32位的读写操作来运行。
导致问题：有可能会出现读取到半个变量的情况。
解决方法：加volatile关键字。
即使没有保证可见性的措施，很多时候共享变量依然能够在主内存和工作内存间得到及时的更新？
答：一般只有在短时间内高并发的情况下才会出现变量得不到及时更新的情况，因为CPU在执行时会很快地刷新
缓存，所以一般情况下很难看到这种问题。
慢了不就不会刷新了。。。CPU运算快的话，在分配的时间片内就能完成所有工作：工作内从1->主内存->工作
内存2，然后这个线程就释放CPU时间片，这样一来就保证了数据的可见性。如果是慢了话CPU强行剥夺该线的资
源，分配给其它线程，该线程就需要等待CPU下次给该线程分配时间片，如果在这段时间内有别的线程访问共享变
量，可见性就没法保证了。
标签：
原文地址：http://blog.csdn.net/erlian1992/article/details/51712615
