建设银行网站电脑上不去,sqlite3做网站数据库,保定有那些网站,运营商查浏览网站最近在阅读FutureTask的源码是发现了一个问题那就是源码中封装结果的字段并没有使用volatile修饰#xff0c;源码如下#xff1a;public class FutureTaskV implements RunnableFutureV {/*** 状态变化路径* Possible state transitions:* NEW - COMPLET…最近在阅读FutureTask的源码是发现了一个问题那就是源码中封装结果的字段并没有使用volatile修饰源码如下public class FutureTaskV implements RunnableFutureV {/*** 状态变化路径* Possible state transitions:* NEW - COMPLETING - NORMAL* NEW - COMPLETING - EXCEPTIONAL* NEW - CANCELLED* NEW - INTERRUPTING - INTERRUPTED*/private static final int NEW 0;private static final int COMPLETING 1;// 完成中private static final int NORMAL 2;// 正常结束// 异常private static final int EXCEPTIONAL 3;// 取消任务private static final int CANCELLED 4;// 中断任务private static final int INTERRUPTING 5;// 被中断的private static final int INTERRUPTED 6;// 任务执行状态private volatile int state;// 待执行的任务private CallableV callable;// 封装的结果或则执行的异常private Object outcome; // non-volatile, protected by state reads/writes// 执行当前任务的线程 通过CAS来设置private volatile Thread runner;// 所有等待获取执行结果的线程被封装为一个链表数据结构private volatile WaitNode waiters;
}我们看到state字段是volatile修改的但是outcome字段并没有volatile修饰。继续看下这两个字段如何设置值的// 1. 正常结束设置结果
protected void set(V v) {// 设置状态为完成中if (UNSAFE.compareAndSwapInt(this, stateOffset, NEW, COMPLETING)) {// 设置结果outcome v;// 设置状态为正常结束UNSAFE.putOrderedInt(this, stateOffset, NORMAL); // final state// 后续事宜唤醒等待的线程调用done()方法finishCompletion();}
}// 不带超时时间
public V get() throws InterruptedException, ExecutionException {int s state;// 状态小于等于完成中...(NEW,COMPLETING)if (s COMPLETING)// 等待s awaitDone(false, 0L);// return report(s);
}咋一看好像看不出什么名堂这里能清楚得出结论的是state字段在get()方法中是可见的。但是outcome字段并没有volatile修饰不能直接得出outcome字段在get()方法中也是可见的这样的结论。happen-before要搞清楚这个问题我们首先来复习下volatile关键字的作用Happens-Before原则前面一个操作的结果对后续操作是可见的。Happens-Before原则约束了编译器的优化行为虽允许编译器优化但是要求编译器优化后一定遵守Happens-Before原则。即使编译器进行指令重排序的优化如果结果和重排序前一致也是允许的。java1.5之后通过happen-before原则增强了volatile关键词。volatile关键词是轻量的实现线程安全的方法保证了volatile变量的有序性和可见性。可见性保证当写 volatile 变量时JMM 会立即把该线程对应的本地内存中的共享变量值刷新到主内存。当读 volatile 变量时JMM 会把该线程对应的本地内存置为无效。线程接下来将从主内存中读取共享变量。volatile 保证内存可见性其实是用到了 CPU 保证缓存一致性的 MESI 协议。当某线程对 volatile 变量的修改会立即回写到主存中并且导致其他线程的缓存失效强制其他线程再使用变量时需要从主存中读取。编译器有以下规则在每个volatile写操作的前面插入一个StoreStore屏障在每个volatile写操作的后面插入一个StoreLoad屏障在每个volatile读操作的后面插入一个LoadLoad屏障在每个volatile读操作的后面插入一个LoadStore屏障接下来我们来分析案例对于如下代码private volatile int state;
private Object outcome;public void set(Object v){if(state NEW){ // 1outcome v; // 2state DONE; // 3}
}public void get(){if(state DONE){ // 4return outcome; // 5}return null;
}根据volatile的happen-before原则2对3是可见的同时4对5是可见的并且3对4是可见的那么根据传递性 2 3 4 5我们不难得出2 5成立即2对5可见。这里还有个问题就是多线程调用set()方法情况下存在竞争我们继续改进set()方法。private volatile int state;
private Object outcome;public void set(Object v){if(compareAndSet(state,NEW,DONE)){ // 1outcome v; // 2}
}
public void get(){if(state DONE){ // 4return outcome; // 5}return null;
}这里解决了修改state字段的原子性但是并不能保证刚才的2对5可见了因为这里满足1对2可见4对5可见同时1对4可见这里我们没法办推到出2对5可见。继续修改为了保证2对5的可见性我们还是得保留3这一行代码。那么我们完全可以增加一个中间临时变量TMP代码就改成这样private volatile int state;
private Object outcome;public void set(Object v){if(compareAndSet(state,NEW,TMP)){ // 1outcome v; // 2state DONE; // 3}
}public void get(){if(state DONE){ // 4return outcome; // 5}return null;
}这样我们既保证了设置state字段的原子性同时保证了outcome字段对get()方法的可见性。这完全就是FutureTask中outcome的实现逻辑所以我们已经正确分析了outcome为什么可以不加volatile关键字也能保证可见性的原因。
