目錄

1.上下文的切換

1.1 什么是上下文切換

2. 并發(fā)編程的死鎖問題

2.1 死鎖產(chǎn)生的原因

2.2 避免死鎖的方法

3.資源限制的挑戰(zhàn)3.1 什么是資源限制

---

????

并發(fā)編程的目的是為了讓程序更快，大家都知道并不是開啟的線程越多越快，因為開啟的線程越多隨即面臨的挑戰(zhàn)也越多，比如：上下文的切換、死鎖問題、以及硬件和軟件資源的限制問題。

1.上下文的切換

1.1 什么是上下文切換

??????? 學習操作系統(tǒng)的時候，都了解到：單核處理器也支持多線程執(zhí)行代碼，CPU通過給每個線程分配CPU時間片來實現(xiàn)這個機制。時間片是CPU分配給各個線程的時間，因為時間片非常短，所以CPU通過不停地切換線程執(zhí)行，讓我們感覺多個線程是同時執(zhí)行的，時間片一般是幾十毫秒(ms)。

???????? CPU通過時間片分配算法來循環(huán)執(zhí)行任務(wù)，當前任務(wù)執(zhí)行一個時間片后會切換到下一個任務(wù)。但是，在切換前會保存上一個任務(wù)的狀態(tài)，以便下次切換回這個任務(wù)時，可以再加載這個任務(wù)的狀態(tài)。所以任務(wù)從保存到再加載的過程就是一次上下文切換。

1.2?? 如何減少上下文切換

??? 減少上下文切換的方法有無鎖并發(fā)編程、CAS算法、使用最少線程和使用協(xié)程。

1. 無鎖并發(fā)編程。多線程競爭鎖時，會引起上下文切換，所以多線程處理數(shù)據(jù)時，可以用一些辦法來避免使用鎖，如將數(shù)據(jù)的ID按照Hash算法取模分段，不同的線程處理不同段的數(shù)據(jù)。

2.CAS算法。Java的 Atomic包使用CAS算法來更新數(shù)據(jù)，而不需要加鎖。

3.使用最少線程。避免創(chuàng)建不需要的線程，比如任務(wù)很少，但是創(chuàng)建了很多線程來處理，這樣會造成大量線程都處于等待狀態(tài)。

4.協(xié)程:在單線程里實現(xiàn)多任務(wù)的調(diào)度，并在單線程里維持多個任務(wù)間的切換

2. 并發(fā)編程的死鎖問題

2.1 死鎖產(chǎn)生的原因

• 資源競爭： 多個線程需要使用相同的資源，并且這些資源只能被一個線程一次性占用。如果一個線程獲取了資源A，另一個線程獲取了資源B，并且兩個線程都在等待對方的資源，就會發(fā)生死鎖。

• 資源請求和保持： 一個線程已經(jīng)持有一個資源，并且在等待獲取另一個資源時，不釋放已經(jīng)持有的資源。

• 資源不可搶占： 資源不能被強制從一個線程中搶占。只有線程自己才可以主動釋放已持有的資源。

• 循環(huán)等待： 存在一個線程循環(huán)等待資源的情況，例如線程A等待線程B持有的資源，而線程B又等待線程A持有的資源。

2.2 避免死鎖的方法

1. 避免嵌套鎖（一個線程獲取多個鎖）： 盡量避免一個線程在持有一個鎖的同時再去請求另一個鎖?？梢酝ㄟ^減少鎖的使用來避免死鎖。

2. 使用超時： 在獲取鎖的時候設(shè)置超時，如果超過一定時間沒有獲取到鎖，就放棄請求該鎖。這樣可以避免線程無限期地等待下去。

   if (lock.tryLock(10, TimeUnit.SECONDS)) {try {// critical section} finally {lock.unlock();}
   } else {// perform alternative action
   }
   

   3.盡量縮短鎖的持有時間：盡量縮短持有鎖的時間，只在必要的地方加鎖，減少在鎖內(nèi)執(zhí)行的操作

3.資源限制的挑戰(zhàn)

3.1 什么是資源限制

??????? 資源限制是指在進行并發(fā)編程時，程序的執(zhí)行速度受限于計算機硬件資源或軟件資源例如，服務(wù)器的帶寬只有 2Mbs，某個資源的下載速度是1Mb/s每秒，系統(tǒng)啟動10個線程下載資源，下載速度不會變成10Mb/s，所以在進行并發(fā)編程時，要考慮這些資源的限制。硬件資源限制有帶寬的上傳/下載速度、硬盤讀寫速度和CPU的處理速度。軟件資源限制有數(shù)據(jù)庫的連接數(shù)和socket 連接數(shù)等。

3.2 資源限制引發(fā)的問題

?????? 在并發(fā)編程中，將代碼執(zhí)行速度加快的原則是將代碼中串行執(zhí)行的部分變成并發(fā)執(zhí)行但是如果將某段串行的代碼并發(fā)執(zhí)行，因為受限于資源，仍然在串行執(zhí)行，這時候程序不僅不會加快執(zhí)行，反而會更慢，因為增加了上下文切換和資源調(diào)度的時間。例如，之前看到-段程序使用多線程在辦公網(wǎng)并發(fā)地下載和處理數(shù)據(jù)時，導致CPU利用率達到100%，幾個小時都不能運行完成任務(wù)，后來修改成單線程，一個小時就執(zhí)行完成了。

??????? 強烈建議：如果并發(fā)程序?qū)懙牟粐乐?#xff0c;出現(xiàn)問題定位起來比較耗時和棘手，java開發(fā)工程師盡量還是多使用JDK并發(fā)包提供的并發(fā)容器和工具類來解決并發(fā)問題。（比較jdk大叔的水平可是經(jīng)歷 了歷史的檢驗）