前言：

Java為我們提供了隱式（synchronized聲明方式）和顯式（java.util.concurrentAPI編程方式）兩種工具來避免線程爭用。

本章節(jié)探索Java關鍵字synchronized。主要包含以下幾個內(nèi)容。

• synchronized關鍵字的使用；
• synchronized背后的Monitor(管程)；
• synchronized保證可見性和防重排序；
• 使用synchronized注意嵌套鎖定。

1、使用方式

synchronized 關鍵字有以下四種使用方式：

• 實例方法
• 靜態(tài)方法
• 實例方法中的代碼塊
• 靜態(tài)方法中的代碼塊

實例方法同步和實例方法代碼塊同步：

// 實例方法同步和實例方法代碼塊同步
public class SynchronizedTest {
    private int count;
    public void setCountPart(int num) {
        synchronized (this) {
            this.count += num;
        }
    }
    public synchronized void setCount(int num) {
        this.count += num;
    }
}

靜態(tài)方法同步和靜態(tài)方法代碼塊同步：

// 靜態(tài)方法同步和靜態(tài)方法代碼塊同步
public class SynchronizedTest {
    private static int count;
    public static void setCountPart(int num) {
        synchronized (SynchronizedTest.class) {
            count += num;
        }
    }
    public static synchronized void setCount(int num) {
        count += num;
    }
}

使用關鍵字synchronized實現(xiàn)同步是在JVM內(nèi)部實現(xiàn)處理，對于應用開發(fā)人員來說它是隱式進行的。

每個Java對象都有一個與之關聯(lián)的monitor。

當線程調(diào)用實例同步方法時，會自動獲取實例對象的monitor。

當線程調(diào)用靜態(tài)同步方法時，會自動獲取該類Class實例對象的monitor。

Class實例：JVM為每個加載的class創(chuàng)建了對應的Class實例來保存class及interface的所有信息；

2、Monitor（管程）

Monitor 直譯為監(jiān)視器，中文圈里稱為管程。它的作用是讓線程互斥，保護共享數(shù)據(jù)，另外也可以向其它線程發(fā)送滿足條件的信號。

如下圖，線程通過入口隊列（Entry Queue）到達訪問共享數(shù)據(jù)，若有線程占用轉(zhuǎn)移等待隊列（Wait Queue），線程訪問共享數(shù)據(jù)完后觸發(fā)通知或轉(zhuǎn)移到信號隊列（Signal Queue）。

2.1 關于管程模型

網(wǎng)上查詢很多文章，大多數(shù)羅列 “ Hasen 模型、Hoare 模型和 MESA模型 ”這些名詞，看過之后我還是一知半解。本著對知識的求真，查找溯源，找到了以下資料。

為什么會有這三種模型？

假設有兩個線程A和B，線程B先進入monitor執(zhí)行，線程A處于等待。當線程A執(zhí)行完準備退出的時候，是先退出monitor還是先喚醒線程A？這時就出現(xiàn)了Mesa語義, Hoare語義和Brinch Hansen語義 三種不同版本的處理方式。

2.2 Mesa Semantics

Mesa模型中 線程只會出現(xiàn)在WaitQueue，EntryQueue，Monitor。

當線程B發(fā)出信號告知線程A時，線程A從WaitQueue 轉(zhuǎn)移到EntryQueue并等待線程B退出Monitor之后再進入Monitor。也就是先通知再退出。

2.3 Brinch Hanson Semantics

Brinch Hanson模型和Mesa模型類似區(qū)別在于僅允許線程B退出Monitor后才能發(fā)送信號給線程A。也就是先退出再通知。

2.4 Hoare Semantics

Hoare模型中 線程會分別出現(xiàn)在WaitQueue，EntryQueue，SignalQueue，Monitor中。

當線程B發(fā)出信號告知線程A并且退出Monitor轉(zhuǎn)移到SignalQueue，線程A進入Monitor。當線程A離開Monitor后，線程B再次回到Monitor。

https://www.andrew.cmu.edu/course/15-440-kesden/applications/ln/lecture6.html

https://cseweb.ucsd.edu/classes/sp17/cse120-a/applications/ln/lecture8.html

Java里面monitor是如何處理？

我們通過反編譯class文件看下Synchronized工作原理。

public class SynchronizedTest {
    private int count;
    public void setCountPart(int num) {
        synchronized (this) {
            this.count += num;
        }
    }
}

編譯和反編譯命令

javac SynchronizedTest.java
javap -v SynchronizedTest

我們看到兩個關鍵指令 monitorenter 和 monitorexit

2.5 monitorenter

Each object has a monitor associated with it. The thread that executes monitorenter gains ownership of the monitor associated with objectref. If another thread already owns the monitor associated with objectref, the current thread ……

每個對象都有一個關聯(lián)monitor。

線程執(zhí)行 monitorenter 時嘗試獲取關聯(lián)對象的monitor。

獲取時如果對象的monitor被另一個線程占有，則等待對方釋放monitor后再次嘗試獲取。

如果獲取成功則monitor計數(shù)器設置為1并將當前線程設為monitor擁有者，如果線程再次進入計數(shù)器自增，以表示進入次數(shù)。

2.6 monitorexit

The current thread should be the owner of the monitor associated with the instance referenced by objectref……

線程執(zhí)行monitorexit 時，monitor計數(shù)器自減，當計數(shù)器變?yōu)?時釋放對象monitor。

原文：https://docs.oracle.com/javase/specs/jvms/se6/html/Instructions2.doc9.html

3、可見性和重排序

在介紹Java并發(fā)內(nèi)存模型詳情的時候，我們提到過線程訪問共享對象時會先拷貝副本到CPU緩存，修改后返回CPU緩存，然后等待時機刷新到主存。這樣一來另外線程讀到的數(shù)據(jù)副本就不是最新，導致了數(shù)據(jù)的不一致，一般也將這種問題稱為線程可見性問題。

不過在使用synchronized關鍵字的時候，情況有所不同。線程在進入synchronized后會同步該線程可見的所有變量，退出synchronized后，會將所有修改的變量直接同步到主存，可視為跳過了CPU緩存，這樣一來就避免了可見性問題。

另外Java編譯器和Java虛擬機為了達到優(yōu)化性能的目的會對代碼中的指令進行重排序。但是重排序會導致多線程執(zhí)行出現(xiàn)意想不到的錯誤。使用synchronized關鍵字可以消除對同步塊共享變量的重排序。

4、局限與性能

synchronized給我們提供了同步處理的便利，但是它在某些場景下也存在局限性，比如以下場景。

• 讀多寫少場景。讀動作其實是安全，我們應該嚴格控制寫操作。替代方案使用讀寫鎖readwritelock。如果只有一個線程進行寫操作，可使用volatile關鍵字替代。
• 允許多個線程同時進入場景。synchronized限制了每次只有一個線程可進入。替代方案使用信號量semaphore。
• 需要保證搶占資源公平性。synchronized并不保證線程進入的公平性。替代方案公平鎖FairLock。
  

關于性能問題。進入和退出同步塊操作性能開銷很小，但是過大范圍設置同步或者在頻繁的循環(huán)中使用同步可能會導致性能問題。

可重入，在monitorenter指令解讀中，可以看出synchronized是可重入，重入一般發(fā)生在同步方法嵌套調(diào)用中。不過要防止嵌套monitor死鎖問題。

比如下面代碼會直接造成死鎖：

private final Object lock1 = new Object();
private final Object lock2 = new Object();
public void method1()   {
    synchronized (lock1) {
        synchronized (lock2) {
        }
    }
}
public void method2()   {
    synchronized (lock2) {
        synchronized (lock1) {
        }
    }
}

現(xiàn)實情況中，開發(fā)一般都不會出現(xiàn)以上代碼。但在使用 wait() notify() 很可能會出現(xiàn)阻塞鎖定。下面是一個模擬鎖的實現(xiàn)。

• 線程A調(diào)用lock() ，進入鎖定代碼執(zhí)行。
• 線程B調(diào)用lock() ，得到monitorObj的monitor后等待線程B喚醒。
• 線程A執(zhí)行完鎖定代碼后，調(diào)用unlock() ，在嘗試獲取monitorObj的monitor時，發(fā)現(xiàn)有線程占用，也一直掛起。
• 這樣線程A B 就互相干瞪眼！
  

public class Lock{
protected MonitorObj monitorObj = new MonitorObj();
    protected boolean isLocked = false;
    public void lock() throws InterruptedException{
        synchronized(this){
            while(isLocked){
                synchronized(this.monitorObj){
                    this.monitorObj.wait();
                }
            }
            isLocked = true;
        }
    }
    public void unlock(){
        synchronized(this){
            this.isLocked = false;
            synchronized(this.monitorObj){
                this.monitorObj.notify();
            }
        }
    }
}

總結(jié)：

到此這篇關于java并發(fā)之synchronized的文章就介紹到這了,更多相關java并發(fā)synchronized內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論