這3個并發(fā)編程的核心，你一定要知道！

前言

遠看并發(fā)，并發(fā)編程可以抽象成三個核心問題: 分工、同步/協(xié)作、互斥

如果你已經(jīng)工作了，那么你一定聽說過或者正在應用敏捷開發(fā)模式來交付日常的工作任務，我們就用你熟悉的流程來解釋這三個核心問題

分工

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

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

關于分工，常見的 Executor，生產(chǎn)者-消費者模式，F(xiàn)ork/Join 等，這都是分工思想的體現(xiàn)

同步/協(xié)作

任務拆分完畢，我要等張三的任務，張三要等李四的任務，也就是說任務之間存在依賴關系，前面的任務執(zhí)行完畢，后面的任務才可以執(zhí)行，人高級在可以通過溝通反復確認，確保自己的任務可以開始執(zhí)行。但面對程序，我們需要了解程序的溝通方式，一個線程執(zhí)行完任務，如何通知后續(xù)線程執(zhí)行

所有的同步/協(xié)作關系我們都可以用你最熟悉的 If-then-else 來表示:

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

上面的代碼就是說:當某個條件不滿足時，線程需要等待；當某個條件滿足時，線程需要被喚醒執(zhí)行，線程之間的協(xié)作可能是主線程與子線程的協(xié)作，可能是子線程與子線程的合作， Java SDK 中 CountDownLatch 和 CyclicBarrier 就是用來解決線程協(xié)作問題的

互斥

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

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

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

同樣 Java SDK 也有很多互斥的解決方案，比如你馬上就能想到 synchronized 關鍵字，Lock，ThreadLocal 等就是互斥的解決方案

總結(jié)

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

當一個工人能干的活，絕不讓兩個人來干(單線程能滿足就沒必要為了多線程)當多個工人干活時，就要讓他們分工明確，合作順暢，沒矛盾

當任務很大時，由于 IO 干活慢，CPU 干活快，就沒必要讓 CPU 死等當前的 IO，轉(zhuǎn)而去執(zhí)行其他指令，這就是榨取剩余價值，如何最大限度的榨取其價值，這就涉及到后續(xù)的調(diào)優(yōu)問題，比如多少線程合適等

分工是設計，同步和互斥是實現(xiàn)，沒有好的設計也就沒有好的實現(xiàn)，所以在分工階段，強烈建議大家勾劃草圖，了解瓶頸所在，這樣才會有更好的實現(xiàn)，后續(xù)章節(jié)的內(nèi)容，我也會帶領大家畫草圖，分析問題，逐步養(yǎng)成這個習慣

歡迎大家關注我的公種浩【程序員追風】，文章都會在里面更新，整理的資料也會放在里面。

本章內(nèi)容可以用下面的圖來簡單概括，葉子結(jié)點的內(nèi)容我們會逐步點亮，現(xiàn)階段不用過分關注(如果你上來就啃 JDK 源碼，也許你會痛苦的迷失，并最終放棄你的進階之路的)

理解三大核心問題，你要充分結(jié)合生活中的實際，程序中的并發(fā)問題，基本上都能在實際生活中找得到原型。

最后

歡迎大家一起交流，喜歡文章記得點個贊喲，感謝支持！