volatile关键字 atomic包
作者：互联网
一旦一个共享变量（类的成员变量、类的静态成员变量）被volatile修饰之后，那么就具备了两层语义：
1）保证了不同线程对这个变量进行操作时的可见性，即一个线程修改了某个变量的值，这新值对其他线程来说是立即可见的。
2）禁止进行指令重排序。
public class TestVolatile {
public static void main(String[] args) {
ThreadDemo td = new ThreadDemo();
new Thread(td).start();
while(true){
if(td.isFlag()){
System.out.println("------------------");
break;
}
}
}
}
class ThreadDemo implements Runnable {
private boolean flag = false;
@Override
public void run() {
try {
Thread.sleep(200);
} catch (InterruptedException e) {
}
flag = true;
System.out.println("flag=" + isFlag());
}
public boolean isFlag() {
return flag;
}
}
上面这个例子，开启一个多线程去改变flag为true，main 主线程中可以输出"------------------"吗？
答案是NO!
这个结论会让人有些疑惑，可以理解。开启的线程虽然修改了flag 的值为true,但是还没来得及写入主存当中，此时main里面的 td.isFlag()还是false,但是由于 while(true) 是底层的指令来实现，速度非常之快，一直循环都没有时间去主存中更新td的值，所以这里会造成死循环！运行结果如下：
flag = true；
此时线程是没有停止的，一直在循环。
如何解决呢？只需将 flag 声明为volatile，即可保证在开启的线程A将其修改为true时，main主线程可以立刻得知：
第一：使用volatile关键字会强制将修改的值立即写入主存；
第二：使用volatile关键字的话，当开启的线程进行修改时，会导致main线程的工作内存中缓存变量flag的缓存行无效（反映到硬件层的话，就是CPU的L1缓存中对应的缓存行无效）；
第三：由于线程main的工作内存中缓存变量flag的缓存行无效，所以线程main再次读取变量flag的值时会去主存读取。
volatile具备两种特性，第一就是保证共享变量对所有线程的可见性。将一个共享变量声明为volatile后，会有以下效应：
1.当写一个volatile变量时，JMM会把该线程对应的本地内存中的变量强制刷新到主内存中去；
2.这个写会操作会导致其他线程中的缓存无效。
2、禁止进行指令重排序
这里我们引用上篇文章单例里面的例子
class Singleton{
private volatile static Singleton instance = null;
private Singleton() {
}
public static Singleton getInstance() {
if(instance==null) {
synchronized (Singleton.class) {
if(instance==null)
instance = new Singleton();
}
}
return instance;
}
}
instance = new Singleton(); 这段代码可以分为三个步骤：
1、memory = allocate() 分配对象的内存空间
2、ctorInstance() 初始化对象
3、instance = memory 设置instance指向刚分配的内存
但是此时有可能发生指令重排，CPU 的执行顺序可能为：
1、memory = allocate() 分配对象的内存空间
3、instance = memory 设置instance指向刚分配的内存
2、ctorInstance() 初始化对象
在单线程的情况下，1->3->2这种顺序执行是没有问题的，但是如果是多线程的情况则有可能出现问题，线程A执行到11行代码，执行了指令1和3，此时instance已经有值了，值为第一步分配的内存空间地址，但是还没有进行对象的初始化；
此时线程B执行到了第8行代码处，此时instance已经有值了则return instance，线程B 使用instance的时候，就会出现异常。
这里可以使用 volatile 来禁止指令重排序。
从上面知道volatile关键字保证了操作的可见性和有序性，但是volatile能保证对变量的操作是原子性吗？
下面看一个例子：
package com.mmall.concurrency.example.count;
import java.util.concurrent.CountDownLatch;
/**
* @author: ChenHao
* @Description:
* @Date: Created in 15:05 2018/11/16
* @Modified by:
*/
public class CountTest {
// 请求总数
public static int clientTotal = 5000;
public static volatile int count = 0;
public static void main(String[] args) throws Exception {
//使用CountDownLatch来等待计算线程执行完
final CountDownLatch countDownLatch = new CountDownLatch(clientTotal);
//开启clientTotal个线程进行累加操作
for(int i=0;i<clientTotal;i++){
new Thread(){
public void run(){
count++;//自加操作
countDownLatch.countDown();
}
}.start();
}
//等待计算线程执行完
countDownLatch.await();
System.out.println(count);
}
}
4994
针对这个示例，一些同学可能会觉得疑惑，如果用volatile修饰的共享变量可以保证可见性，那么结果不应该是5000么?
问题就出在count++这个操作上，因为count++不是个原子性的操作，而是个复合操作。我们可以简单讲这个操作理解为由这三步组成:
1.读取count
2.count 加 1
3.将count 写到主存
所以，在多线程环境下，有可能线程A将count读取到本地内存中，此时其他线程可能已经将count增大了很多，线程A依然对过期的本地缓存count进行自加，重新写到主存中，最终导致了count的结果不合预期，而是小于5000。
那么如何来解决这个问题呢？下面我们来看看
Atomic包
在java 1.5的java.util.concurrent.atomic包下提供了一些原子操作类，即对基本数据类型的 自增（加1操作），自减（减1操作）、以及加法操作（加一个数），减法操作（减一个数）进行了封装，保证这些操作是原子性操作。atomic是利用CAS来实现原子性操作的（Compare And Swap）
package com.mmall.concurrency.example.count;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.atomic.AtomicInteger;
/**
* @author: ChenHao
* @Description:
* @Date: Created in 15:05 2018/11/16
* @Modified by:
*/
public class CountTest {
// 请求总数
public static int clientTotal = 5000;
public static AtomicInteger count = new AtomicInteger(0);
public static void main(String[] args) throws Exception {
//使用CountDownLatch来等待计算线程执行完
final CountDownLatch countDownLatch = new CountDownLatch(clientTotal);
//开启clientTotal个线程进行累加操作
for(int i=0;i<clientTotal;i++){
new Thread(){
public void run(){
count.incrementAndGet();//先加1，再get到值
countDownLatch.countDown();
}
}.start();
}
//等待计算线程执行完
countDownLatch.await();
System.out.println(count);
}
}
5000
public final int incrementAndGet() {
return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
}
public final int getAndAddInt(Object var1, long var2, int var4) {
int var5;
do {
var5 = this.getIntVolatile(var1, var2);
} while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));
return var5;
}
/***
* 获取obj对象中offset偏移地址对应的整型field的值。
* @param obj 包含需要去读取的field的对象
* @param obj中整型field的偏移量
*/
public native int getIntVolatile(Object obj, long offset);
/**
* 比较obj的offset处内存位置中的值和期望的值，如果相同则更新。此更新是不可中断的。
*
* @param obj 需要更新的对象
* @param offset obj中整型field的偏移量
* @param expect 希望field中存在的值
* @param update 如果期望值expect与field的当前值相同，设置filed的值为这个新值
* @return 如果field的值被更改返回true
*/
public native boolean compareAndSwapInt(Object obj, long offset, int expect, int update);
首先介绍一下什么是Compare And Swap(CAS)？简单的说就是比较并交换。
CAS 操作包含三个操作数 —— 内存位置（V）、预期原值（A）和新值(B)。如果内存位置的值与预期原值相匹配，那么处理器会自动将该位置值更新为新值。否则，处理器不做任何操作。无论哪种情况，它都会在 CAS 指令之前返回该位置的值。CAS 有效地说明了“我认为位置 V 应该包含值 A；如果包含该值，则将 B 放到这个位置；否则，不要更改该位置，只告诉我这个位置现在的值即可。” Java并发包(java.util.concurrent)中大量使用了CAS操作,涉及到并发的地方都调用了sun.misc.Unsafe类方法进行CAS操作。
我们来分析下incrementAndGet的逻辑：
1.先获取当前的value值
2.调用compareAndSet方法来来进行原子更新操作，这个方法的语义是：
先检查当前value是否等于obj中整型field的偏移量处的值，如果相等，则意味着obj中整型field的偏移量处的值 没被其他线程修改过，更新并返回true。如果不相等，compareAndSet则会返回false，然后循环继续尝试更新。
第一次count 为0时线程A调用incrementAndGet时，传参为 var1=AtomicInteger(0)，var2为var1 里面 0 的偏移量，比如为8090，var4为需要加的数值1,var5为线程工作内存值，do里面会先执行一次，通过getIntVolatile 获取obj对象中offset偏移地址对应的整型field的值此时var5=0;while 里面compareAndSwapInt 比较obj的8090处内存位置中的值和期望的值var5，如果相同则更新obj的值为(var5+var4=1)，此时更新成功，返回true,则 while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));结束循环，return var5。
当count 为0时，线程B 和线程A 同时读取到 count ,进入到第 8 行代码处，线程B 也是取到的var5=0,当线程B 执行到compareAndSwapInt时，线程A已经执行完compareAndSwapInt，已经将内存地址为8090处的值修改为1，此时线程B 执行compareAndSwapInt返回false,则继续循环执行do里面的语句，再次取内存地址偏移量为8090处的值为1，再去执行compareAndSwapInt，更新obj的值为(var5+var4=2)，返回为true,结束循环，return var5。
CAS的ABA问题
当然CAS也并不完美，它存在"ABA"问题，假若一个变量初次读取是A，在compare阶段依然是A，但其实可能在此过程中，它先被改为B，再被改回A，而CAS是无法意识到这个问题的。CAS只关注了比较前后的值是否改变，而无法清楚在此过程中变量的变更明细，这就是所谓的ABA漏洞。
标签：count,var5,instance,关键字,线程,atomic,volatile,public 来源： https://www.cnblogs.com/luxiaosheng999/p/16376120.html