并發(fā)安全問題

線程安全性

線程安全是指我們所寫的代碼在并發(fā)情況下使用時(shí)，總是能表現(xiàn)出正確的行為；反之，未實(shí)現(xiàn)線程安全的代碼，表現(xiàn)的行為是不可預(yù)知的，有可能正確，

實(shí)現(xiàn)線程安全的方式：

• 線程封閉

  就是把對象封裝到一個(gè)線程里，只有這一個(gè)線程能看到此對象。實(shí)現(xiàn)線程封閉的方式如下：

  • 棧封閉

    這里是指每個(gè)線程自己的線程棧，方法的局部變量就是在線程棧中的，對于其他線程是不可見的

  • ThreadLocal

    各個(gè)線程Thread對象維護(hù)了一份Map，對于其他線程是不可見的

• 無狀態(tài)的類

  沒有任何成員變量的類，就叫無狀態(tài)的類，這種類一定是線程安全的。

• 讓類不可變

  沒有成員變量的類畢竟是少數(shù)，我們還可以讓類的成員變量不可變，給他們加上final關(guān)鍵字

  如果成員變量是一個(gè)對象，final不能保證類的安全性，因?yàn)殡m然對象的引用不會變，但是在堆上的對象實(shí)例可能被多個(gè)線程同時(shí)修改，沒有正確處理的情況下，對象實(shí)例在堆中的數(shù)據(jù)是不可預(yù)知的。

• 加鎖或CAS

  synchronized、顯示鎖Look、原子Atomic操作、CAS機(jī)制等等

死鎖

定義

是指兩個(gè)或兩個(gè)以上的進(jìn)程在執(zhí)行過程中，由于競爭資源或者由于彼此通信而造成的一種阻塞的現(xiàn)象，若無外力作用，它們都將無法推進(jìn)下去。此時(shí)稱系統(tǒng)處于死鎖狀態(tài)或系統(tǒng)產(chǎn)生了死鎖。

• 死鎖是必然發(fā)生在多操作者（M>=2 個(gè)）爭奪多個(gè)資源（N>=2 個(gè)，且 N<=M） 才會發(fā)生這種情況。
• 爭奪資源的順序不對，如果爭奪資源的順序是一樣的，也不會產(chǎn)生死鎖；
• 爭奪者對拿到的資源不放手，也不能被掠奪。

學(xué)術(shù)化的定義。死鎖的發(fā)生必須具備以下四個(gè)必要條件。

• 互斥條件：指進(jìn)程對所分配到的資源進(jìn)行排它性使用，即在一段時(shí)間內(nèi)某資源只由一個(gè)進(jìn)程占用。如果此時(shí)還有其它進(jìn)程請求資源，則請求者只能等待， 直至占有資源的進(jìn)程用畢釋放。
• 請求和保持條件：指進(jìn)程已經(jīng)保持至少一個(gè)資源，但又提出了新的資源請求，而該資源已被其它進(jìn)程占有，此時(shí)請求進(jìn)程阻塞，但又對自己已獲得的其它資源保持不放。
• 不剝奪條件：指進(jìn)程已獲得的資源，在未使用完之前，不能被剝奪，只能在使用完時(shí)由自己釋放。
• 環(huán)路等待條件：指在發(fā)生死鎖時(shí)，必然存在一個(gè)進(jìn)程——資源的環(huán)形鏈， 即進(jìn)程集合{P0，P1，P2，···，Pn}中的 P0 正在等待一個(gè) P1 占用的資源；P1 正在等待 P2 占用的資源，……，Pn 正在等待已被 P0 占用的資源。

只要打破四個(gè)必要條件之一就能有效預(yù)防死鎖的發(fā)生。

• 打破互斥條件：改造獨(dú)占性資源為虛擬資源，大部分資源已無法改造。
• 打破不可搶占條件：當(dāng)一進(jìn)程占有一獨(dú)占性資源后又申請一獨(dú)占性資源而無 法滿足，則退出原占有的資源。
• 打破占有且申請條件：采用資源預(yù)先分配策略，即進(jìn)程運(yùn)行前申請全部資源， 滿足則運(yùn)行，不然就等待，這樣就不會占有且申請。
• 打破循環(huán)等待條件：實(shí)現(xiàn)資源有序分配策略，對所有設(shè)備實(shí)現(xiàn)分類編號，所有進(jìn)程只能采用按序號遞增的形式申請資源。

避免死鎖常見的算法有有序資源分配法、銀行家算法。

實(shí)現(xiàn)一個(gè)死鎖

/*** @Description: 實(shí)現(xiàn)一個(gè)簡單的死鎖程序* @Author 胡尚* @Date: 2023/4/1 17:59*/
public class DeadLookTest {private static Object o1 = new Object();private static Object o2 = new Object();public void fastLock() throws InterruptedException {synchronized(o1){Thread.sleep(2000);System.out.println("fast");synchronized (o2){System.out.println("----");}}}public void postLock() throws InterruptedException {synchronized(o2){Thread.sleep(2000);System.out.println("post");synchronized (o1){System.out.println("----");}}}public static void main(String[] args) throws InterruptedException {DeadLookTest deadlook = new DeadLookTest();// 新開一個(gè)線程去調(diào)用其中一個(gè)方法new Thread(() -> {try {deadlook.postLock();} catch (InterruptedException e) {}}).start();deadlook.fastLock();}
}

查看死鎖

使用jstack命令查看死鎖結(jié)果

C:\Users\Administrator>jps
4784 DeadLookTest
9808 RemoteMavenServer36
2052 Launcher
2692 Jps
8572C:\Users\Administrator>jstack 4784
......
Found one Java-level deadlock:
=============================
"Thread-0":waiting to lock monitor 0x0000025d5a58fd88 (object 0x0000000716edb910, a java.lang.Object),which is held by "main"
"main":waiting to lock monitor 0x0000025d5a58e998 (object 0x0000000716edb920, a java.lang.Object),which is held by "Thread-0"Java stack information for the threads listed above:
===================================================
"Thread-0":at cn.tulingxueyuan.safe.dl.DeadLookTest.postLock(DeadLookTest.java:30)- waiting to lock <0x0000000716edb910> (a java.lang.Object)- locked <0x0000000716edb920> (a java.lang.Object)at cn.tulingxueyuan.safe.dl.DeadLookTest.lambda$main$0(DeadLookTest.java:39)at cn.tulingxueyuan.safe.dl.DeadLookTest$$Lambda$1/2003749087.run(Unknown Source)at java.lang.Thread.run(Thread.java:748)
"main":at cn.tulingxueyuan.safe.dl.DeadLookTest.fastLock(DeadLookTest.java:20)- waiting to lock <0x0000000716edb920> (a java.lang.Object)- locked <0x0000000716edb910> (a java.lang.Object)at cn.tulingxueyuan.safe.dl.DeadLookTest.main(DeadLookTest.java:43)Found 1 deadlock.

解決死鎖

我們現(xiàn)在通過上面的命令找到了產(chǎn)生死鎖的位置，那么如何取解決死鎖嘞？我們知道產(chǎn)生死鎖的原因如下：

• 死鎖是必然發(fā)生在多操作者（M>=2 個(gè)）爭奪多個(gè)資源（N>=2 個(gè)，且 N<=M） 才會發(fā)生這種情況。
• 爭奪資源的順序不對，如果爭奪資源的順序是一樣的，也不會產(chǎn)生死鎖；
• 爭奪者對拿到的資源不放手，也不能被掠奪。

第一個(gè)條件一般都是業(yè)務(wù)必須要，那么打破死鎖就要從下面的兩個(gè)條件去解決

• 保證爭奪鎖資源的順序一樣。

  在實(shí)際的開發(fā)中可能會存在比較隱蔽的加鎖順序，比如鎖對象作為方法參數(shù)傳遞，如下所示

  private static void businessDo(Object first,Object second) throws InterruptedException {String threadName = Thread.currentThread().getName();synchronized (first){System.out.println(threadName + " get first");Thread.sleep(1000);synchronized (second){System.out.println(threadName + " get second");}}
  }// 然后兩個(gè)線程，在調(diào)用的時(shí)候傳遞的參數(shù)順序卻不一樣
  businessDo(No1,No2);
  businessDo(No2,No1);
  

  解決上面這種問題的方式是：在加鎖前，在方法中做一個(gè)內(nèi)部的排序

  public class SafeOperate {private static Object No13 = new Object();//第一個(gè)鎖private static Object No14 = new Object();//第二個(gè)鎖private static Object tieLock = new Object();//第三把鎖public void transfer(Object first,Object second) throws InterruptedException {int firstHash = System.identityHashCode(first);int secondHash = System.identityHashCode(second);if(firstHash<secondHash){synchronized (first){System.out.println(Thread.currentThread().getName()+" get "+first);Thread.sleep(100);synchronized (second){System.out.println(Thread.currentThread().getName()+" get "+second);}}}else if(secondHash<firstHash){synchronized (second){System.out.println(Thread.currentThread().getName()+" get"+second);Thread.sleep(100);synchronized (first){System.out.println(Thread.currentThread().getName()+" get"+first);}}}else{// 萬一兩個(gè)對象的hash值一樣，那么就引入第三把鎖，誰先搶到第三把鎖就去進(jìn)行前兩兩把鎖的加鎖synchronized (tieLock){synchronized (first){synchronized (second){System.out.println(Thread.currentThread().getName()+" get"+first);System.out.println(Thread.currentThread().getName()+" get"+second);}}}}}
  }
  

• 對拿到的鎖資源嘗試釋放

  這種方式對于synchronized是不適用的，因?yàn)樗荒玫芥i誓不罷休。使用ReentrantLock，使用其中的tryLock(long time, TimeUnit unit)方法，在指定的時(shí)間中如果還沒有拿到鎖就去進(jìn)行釋放的邏輯

  大致是實(shí)現(xiàn)邏輯如下所示

  while(true){if(No13.tryLock()){System.out.println(threadName +" get 13");// 如果沒有拿到No14的鎖，那么No13的鎖也釋放try{if(No14.tryLock()){try{System.out.println(threadName  +" get 14");System.out.println("zhouYuDo do work------------");break;}finally{No14.unlock();}}}finally {No13.unlock();}}// 如果不加休眠機(jī)制，那么就比較容易產(chǎn)生活鎖Thread.sleep(1000);
  }
  

其他線程安全問題

活鎖

兩個(gè)線程在嘗試拿鎖的機(jī)制中，發(fā)生多個(gè)線程之間互相謙讓，不斷發(fā)生同一個(gè)線程總是拿到同一把鎖，在嘗試拿另一把鎖時(shí)因?yàn)槟貌坏?#xff0c;而將本來已經(jīng)持有的鎖釋放的過程。

解決辦法：每個(gè)線程休眠隨機(jī)數(shù)，錯(cuò)開拿鎖的時(shí)間。

線程饑餓

低優(yōu)先級的線程，總是拿不到執(zhí)行時(shí)間

單例模式

• DCL雙重檢測機(jī)制
• volatile關(guān)鍵字禁止指令重排

public class HungrySingleton {//創(chuàng)建 SingletonHungry 的一個(gè)對象private static volatile HungrySingleton instance;// 讓構(gòu)方法私有，這樣該類就不會被其它類實(shí)例化private HungrySingleton() {}//獲取唯一可用的對象public static HungrySingleton getInstance() {if(null == instance) { synchronized{if(null == instance) { instance = new LazySingleton();}}}return instance;}
}