Java Synchronized怎么使用

本篇內(nèi)容介紹了“Java Synchronized怎么使用”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

Synchronized鎖優(yōu)化

jdk1.6對鎖的實現(xiàn)引入了大量的優(yōu)化，如自旋鎖、適應(yīng)性自旋鎖、鎖消除、鎖粗化、偏向鎖、輕量級鎖等技術(shù)來減少鎖操作的開銷。 鎖主要存在四中狀態(tài)，依次是：無鎖-> 偏向鎖 -> 輕量級鎖 -> 重量級鎖，他們會隨著競爭的激烈而逐漸升級。注意鎖可以升級不可降級，這種策略是為了提高獲得鎖和釋放鎖的效率。

偏向鎖

偏向鎖是Java 6之后加入的新鎖，它是一種針對加鎖操作的優(yōu)化手段，經(jīng)過研究發(fā)現(xiàn)，在大多數(shù)情況下，鎖不僅不存在多線程競爭，而且總是由同一線程多次獲得，因此為了減少同一線程獲取鎖(會涉及到一些CAS操作,耗時)的代價而引入偏向鎖。

偏向鎖的核心思想是，如果一個線程獲得了鎖，那么鎖就進入偏向模式，此時Mark Word 的結(jié)構(gòu)也變?yōu)槠蜴i結(jié)構(gòu)，當這個線程再次請求鎖時，無需再做任何同步操作，即獲取鎖的過程，這樣就省去了大量有關(guān)鎖申請的操作，從而也就提供程序的性能。

所以，對于沒有鎖競爭的場合，偏向鎖有很好的優(yōu)化效果，畢竟極有可能連續(xù)多次是同一個線程申請相同的鎖。但是對于鎖競爭比較激烈的場合，偏向鎖就失效了，

因為這樣場合極有可能每次申請鎖的線程都是不相同的，因此這種場合下不應(yīng)該使用偏向鎖，否則會得不償失，需要注意的是，偏向鎖失敗后，并不會立即膨脹為重量級鎖，而是先升級為輕量級鎖。下面我們接著了解輕量級鎖。

引入偏向鎖主要目的是：為了在無多線程競爭的情況下盡量減少不必要的輕量級鎖執(zhí)行路徑。上面提到了輕量級鎖的加鎖解鎖操作是需要依賴多次CAS原子指令的。

那么偏向鎖是如何來減少不必要的CAS操作呢？我們可以查看Mark work的結(jié)構(gòu)就明白了。只需要檢查是否為偏向鎖、鎖標識為以及ThreadID即可

獲取鎖

• 檢測Mark Word是否為可偏向狀態(tài)，即是否為偏向鎖1，鎖標識位為01；

• 若為可偏向狀態(tài)，則測試線程ID是否為當前線程ID，如果是，則執(zhí)行步驟（5），否則執(zhí)行步驟（3）；

• 如果線程ID不為當前線程ID，則通過CAS操作競爭鎖，競爭成功，則將Mark Word的線程ID替換為當前線程ID，否則執(zhí)行線程（4）；

• 通過CAS競爭鎖失敗，證明當前存在多線程競爭情況，當?shù)竭_全局安全點，獲得偏向鎖的線程被掛起，偏向鎖升級為輕量級鎖，然后被阻塞在安全點的線程繼續(xù)往下執(zhí)行同步代碼塊；

• 執(zhí)行同步代碼塊

釋放鎖 偏向鎖的釋放采用了一種只有競爭才會釋放鎖的機制，線程是不會主動去釋放偏向鎖，需要等待其他線程來競爭。偏向鎖的撤銷需要等待全局安全點（這個時間點是上沒有正在執(zhí)行的代碼）。其步驟如下：

• 暫停擁有偏向鎖的線程，判斷鎖對象石是否還處于被鎖定狀態(tài)；

• 撤銷偏向蘇，恢復到無鎖狀態(tài)（01）或者輕量級鎖的狀態(tài)；

輕量級鎖

倘若偏向鎖失敗，虛擬機并不會立即升級為重量級鎖，它還會嘗試使用一種稱為輕量級鎖的優(yōu)化手段(1.6之后加入的)，此時Mark Word 的結(jié)構(gòu)也變?yōu)檩p量級鎖的結(jié)構(gòu)。

輕量級鎖能夠提升程序性能的依據(jù)是“對絕大部分的鎖，在整個同步周期內(nèi)都不存在競爭”，注意這是經(jīng)驗數(shù)據(jù)。需要了解的是，輕量級鎖所適應(yīng)的場景是線程交替執(zhí)行同步塊的場合，如果存在同一時間訪問同一鎖的場合，就會導致輕量級鎖膨脹為重量級鎖。

引入輕量級鎖的主要目的是在多沒有多線程競爭的前提下，減少傳統(tǒng)的重量級鎖使用操作系統(tǒng)互斥量產(chǎn)生的性能消耗。當關(guān)閉偏向鎖功能或者多個線程競爭偏向鎖導致偏向鎖升級為輕量級鎖，則會嘗試獲取輕量級鎖。

獲取鎖

• 判斷當前對象是否處于無鎖狀態(tài)（hashcode、0、01），若是，則JVM首先將在當前線程的棧幀中建立一個名為鎖記錄（Lock Record）的空間，用于存儲鎖對象目前的Mark Word的拷貝（官方把這份拷貝加了一個Displaced前綴，即Displaced Mark Word）；否則執(zhí)行步驟（3）；

• JVM利用CAS操作嘗試將對象的Mark Word更新為指向Lock Record的指正，如果成功表示競爭到鎖，則將鎖標志位變成00（表示此對象處于輕量級鎖狀態(tài)），執(zhí)行同步操作；如果失敗則執(zhí)行步驟（3）；

• 判斷當前對象的Mark Word是否指向當前線程的棧幀，如果是則表示當前線程已經(jīng)持有當前對象的鎖，則直接執(zhí)行同步代碼塊；否則只能說明該鎖對象已經(jīng)被其他線程搶占了，這時輕量級鎖需要膨脹為重量級鎖，鎖標志位變成10，后面等待的線程將會進入阻塞狀態(tài)；

釋放鎖

輕量級鎖的釋放也是通過CAS操作來進行的，主要步驟如下：

• 取出在獲取輕量級鎖保存在Displaced Mark Word中的數(shù)據(jù)；

• 用CAS操作將取出的數(shù)據(jù)替換當前對象的Mark Word中，如果成功，則說明釋放鎖成功，否則執(zhí)行（3）；

• 如果CAS操作替換失敗，說明有其他線程嘗試獲取該鎖，則需要在釋放鎖的同時需要喚醒被掛起的線程。

對于輕量級鎖，其性能提升的依據(jù)是“對于絕大部分的鎖，在整個生命周期內(nèi)都是不會存在競爭的”，如果打破這個依據(jù)則除了互斥的開銷外，還有額外的CAS操作，因此在有多線程競爭的情況下，輕量級鎖比重量級鎖更慢；

自旋鎖

輕量級鎖失敗后，虛擬機為了避免線程 真實地在操作系統(tǒng)層面掛起，還會進行一項稱為自旋鎖的優(yōu)化手段。

這是基于在大多數(shù)情況下，線程持有鎖的時間都不會太長，如果直接掛起操作系統(tǒng)層面的線程可能會得不償失，畢竟操作系統(tǒng)實現(xiàn)線程之間的切換時需要從用戶態(tài)轉(zhuǎn)換到核心態(tài)，這個狀態(tài)之間的轉(zhuǎn)換需要相對比較長的時間，時間成本相對較高，因此自旋鎖會假設(shè)在不久將來，

當前的線程可以獲得鎖，因此虛擬機會讓當前想要獲取鎖的線程做幾個空循環(huán)(這也是稱為自旋的原因)，一般不會太久，可能是50個循環(huán)或100循環(huán)，在經(jīng)過若干次循環(huán)后，如果得到鎖，就順利進入臨界區(qū)。

如果還不能獲得鎖，那就會將線程在操作系統(tǒng)層面掛起，這就是自旋鎖的優(yōu)化方式，這種方式確實也是可以提升效率的。最后沒辦法也就只能升級為重量級鎖了。

線程的阻塞和喚醒需要CPU從用戶態(tài)轉(zhuǎn)為核心態(tài)，頻繁的阻塞和喚醒對CPU來說是一件負擔很重的工作，勢必會給系統(tǒng)的并發(fā)性能帶來很大的壓力。

同時我們發(fā)現(xiàn)在許多應(yīng)用上面，對象鎖的鎖狀態(tài)只會持續(xù)很短一段時間，為了這一段很短的時間頻繁地阻塞和喚醒線程是非常不值得的。所以引入自旋鎖。

何謂自旋鎖？ 所謂自旋鎖，就是讓該線程等待一段時間，不會被立即掛起，看持有鎖的線程是否會很快釋放鎖。怎么等待呢？執(zhí)行一段無意義的循環(huán)即可（自旋），和CAS類似。

自旋等待不能替代阻塞，先不說對處理器數(shù)量的要求（多核，貌似現(xiàn)在沒有單核的處理器了），雖然它可以避免線程切換帶來的開銷，但是它占用了處理器的時間。

如果持有鎖的線程很快就釋放了鎖，那么自旋的效率就非常好，反之，自旋的線程就會白白消耗掉處理的資源，它不會做任何有意義的工作，典型的占著茅坑不拉屎，這樣反而會帶來性能上的浪費。

所以說，自旋等待的時間（自旋的次數(shù)）必須要有一個限度，如果自旋超過了定義的時間仍然沒有獲取到鎖，則應(yīng)該被掛起。

自旋鎖在JDK 1.4.2中引入，默認關(guān)閉，但是可以使用-XX:+UseSpinning開開啟，在JDK1.6中默認開啟。同時自旋的默認次數(shù)為10次，可以通過參數(shù)-XX:PreBlockSpin來調(diào)整；

如果通過參數(shù)-XX:preBlockSpin來調(diào)整自旋鎖的自旋次數(shù)，會帶來諸多不便。假如我將參數(shù)調(diào)整為10，但是系統(tǒng)很多線程都是等你剛剛退出的時候就釋放了鎖（假如你多自旋一兩次就可以獲取鎖），你是不是很尷尬。

于是JDK1.6引入自適應(yīng)的自旋鎖，讓虛擬機會變得越來越聰明。

適應(yīng)自旋鎖

JDK 1.6引入了更加聰明的自旋鎖，即自適應(yīng)自旋鎖。所謂自適應(yīng)就意味著自旋的次數(shù)不再是固定的，它是由前一次在同一個鎖上的自旋時間及鎖的擁有者的狀態(tài)來決定。

它怎么做呢？線程如果自旋成功了，那么下次自旋的次數(shù)會更加多，因為虛擬機認為既然上次成功了，那么此次自旋也很有可能會再次成功，那么它就會允許自旋等待持續(xù)的次數(shù)更多。

反之，如果對于某個鎖，很少有自旋能夠成功的，那么在以后要或者這個鎖的時候自旋的次數(shù)會減少甚至省略掉自旋過程，以免浪費處理器資源。

有了自適應(yīng)自旋鎖，隨著程序運行和性能監(jiān)控信息的不斷完善，虛擬機對程序鎖的狀況預測會越來越準確，虛擬機會變得越來越聰明。

鎖消除

消除鎖是虛擬機另外一種鎖的優(yōu)化，這種優(yōu)化更徹底，Java虛擬機在JIT編譯時(可以簡單理解為當某段代碼即將第一次被執(zhí)行時進行編譯，又稱即時編譯).

通過對運行上下文的掃描，去除不可能存在共享資源競爭的鎖，通過這種方式消除沒有必要的鎖，可以節(jié)省毫無意義的請求鎖時間，如下StringBuffer的append是一個同步方法，但是在add方法中的StringBuffer屬于一個局部變量，并且不會被其他線程所使用

因此StringBuffer不可能存在共享資源競爭的情景，JVM會自動將其鎖消除。

為了保證數(shù)據(jù)的完整性，我們在進行操作時需要對這部分操作進行同步控制，但是在有些情況下，JVM檢測到不可能存在共享數(shù)據(jù)競爭，這是JVM會對這些同步鎖進行鎖消除。

鎖消除的依據(jù)是逃逸分析的數(shù)據(jù)支持。 如果不存在競爭，為什么還需要加鎖呢？所以鎖消除可以節(jié)省毫無意義的請求鎖的時間。

變量是否逃逸，對于虛擬機來說需要使用數(shù)據(jù)流分析來確定，但是對于我們程序員來說這還不清楚么？我們會在明明知道不存在數(shù)據(jù)競爭的代碼塊前加上同步嗎？

但是有時候程序并不是我們所想的那樣？我們雖然沒有顯示使用鎖，但是我們在使用一些JDK的內(nèi)置API時，如StringBuffer、Vector、HashTable等，這個時候會存在隱形的加鎖操作。

比如StringBuffer的append()方法，Vector的add()方法：

COPYpublic void vectorTest(){
       Vector<String> vector = new Vector<String>();
       for(int i = 0 ; i < 10 ; i++){
           vector.add(i + "");
       }
       System.out.println(vector);
   }

在運行這段代碼時，JVM可以明顯檢測到變量vector沒有逃逸出方法vectorTest()之外，所以JVM可以大膽地將vector內(nèi)部的加鎖操作消除。

逃逸分析

如果證明一個對象不會逃逸方法外或者線程外，則可針對此變量進行優(yōu)化：

同步消除synchronization Elimination，如果一個對象不會逃逸出線程，則對此變量的同步措施可消除。

重量級鎖

重量級鎖通過對象內(nèi)部的監(jiān)視器（monitor）實現(xiàn)，其中monitor的本質(zhì)是依賴于底層操作系統(tǒng)的Mutex Lock實現(xiàn)，操作系統(tǒng)實現(xiàn)線程之間的切換需要從用戶態(tài)到內(nèi)核態(tài)的切換，切換成本非常高。

為什么重量級鎖的開銷比較大呢

原因是當系統(tǒng)檢查到是重量級鎖之后，會把等待想要獲取鎖的線程阻塞，被阻塞的線程不會消耗CPU，但是阻塞或者喚醒一個線程，都需要通過操作系統(tǒng)來實現(xiàn)，也就是相當于從用戶態(tài)轉(zhuǎn)化到內(nèi)核態(tài)，而轉(zhuǎn)化狀態(tài)是需要消耗時間的

三種鎖的區(qū)別

鎖升級

偏向鎖升級輕量級鎖：當一個對象持有偏向鎖，一旦第二個線程訪問這個對象，如果產(chǎn)生競爭，偏向鎖升級為輕量級鎖。

輕量級鎖升級重量級鎖：一般兩個線程對于同一個鎖的操作都會錯開，或者說稍微等待一下（自旋），另一個線程就會釋放鎖。但是當自旋超過一定的次數(shù)，或者一個線程在持有鎖，一個在自旋，又有第三個來訪時，輕量級鎖膨脹為重量級鎖，重量級鎖使除了擁有鎖的線程以外的線程都阻塞，防止CPU空轉(zhuǎn)。

鎖粗化

我們知道在使用同步鎖的時候，需要讓同步塊的作用范圍盡可能小—僅在共享數(shù)據(jù)的實際作用域中才進行同步，這樣做的目的是為了使需要同步的操作數(shù)量盡可能縮小，如果存在鎖競爭，那么等待鎖的線程也能盡快拿到鎖。  在大多數(shù)的情況下，上述觀點是正確的，LZ也一直堅持著這個觀點。

但是如果一系列的連續(xù)加鎖解鎖操作，可能會導致不必要的性能損耗，所以引入鎖粗話的概念。 鎖粗話概念比較好理解，就是將多個連續(xù)的加鎖、解鎖操作連接在一起，擴展成一個范圍更大的鎖。

如下面的例子，一個方法由兩個加鎖,因為num = x + y;耗時較短，對比兩次鎖短的多，就會鎖粗化。

COPYprivate int x, y;
   /**
    * 因為一個方法需要兩個加鎖解鎖耗費資源
    * 對于  num = x + y; 耗費時間很短 就會將
    * 代碼包裹進去組成一個鎖
    * @return
    */
   public int lockCoarsening() {
       int num = 0;
       //對象鎖
       synchronized (this) {
           x++;
           //todo 處理部分業(yè)務(wù)
       }
       num = x + y;
       //對象鎖
       synchronized (this) {
           y++;
           //todo 處理部分業(yè)務(wù)
       }
       return num;
   }

粗化后

COPYprivate int x, y;
  /**
   * 使用一個鎖
   *
   * @return
   */
  public int lockCoarsening() {
      int num = 0;
      //只進行一次加鎖解鎖
      synchronized (this) {
          x++;
          //todo 處理部分業(yè)務(wù)
          num = x + y;
          y++;
          //todo 處理部分業(yè)務(wù)
      }
      return num;
  }

wait和notify的原理

調(diào)用wait方法，首先會獲取監(jiān)視器鎖，獲得成功以后，會讓當前線程進入等待狀態(tài)進入等待隊列并且釋放鎖。

當其他線程調(diào)用notify后，會選擇從等待隊列中喚醒任意一個線程，而執(zhí)行完notify方法以后，并不會立馬喚醒線程，原因是當前的線程仍然持有這把鎖，處于等待狀態(tài)的線程無法獲得鎖。必須要等到當前的線程執(zhí)行完按monitorexit指令以后，也就是鎖被釋放以后，處于等待隊列中的線程就可以開始競爭鎖了。

wait和notify為什么需要在synchronized里面？

wait方法的語義有兩個，一個是釋放當前的對象鎖、另一個是使得當前線程進入阻塞隊列，而這些操作都和監(jiān)視器是相關(guān)的，所以wait必須要獲得一個監(jiān)視器鎖。

而對于notify來說也是一樣，它是喚醒一個線程，既然要去喚醒，首先得知道它在哪里，所以就必須要找到這個對象獲取到這個對象的鎖，然后到這個對象的等待隊列中去喚醒一個線程。

“Java Synchronized怎么使用”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！