這3個併發編程的核心，你必定要知道！

前言

遠看併發，併發編程能夠抽象成三個核心問題: 分工、同步/協做、互斥

若是你已經工做了，那麼你必定據說過或者正在應用敏捷開發模式來交付平常的工做任務，咱們就用你熟悉的流程來解釋這三個核心問題

分工

將當前 Sprint 的 Story 拆分紅「合適」大小的 Task，而且安排給「合適」的 Team Member 去完成

這裏面用了兩個「合適」，將 Story 拆分紅大小適中，可完成的 Task 是很是重要的。拆分的粒度太粗，致使這個任務完成難度變高，耗時長，不易與其餘人配合；拆分的粒度太細，又致使任務太多，很差管理與追蹤，浪費精力和資源。(合適的線程才能更好的完成整塊工做，固然一個線程能夠輕鬆搞定的就不必多線程)；安排給合適的人員去完成一樣重要，UX-UE 問題交給後端人員處理，很顯然是有問題的 (主線程應該作的事交給子線程顯然是解決不了問題的，每一個線程作正確的事才能發揮做用)

關於分工，常見的 Executor，生產者-消費者模式，Fork/Join 等，這都是分工思想的體現

同步/協做

任務拆分完畢，我要等張三的任務，張三要等李四的任務，也就是說任務之間存在依賴關係，前面的任務執行完畢，後面的任務才能夠執行，人高級在能夠經過溝通反覆確認，確保本身的任務能夠開始執行。但面對程序，咱們須要瞭解程序的溝通方式，一個線程執行完任務，如何通知後續線程執行

全部的同步/協做關係咱們均可以用你最熟悉的 If-then-else 來表示:

if(前序任務完成){
    execute();
}else{
    wait();
}

複製代碼

上面的代碼就是說:當某個條件不知足時，線程須要等待；當某個條件知足時，線程須要被喚醒執行，線程之間的協做多是主線程與子線程的協做，多是子線程與子線程的合做， Java SDK 中 CountDownLatch 和 CyclicBarrier 就是用來解決線程協做問題的

互斥

分工和同步強調的是性能，可是互斥是強調正確性，就是咱們經常提到的「線程安全」，當多個線程同時訪問一個共享變量/成員變量時，就可能發生不肯定性，形成不肯定性主要是有可見性、原子性、有序性這三大問題，而解決這些問題的核心就是互斥

互斥同一時刻，只容許一個線程訪問共享變量

來看下圖，主幹路就是共享變量，進入主幹路一次只能有一輛車，這樣你是否理解了呢？「天下大事，分久必合」

一樣 Java SDK 也有不少互斥的解決方案，好比你立刻就能想到 synchronized 關鍵字，Lock，ThreadLocal 等就是互斥的解決方案

總結

資本家瘋狂榨取勞動工人的剩餘價值，得到最大收益。當你面對 CPU，內存，IO 這些勞動工人時，你就是那個資本家，你要思考如何充分榨取它們的價值

當一個工人能幹的活，毫不讓兩我的來幹(單線程能知足就不必爲了多線程)當多個工人幹活時，就要讓他們分工明確，合做順暢，沒矛盾

當任務很大時，因爲 IO 幹活慢，CPU 幹活快，就不必讓 CPU 死等當前的 IO，轉而去執行其餘指令，這就是榨取剩餘價值，如何最大限度的榨取其價值，這就涉及到後續的調優問題，好比多少線程合適等

分工是設計，同步和互斥是實現，沒有好的設計也就沒有好的實現，因此在分工階段，強烈建議你們勾劃草圖，瞭解瓶頸所在，這樣纔會有更好的實現，後續章節的內容，我也會帶領你們畫草圖，分析問題，逐步養成這個習慣

本章內容能夠用下面的圖來簡單歸納，葉子結點的內容咱們會逐步點亮，現階段不用過度關注(若是你上來就啃 JDK 源碼，也許你會痛苦的迷失，並最終放棄你的進階之路的)

理解三大核心問題，你要充分結合生活中的實際，程序中的併發問題，基本上都能在實際生活中找獲得原型。

最後

歡迎你們關注個人公衆號【程序員追風】，文章都會在裏面更新，整理的資料也會放在裏面。