【死磕Java並發】-----Java記憶體模型之happens-before
- 黄舟原創
- 2017-02-24 10:03:011239瀏覽
在上篇部落格（【死磕Java並發】—–深入分析volatile的實作原理）LZ提到由於存在執行緒本地記憶體和主記憶體的原因，再加上重排序，會導致多執行緒環境下存在可見性的問題。那我們正確使用同步、鎖的情況下，執行緒A修改了變數a何時對執行緒B可見？
我們無法就所有場景來規定某個執行緒修改的變數何時對其他執行緒可見，但是我們可以指定某些規則，這規則就是happens-before，從JDK 5 開始，JMM就使用happens-before的概念來闡述多執行緒之間的記憶體可見性。
在JMM中，如果一個操作執行的結果需要對另一個操作可見，那麼這兩個操作之間必定存在happens-before關係。
happens-before原則非常重要，它是判斷資料是否存在競爭、線程是否安全的主要依據，依靠這個原則，我們解決在並發環境下兩個操作之間是否可能存在衝突的所有問題。下面我們就一個簡單的例子稍微了解下happens-before ;
i = 1; //线程A执行 j = i ; //线程B执行
j 是否等於1呢？假設線程A的操作（i = 1）happens-before線程B的操作（j = i）,那麼可以確定線程B執行後j = 1 一定成立，如果他們不存在happens-before原則，那麼j = 1 不一定成立。這就是happens-before原則的威力。
happens-before原則定義如下：
1. 如果一個操作happens-before另一個操作，那麼第一個操作的執行結果將對第二個操作可見，而且第一個操作的執行順序排在第二個操作之前。
2. 兩個操作之間存在happens-before關係，並不意味著一定要按照happens-before原則制定的順序來執行。如果重排序之後的執行結果與依照happens-before關係來執行的結果一致，那麼這種重排序就不是非法。
下面是happens-before原則規則：
#程式順序規則：一個執行緒內，依照程式碼順序，書寫在前面的操作先行發生於書寫在後面的操作；
鎖定規則：一個unLock操作先行發生於後面對同一個鎖額lock操作；
- ##volatile變量規則：對一個變數的寫入操作先行發生於後面對這個變數的讀取操作；
- #傳遞規則：如果操作A先行發生於操作B，而操作B又先行發生於操作C，則可以得出操作A先行發生於操作C；
- 執行緒啟動規則：Thread物件的start()方法先行發生於此執行緒的每個一個動作；
- 執行緒中斷規則：對執行緒interrupt()方法的呼叫先行發生於被中斷執行緒的程式碼偵測到中斷事件的發生；
- 執行緒終結規則：執行緒中所有的操作都先行發生於執行緒的終止偵測，我們可以透過Thread.join()方法結束、Thread.isAlive()的回傳值手段偵測到執行緒已經終止執行；
- 物件終結規則：一個物件的初始化完成先行發生於他的finalize()方法的開始；
程式順序規則：一段程式碼在單一執行緒中執行的結果是有順序的。注意是執行結果，因為虛擬機器、處理器會對指令進行重排序（重新排序後面會詳細介紹）。雖然重新排序了，但是並不會影響程式的執行結果，所以程式最終執行的結果與順序執行的結果是一致的。故而這個規則只對單執行緒有效，在多執行緒環境下無法保證正確性。
鎖定規則：這個規則比較好理解，無論是在單執行緒環境或多執行緒環境，一個鎖處於被鎖定狀態，那麼必須先執行unlock操作後面才能進行lock操作。
volatile變數規則：這是一條比較重要的規則，它標誌著volatile保證了執行緒可見性。通俗點講就是如果一個線程先去寫一個volatile變量，然後一個線程去讀這個變量，那麼這個寫操作一定是happens-before讀操作的。
傳遞規則：提現了happens-before原則具有傳遞性，即A happens-before B , B happens-before C，那麼A happens-before C
#執行緒啟動規則：假定執行緒A在執行過程中，透過執行ThreadB.start()來啟動執行緒B，那麼執行緒A對共享變數的修改在接下來執行緒B開始執行後確保對執行緒B可見。
執行緒終結規則：假定執行緒A在執行的過程中，透過制定ThreadB.join()等待執行緒B終止，那麼執行緒B在終止之前對共享變數的修改在執行緒A等待返回後可見。
上面八條是原生Java滿足Happens-before關係的規則，但是我們可以對他們進行推導出其他滿足happens-before的規則：将一个元素放入一个线程安全的队列的操作Happens-Before从队列中取出这个元素的操作
将一个元素放入一个线程安全容器的操作Happens-Before从容器中取出这个元素的操作
在CountDownLatch上的倒数操作Happens-Before CountDownLatch#await()操作
释放Semaphore许可的操作Happens-Before获得许可操作
Future表示的任务的所有操作Happens-Before Future#get()操作
向Executor提交一个Runnable或Callable的操作Happens-Before任务开始执行操作
这里再说一遍happens-before的概念：如果两个操作不存在上述（前面8条 + 后面6条）任一一个happens-before规则，那么这两个操作就没有顺序的保障，JVM可以对这两个操作进行重排序。如果操作A happens-before操作B，那么操作A在内存上所做的操作对操作B都是可见的。
下面就用一个简单的例子来描述下happens-before原则：
private int i = 0;public void write(int j ){
i = j;
}public int read(){ return i;
}我们约定线程A执行write()，线程B执行read()，且线程A优先于线程B执行，那么线程B获得结果是什么？；我们就这段简单的代码一次分析happens-before的规则（规则5、6、7、8 + 推导的6条可以忽略，因为他们和这段代码毫无关系）：
由于两个方法是由不同的线程调用，所以肯定不满足程序次序规则；
两个方法都没有使用锁，所以不满足锁定规则；
变量i不是用volatile修饰的，所以volatile变量规则不满足；
传递规则肯定不满足；
所以我们无法通过happens-before原则推导出线程A happens-before线程B，虽然可以确认在时间上线程A优先于线程B指定，但是就是无法确认线程B获得的结果是什么，所以这段代码不是线程安全的。那么怎么修复这段代码呢？满足规则2、3任一即可。
happen-before原则是JMM中非常重要的原则，它是判断数据是否存在竞争、线程是否安全的主要依据，保证了多线程环境下的可见性。
下图是happens-before与JMM的关系图（摘自《Java并发编程的艺术》） 
参考资料
周志明：《深入理解Java虚拟机》
方腾飞：《Java并发编程的艺术》
在上篇博客（【死磕Java并发】—–深入分析volatile的实现原理）LZ提到过由于存在线程本地内存和主内存的原因，再加上重排序，会导致多线程环境下存在可见性的问题。那么我们正确使用同步、锁的情况下，线程A修改了变量a何时对线程B可见？
我们无法就所有场景来规定某个线程修改的变量何时对其他线程可见，但是我们可以指定某些规则，这规则就是happens-before，从JDK 5 开始，JMM就使用happens-before的概念来阐述多线程之间的内存可见性。
在JMM中，如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在happens-before关系。
happens-before原则非常重要，它是判断数据是否存在竞争、线程是否安全的主要依据，依靠这个原则，我们解决在并发环境下两操作之间是否可能存在冲突的所有问题。下面我们就一个简单的例子稍微了解下happens-before ；
i = 1; //线程A执行 j = i ; //线程B执行
j 是否等于1呢？假定线程A的操作（i = 1）happens-before线程B的操作（j = i）,那么可以确定线程B执行后j = 1 一定成立，如果他们不存在happens-before原则，那么j = 1 不一定成立。这就是happens-before原则的威力。
happens-before原则定义如下：
1. 如果一个操作happens-before另一个操作，那么第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前。
2. 两个操作之间存在happens-before关系，并不意味着一定要按照happens-before原则制定的顺序来执行。如果重排序之后的执行结果与按照happens-before关系来执行的结果一致，那么这种重排序并不非法。
下面是happens-before原则规则：
程序次序规则：一个线程内，按照代码顺序，书写在前面的操作先行发生于书写在后面的操作；
锁定规则：一个unLock操作先行发生于后面对同一个锁额lock操作；
volatile变量规则：对一个变量的写操作先行发生于后面对这个变量的读操作；
传递规则：如果操作A先行发生于操作B，而操作B又先行发生于操作C，则可以得出操作A先行发生于操作C；
线程启动规则：Thread对象的start()方法先行发生于此线程的每个一个动作；
线程中断规则：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生；
线程终结规则：线程中所有的操作都先行发生于线程的终止检测，我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值手段检测到线程已经终止执行；
对象终结规则：一个对象的初始化完成先行发生于他的finalize()方法的开始；
我们来详细看看上面每条规则（摘自《深入理解Java虚拟机第12章》）：
程序次序规则：一段代码在单线程中执行的结果是有序的。注意是执行结果，因为虚拟机、处理器会对指令进行重排序（重排序后面会详细介绍）。虽然重排序了，但是并不会影响程序的执行结果，所以程序最终执行的结果与顺序执行的结果是一致的。故而这个规则只对单线程有效，在多线程环境下无法保证正确性。
锁定规则：这个规则比较好理解，无论是在单线程环境还是多线程环境，一个锁处于被锁定状态，那么必须先执行unlock操作后面才能进行lock操作。
volatile变量规则：这是一条比较重要的规则，它标志着volatile保证了线程可见性。通俗点讲就是如果一个线程先去写一个volatile变量，然后一个线程去读这个变量，那么这个写操作一定是happens-before读操作的。
传递规则：提现了happens-before原则具有传递性，即A happens-before B , B happens-before C，那么A happens-before C
线程启动规则：假定线程A在执行过程中，通过执行ThreadB.start()来启动线程B，那么线程A对共享变量的修改在接下来线程B开始执行后确保对线程B可见。
线程终结规则：假定线程A在执行的过程中，通过制定ThreadB.join()等待线程B终止，那么线程B在终止之前对共享变量的修改在线程A等待返回后可见。
上面八条是原生Java满足Happens-before关系的规则，但是我们可以对他们进行推导出其他满足happens-before的规则：
将一个元素放入一个线程安全的队列的操作Happens-Before从队列中取出这个元素的操作
将一个元素放入一个线程安全容器的操作Happens-Before从容器中取出这个元素的操作
在CountDownLatch上的倒数操作Happens-Before CountDownLatch#await()操作
释放Semaphore许可的操作Happens-Before获得许可操作
Future表示的任务的所有操作Happens-Before Future#get()操作
向Executor提交一个Runnable或Callable的操作Happens-Before任务开始执行操作
这里再说一遍happens-before的概念：如果两个操作不存在上述（前面8条 + 后面6条）任一一个happens-before规则，那么这两个操作就没有顺序的保障，JVM可以对这两个操作进行重排序。如果操作A happens-before操作B，那么操作A在内存上所做的操作对操作B都是可见的。
下面就用一个简单的例子来描述下happens-before原则：
private int i = 0;public void write(int j ){
i = j;
}public int read(){ return i;
}我们约定线程A执行write()，线程B执行read()，且线程A优先于线程B执行，那么线程B获得结果是什么？；我们就这段简单的代码一次分析happens-before的规则（规则5、6、7、8 + 推导的6条可以忽略，因为他们和这段代码毫无关系）：
由于两个方法是由不同的线程调用，所以肯定不满足程序次序规则；
两个方法都没有使用锁，所以不满足锁定规则；
变量i不是用volatile修饰的，所以volatile变量规则不满足；
传递规则肯定不满足；
所以我们无法通过happens-before原则推导出线程A happens-before线程B，虽然可以确认在时间上线程A优先于线程B指定，但是就是无法确认线程B获得的结果是什么，所以这段代码不是线程安全的。那么怎么修复这段代码呢？满足规则2、3任一即可。
happen-before原则是JMM中非常重要的原则，它是判断数据是否存在竞争、线程是否安全的主要依据，保证了多线程环境下的可见性。
下圖是happens-before與JMM的關係圖（摘自《Java並發程式設計的藝術》）
以上就是【死磕Java並發】--- --Java記憶體模型之happens-before的內容，更多相關內容請關注PHP中文網（www.php.cn）！