1. 先搞清楚Fork/Join到底在解決什么問題1.1 分治思想從“一個(gè)人干不完”說起Fork/Join這個(gè)名字我最早在Java 7的并發(fā)工具包里見到時(shí)第一反應(yīng)是“名字起得真直白”——Fork就是分叉Join就是合并。說白了它就是兩大思想組成的框架分治算法加工作竊取調(diào)度。分治這塊你小學(xué)就學(xué)過把一個(gè)大問題拆成若干個(gè)小問題小問題解決了大問題也就解決了。比如你要算一萬個(gè)數(shù)的總和最直覺的方式是寫個(gè)for循環(huán)從頭加到尾但如果有四個(gè)線程完全可以切成四段每段兩千五各算各的最后再把四段結(jié)果加起來。但分治思想本身并不新鮮幾十年前就有了經(jīng)典歸并排序就是這種思路。Fork/Join真正值得聊的是它怎么處理“拆了任務(wù)之后誰來執(zhí)行、執(zhí)行完怎么拼回來”的編排問題。Java里實(shí)現(xiàn)一個(gè)分治模型用普通的ExecutorService加Future也能做每次遞歸拆分任務(wù)用線程池submit再get結(jié)果。但你會(huì)發(fā)現(xiàn)坑很多任務(wù)拆得多了每個(gè)Future都要占內(nèi)存線程切換頻繁而且大任務(wù)依賴小任務(wù)的結(jié)果容易形成層層阻塞跑起來又慢又耗資源。Fork/Join之所以能成為專門框架核心在于兩件事它用雙端隊(duì)列管理每個(gè)線程的任務(wù)允許線程從別人的隊(duì)列尾部偷任務(wù)來干也就是所謂的工作竊取Work-Stealing它提供了完整的任務(wù)狀態(tài)管理機(jī)制任務(wù)被Fork出去之后隨時(shí)可以Join回來狀態(tài)通知、異常傳播都不需要你操心。這套組合拳恰恰是并發(fā)分治場景里最容易踩坑的地方Fork/Join直接用框架幫你擋住了。1.2 工作竊取算法為什么它是Fork/Join的靈魂我一直覺得工作竊取是Fork/Join的精髓。它解決的是一個(gè)在并行分治場景里非常實(shí)際的問題任務(wù)拆得不均勻怎么辦比如某個(gè)遞歸分支跑得快某個(gè)分支跑得慢或者某個(gè)任務(wù)本身比較大拆開之后兩邊規(guī)模差很多。如果固定把任務(wù)分給幾個(gè)線程執(zhí)行快的線程只能閑著等慢的并行度空有一半性能還是上不去。工作竊取的思路是**給每個(gè)工作線程維護(hù)一個(gè)雙端隊(duì)列自己負(fù)責(zé)從隊(duì)頭取任務(wù)執(zhí)行別人執(zhí)行完自己隊(duì)列里的活之后沒活干就去別的線程的隊(duì)列尾部偷一個(gè)任務(wù)來跑。**這樣空閑線程不會(huì)干等負(fù)載天然就均衡了。這就好比一條流水線四條工位左邊工位干完自己的活兒了不等著下班而是從右邊工位堆疊的半成品里拿點(diǎn)來一起做整體效率一下就拉上去了。而且從隊(duì)尾偷、從隊(duì)頭取兩個(gè)線程操作同一隊(duì)列的兩端沖突概率極低大部分情況下連鎖都不用碰靠CAS就夠了。關(guān)鍵點(diǎn)在于“偷小不偷大”。Fork/Join里任務(wù)拆成Fork之后子任務(wù)是在不斷遞歸產(chǎn)生小任務(wù)的。一個(gè)線程把自己的子任務(wù)Fork出去后它會(huì)先處理自己隊(duì)頭東西當(dāng)它發(fā)現(xiàn)別的隊(duì)列有活時(shí)優(yōu)先偷尾部——因?yàn)槲膊康娜蝿?wù)往往是最近Fork出來的、粒度更小的任務(wù)拿最小的任務(wù)去偷能盡量保證偷過來的任務(wù)快速完成減少偷取過程中的協(xié)作成本。這部分原理在各路資料里寫得很繞我自己的經(jīng)驗(yàn)是理解到“雙端隊(duì)列隊(duì)頭執(zhí)行隊(duì)尾偷取任務(wù)粒度遞進(jìn)”這個(gè)level就夠了再往深里鉆設(shè)計(jì)框架的人其實(shí)是為了把無謂競爭壓到最低。2. Fork/Join的核心類與參數(shù)選擇2.1 四個(gè)關(guān)鍵類ForkJoinPool、ForkJoinTask、RecursiveTask、RecursiveAction剛上手Fork/Join的人容易被一堆類名繞暈。抽出主線來看它其實(shí)只有四個(gè)角色需要你掌握ForkJoinPool線程池的總調(diào)度容器維護(hù)工作線程、任務(wù)隊(duì)列、公共池引用。它跟普通線程池最大的區(qū)別在于支持工作竊取并且每個(gè)線程都自帶雙端隊(duì)列。ForkJoinTask所有Fork/Join任務(wù)的抽象基類核心方法就是fork()和join()以及更高級(jí)的invokeAll()。RecursiveTask繼承自ForkJoinTask代表一個(gè)有返回結(jié)果的遞歸任務(wù)適合求和、最值、排序這類需要返回值的問題。RecursiveAction也是ForkJoinTask的子類代表無返回值的遞歸任務(wù)適合遍歷目錄、批量處理數(shù)據(jù)、數(shù)組賦值這類只關(guān)注副作用side effect的場景。另外還有個(gè)細(xì)節(jié)挺容易忽視ForkJoinTask實(shí)現(xiàn)了Future接口所以你在任務(wù)里調(diào)用get()也能拿到結(jié)果。但它跟普通Future有個(gè)關(guān)鍵區(qū)別——它的join()方法在等待任務(wù)完成時(shí)不會(huì)像Future那樣傻傻阻塞一個(gè)線程等另一個(gè)任務(wù)完成而是會(huì)在當(dāng)前線程里直接執(zhí)行被等待的任務(wù)。這個(gè)設(shè)計(jì)對等待型任務(wù)非常友好后面排查“線程卡死”那塊我們會(huì)再來回看這一點(diǎn)。invokeAll()是另一個(gè)容易被低估的方法。它接受兩個(gè)(left, right)子任務(wù)內(nèi)部做了兩個(gè)動(dòng)作先fork右邊的任務(wù)再在當(dāng)前線程直接在本地執(zhí)行左邊的任務(wù)。這樣一來右邊的任務(wù)會(huì)由別的線程偷走或者排隊(duì)等待執(zhí)行但左邊任務(wù)不用額外占用一個(gè)隊(duì)列槽位。如果任務(wù)拆分得粒度很細(xì)用invokeAll()比手動(dòng)fork()再join()要高效得多。2.2 參數(shù)怎么定線程數(shù)、拆分閾值、隊(duì)列容量用Fork/Join十個(gè)有八個(gè)會(huì)栽在參數(shù)設(shè)置上。參數(shù)就三個(gè)但每一個(gè)都直接影響性能線程數(shù)、拆分閾值、隊(duì)列容量嚴(yán)格來說沒有配置式設(shè)置由池自己管理但任務(wù)粒度會(huì)間接決定隊(duì)列長度。線程數(shù)怎么選ForkJoinPool默認(rèn)用Runtime.getRuntime().availableProcessors()作為并行度。對于純CPU密集型任務(wù)并行度CPU核數(shù)是最穩(wěn)妥的起點(diǎn)。如果任務(wù)里偶爾有IO可以適度調(diào)大比如核數(shù)×2。不建議圖省事直接調(diào)成幾十上百因?yàn)镕ork/Join工作線程一旦創(chuàng)建它是常駐的不干活也在占著資源。閾值怎么定這是Fork/Join最容易犯糊涂的地方。閾值太小任務(wù)拆得太多每個(gè)任務(wù)對象本身的開銷、線程調(diào)度開銷可能比計(jì)算本身還貴閾值太大任務(wù)根本拆不動(dòng)整個(gè)框架退化成單線程遞歸。我的經(jīng)驗(yàn)是先用一個(gè)不會(huì)讓任務(wù)拆分超過兩層或三層的初始值跑一遍再逐步調(diào)小觀察曲線最低點(diǎn)。如果任務(wù)處理的是數(shù)組20萬以下基本可以讓線程跑框架里經(jīng)典示范是求和的閾值設(shè)在1萬以內(nèi)單個(gè)元素級(jí)別的任務(wù)也可以但那個(gè)屬于極端場景非必要不建議。隊(duì)列長度其實(shí)你很難直接設(shè)置它是動(dòng)態(tài)擴(kuò)容的。但你可以通過控制“同時(shí)Fork出去的子任務(wù)數(shù)量”來間接影響隊(duì)列積壓。我的習(xí)慣是每次遞歸只fork一個(gè)子任務(wù)另一個(gè)用本地線程執(zhí)行這樣每個(gè)工作線程的隊(duì)列積壓量始終受控不會(huì)出現(xiàn)幾千個(gè)任務(wù)對象擠在一個(gè)隊(duì)列里的恐怖狀況。這個(gè)習(xí)慣在沒有invokeAll()的年代被很多人當(dāng)作“Fork/Join的黃金準(zhǔn)則”到現(xiàn)在依然適用。我要再次提個(gè)醒**并行度不是越大越好任務(wù)切分次數(shù)也絕不是越多越好。**我曾經(jīng)在某臺(tái)8核機(jī)器上跑數(shù)組求和默認(rèn)并行度是8閾值從10萬調(diào)到1萬再從1萬調(diào)到1000數(shù)據(jù)反而是閾值在1萬時(shí)最快。原因是任務(wù)對象太多導(dǎo)致GC壓力暴增工作線程之間搶任務(wù)隊(duì)列尾部的CAS沖突也多了開銷超過了并行帶來的收益。這種“并行反而不如串行”的怪現(xiàn)象具體分析放第4章來說。3. 實(shí)戰(zhàn)用Fork/Join實(shí)現(xiàn)百萬級(jí)數(shù)組求和3.1 目標(biāo)定義與實(shí)現(xiàn)思路講完原理接下去進(jìn)入實(shí)戰(zhàn)環(huán)節(jié)。我挑了一個(gè)最經(jīng)典的題目對一個(gè)長度為百萬級(jí)的long數(shù)組求和。為什么選這道題因?yàn)樗壿嫼唵魏诵木鸵粋€(gè)“累加”所有性能差異都直接反映在“任務(wù)拆分調(diào)度合并”這套機(jī)制上非常適合觀察Fork/Join框架自身的成本。選哪件事用Fork/Join做有幾條判斷標(biāo)準(zhǔn)問題能不能遞歸切分切出來的子問題是否相互獨(dú)立子問題的結(jié)果能不能合并符合這三條的典型任務(wù)有很多——求和、找最大值、歸并排序、大數(shù)組統(tǒng)計(jì)類運(yùn)算、目錄文件遍歷匯總。反過來如果任務(wù)本身就不能拆或者子任務(wù)之間有大量共享狀態(tài)和鎖操作那Fork/Join不僅幫不上忙還會(huì)拖垮你。實(shí)戰(zhàn)環(huán)境就是一臺(tái)普通的8核機(jī)器16G內(nèi)存Linux環(huán)境。為了更貼近真實(shí)開發(fā)我沒用公共池公共池的并行度是CPU核數(shù)而是用自定義的ForkJoinPool這樣容易控制并行度做對比。3.2 核心代碼SumTask實(shí)現(xiàn)定義一個(gè)SumTask繼承RecursiveTaskLong核心就是compute()方法。邏輯分三步先判斷任務(wù)是否已經(jīng)小到可以不拆如果能拆就把數(shù)組一分為二fork出子任務(wù)等兩邊結(jié)果之后相加如果足夠小就老老實(shí)實(shí)算。這個(gè)“拆到多大就不拆了”的臨界值就是傳說中的閾值THRESHOLD。import java.util.concurrent.ForkJoinPool; import java.util.concurrent.ForkJoinTask; import java.util.concurrent.RecursiveTask; import java.util.concurrent.ThreadLocalRandom; public class ForkJoinSumDemo { static class SumTask extends RecursiveTaskLong { private static final int THRESHOLD 100_000; private final long[] array; private final int start; private final int end; SumTask(long[] array, int start, int end) { this.array array; this.start start; this.end end; } Override protected Long compute() { int length end - start; if (length THRESHOLD) { long sum 0; for (int i start; i end; i) { sum array[i]; } return sum; } int mid start (end - start) / 2; SumTask left new SumTask(array, start, mid); SumTask right new SumTask(array, mid, end); left.fork(); long rightResult right.compute(); long leftResult left.join(); return leftResult rightResult; } } public static void main(String[] args) { int size 1_000_000; long[] arr new long[size]; for (int i 0; i size; i) { arr[i] ThreadLocalRandom.current().nextLong(1, 100); } // 單線程直接求和 long start System.nanoTime(); long serialSum 0; for (long v : arr) { serialSum v; } long serialCost System.nanoTime() - start; // 默認(rèn)并行度 ForkJoinPool pool new ForkJoinPool(); start System.nanoTime(); long parallelSum pool.invoke(new SumTask(arr, 0, arr.length)); long parallelCost System.nanoTime() - start; pool.shutdown(); System.out.println(serialSum serialSum); System.out.println(parallelSum parallelSum); System.out.printf(serial cost : %.2f ms%n, serialCost / 1_000_000.0); System.out.printf(parallel cost : %.2f ms%n, parallelCost / 1_000_000.0); } }注意上面用了個(gè)小技巧拆任務(wù)時(shí)只fork一邊另一邊在當(dāng)前線程執(zhí)行。這樣設(shè)計(jì)的好處我在前面提過——避免當(dāng)前線程傻等同時(shí)減少隊(duì)列槽位被無關(guān)子任務(wù)占滿的可能。你會(huì)在很多標(biāo)準(zhǔn)實(shí)現(xiàn)里看到寫成SumTask left new SumTask(...); SumTask right new SumTask(...); invokeAll(left, right);這也可以。兩種寫法其實(shí)是同一個(gè)策略的不同表達(dá)。invokeAll(left, right)內(nèi)部做的事就是先fork一個(gè)再在當(dāng)前線程執(zhí)行另一個(gè)手動(dòng)寫出來更好展示背后邏輯理解框架的人看了也不會(huì)覺得突兀。3.3 性能對比與數(shù)據(jù)分析我實(shí)測幾次取中間值結(jié)果大致是這樣數(shù)組長度100萬數(shù)值范圍1-99執(zhí)行方式耗時(shí)約說明單線程for循環(huán)2.1 ms基準(zhǔn)值最樸素方式Fork/Join8并行度閾值10萬1.4 ms約1.5倍提升符合預(yù)期Fork/Join8并行度閾值1萬1.2 ms拆得更細(xì)提升略多Fork/Join8并行度閾值1002.8 ms拆得太細(xì)性能反降Fork/Join并行度2閾值10萬3.0 ms并行度不足接近串行有幾個(gè)值得聊的點(diǎn)。差距為什么只有1.5倍而不是8倍這很正常。求和這種任務(wù)是典型的高帶寬內(nèi)存密集型任務(wù)單線程for循環(huán)已經(jīng)能非常有效地把CPU緩存和內(nèi)存帶寬吃滿了。把任務(wù)拆到多個(gè)線程并行其實(shí)是在跟同一個(gè)內(nèi)存帶寬搶資源收益自然有限。換成純CPU計(jì)算任務(wù)比如斐波那契、加密運(yùn)算、復(fù)雜數(shù)學(xué)公式并行度高帶來的加速比會(huì)好看得多。這告訴我們不是所有任務(wù)都適合Fork/Join計(jì)算密度越高的任務(wù)越能體現(xiàn)出框架價(jià)值。閾值的影響為什么會(huì)呈“倒U型”曲線波動(dòng)來自三個(gè)開銷源的此消彼長任務(wù)對象創(chuàng)建開銷、線程調(diào)度與隊(duì)列競爭開銷、任務(wù)合并開銷。閾值太大拆出來的任務(wù)少并行度利用不充分閾值太小任務(wù)對象太多GC和CAS都成了瓶頸。后期我做對比時(shí)發(fā)現(xiàn)當(dāng)閾值等于1萬時(shí)百萬數(shù)組只拆了大概7層就到葉子了任務(wù)是128個(gè)符合8核并行能力閾值調(diào)到100時(shí)任務(wù)直接上萬GC暫停肉眼可感。盡量讓任務(wù)數(shù)量保持在并行線程數(shù)的整數(shù)倍附近是比較穩(wěn)妥的選擇。3.4 不只是寫代碼Fork/Join在JDK里的“隱藏應(yīng)用”如果你覺得Fork/Join只能用來寫求和這類私有工具那就低估它了。你在日常開發(fā)里很可能已經(jīng)間接用過它只是完全沒意識(shí)到。**Arrays.parallelSort()底層就用了一個(gè)叫ForkJoinPool.commonPool()的公共池來并行做排序。Stream.parallel()的默認(rèn)執(zhí)行線程池也是這個(gè)公共池只不過嚴(yán)格來說它是Java流的并行實(shí)現(xiàn)底層主要靠Spliterator拆分任務(wù)最終會(huì)借助Fork/Join來完成子任務(wù)的執(zhí)行。CompletableFuture**里的異步鏈路也有Fork/Join的影子。你可以做一個(gè)實(shí)驗(yàn)用Stream的parallel()對一個(gè)百萬數(shù)組求和再看任務(wù)列表里線程名你會(huì)發(fā)現(xiàn)線程前綴是ForkJoinPool.commonPool-worker-x用的就是公共池。這驗(yàn)證了一件事——標(biāo)準(zhǔn)庫并沒有給Stream另起爐灶而是復(fù)用了Fork/Join的調(diào)度體系。這也從側(cè)面說明Fork/Join不是小眾玩具而是Java并發(fā)工具箱里被官方重用的大件。4. 常見問題與排查技巧實(shí)錄4.1 性能不升反降問題出在哪Fork/Join寫著簡單但跑起來“變慢”是新手最常見的事故。我把這種問題總結(jié)成三句話第一任務(wù)拆得不夠粗。這是默認(rèn)閾值過高導(dǎo)致的。如果你把百萬數(shù)組求和閾值設(shè)成50萬那任務(wù)只被拆一次一半任務(wù)在一個(gè)線程上跑最終性能約等于單線程看不出任何加速。第二任務(wù)拆得太細(xì)GC壓力爆炸。當(dāng)一個(gè)任務(wù)拆出來的對象數(shù)以萬計(jì)時(shí)JVM開始頻繁Minor GCGC本身要暫停所有工作線程你并行計(jì)算的收益全被暫停耗掉了。這時(shí)候性能曲線會(huì)掉頭向下比你不用Fork/Join還慢。唯一的解法就是調(diào)大閾值讓任務(wù)數(shù)回歸到可控范圍。第三并行度設(shè)置不匹配。給你CPU核數(shù)為8的機(jī)器設(shè)并行度為16線程多了切換開銷反而上升設(shè)成2并行度不夠空閑核在嘆氣。想要精確匹配可以先用Runtime.getRuntime().availableProcessors()獲取物理核數(shù)再根據(jù)任務(wù)CPU/IO比例調(diào)整。排查這類性能問題時(shí)我的順序是先看閾值然后看并行度再看任務(wù)拆分是否合理最后用jvisualvm看GC曲線。大多數(shù)“我Fork/Join好慢”的問題最終都會(huì)落到“我閾值設(shè)置不合理”這五個(gè)字上。4.2 任務(wù)不執(zhí)行或線程全部阻塞這個(gè)現(xiàn)象很經(jīng)典程序啟動(dòng)后某些任務(wù)一直不跑有的任務(wù)卡在join上出不來。通常原因有兩個(gè)。原因一任務(wù)沒有使用fork()而是直接互相join()。當(dāng)線程A執(zhí)行任務(wù)甲甲需要等子任務(wù)乙的結(jié)果但你只是rightResult right.get()沒有先fork——這等于讓當(dāng)前線程空等一個(gè)從未提交執(zhí)行的任務(wù)死鎖就這樣產(chǎn)生了。正確做法是fork之后調(diào)用join()或者用invokeAll()讓當(dāng)前線程在join時(shí)能反過來執(zhí)行被等待任務(wù)打破相互等待的循環(huán)。原因二在自定義的ForkJoinPool里寫了阻塞調(diào)用把池里所有工作線程都占滿了。比如你池里只有8個(gè)線程但有16個(gè)任務(wù)在等待某個(gè)外部資源數(shù)據(jù)庫連接、Redis、鎖8個(gè)工作線程全部處于阻塞狀態(tài)剩下8個(gè)任務(wù)永遠(yuǎn)得不到執(zhí)行機(jī)會(huì)。這個(gè)問題凡是線程池都會(huì)遇到但Fork/Join尤其容易忽視因?yàn)樗墓ぷ骶€程數(shù)量通常比較固定。我自己的習(xí)慣是如果任務(wù)里存在不可控的IO阻塞就不要用Fork/Join至少不要用并行度等于CPU核數(shù)的默認(rèn)池。解決這類問題可以先用jstack看線程卡在哪如果看到一片F(xiàn)orkJoinPool管理線程處于WAITING狀態(tài)基本就能鎖定問題類型了。4.3 工作竊取引發(fā)的CPU飆高還有一類詭異問題任務(wù)全部完成了join()都返回了但CPU占用還是居高不下。有人懷疑是死循環(huán)但線程棧里看不到業(yè)務(wù)線程全是ForkJoinPool的工作線程。這大概率是碰到了公共池線程饑餓的變體。工作線程在處理完隊(duì)列任務(wù)之后會(huì)進(jìn)入awaitWork()阻塞等待新任務(wù)喚醒。正常情況下它應(yīng)該掛起但如果池里設(shè)置了commonMaxSpares公共池備用線程上限或合并了大量長尾任務(wù)它的喚醒機(jī)制可能會(huì)讓部分線程頻繁空轉(zhuǎn)CPU曲線就被“假活”拉高了。排查方法很簡單用jstack看那些ForkJoinPool線程如果大量處于RUNNABLE狀態(tài)且堆棧都指向同一個(gè)scan()方法那就是它在空轉(zhuǎn)等待池里塞入新任務(wù)。真遇到這種情況不需要太慌張。大多數(shù)場景下把自定義池的awaitQuiescence()或shutdown()好好調(diào)一調(diào)就行如果沒有特殊需求直接使用默認(rèn)公共池讓JDK自行管理線程生命周期反而更省心。4.4 避坑清單幾個(gè)值得牢記的使用習(xí)慣總結(jié)一下我踩過坑之后沉淀下來的使用原則也算是一份速查表檢查項(xiàng)推薦做法反面典型閾值先從大往小調(diào)觀察性能拐點(diǎn)一開始就設(shè)為1任務(wù)對象爆炸并行度CPU密集型設(shè)為核數(shù)IO型調(diào)大1-2倍盲目設(shè)置64、128任務(wù)拆分優(yōu)先invokeAll或fork一半、本地執(zhí)行一半把所有子任務(wù)都fork出去阻塞操作避免在Fork/Join任務(wù)中做外部IO在任務(wù)里查數(shù)據(jù)庫異常處理join()可能拋出CancellationException要捕獲處理以為get()一定成功公共池直接使用ForkJoinPool.commonPool()就行它是全局的每個(gè)模塊都new一個(gè)池子還有個(gè)小技巧Fork/Join的invoke()返回的是第一個(gè)被提交的任務(wù)結(jié)果但如果你調(diào)動(dòng)的是多個(gè)獨(dú)立任務(wù)最好還是拆分之后各自維護(hù)Future或者用一個(gè)匯總?cè)蝿?wù)包住所有子任務(wù)免得把不同階段的邏輯混在一棵樹上。另外說個(gè)很實(shí)際的體會(huì)——Fork/Join的調(diào)試比普通多線程容易一截因?yàn)槿蝿?wù)結(jié)構(gòu)天生是樹任務(wù)棧的父子關(guān)系可以畫出來。我過去排查一個(gè)復(fù)雜并行查詢問題時(shí)就是用日志把每個(gè)子任務(wù)的fork/join時(shí)間打印出來根據(jù)時(shí)間線樹狀結(jié)構(gòu)一眼就看出了瓶頸在哪個(gè)子分支上。如果你要把這份經(jīng)驗(yàn)帶進(jìn)團(tuán)隊(duì)協(xié)作建議把任務(wù)拆分時(shí)的start和end也打出來調(diào)試時(shí)能把問題定位到具體的數(shù)組片段節(jié)省大量翻日志的時(shí)間。5. 從實(shí)戰(zhàn)到進(jìn)階這幾類任務(wù)建議用Fork/Join重寫5.1 數(shù)據(jù)統(tǒng)計(jì)與聚合類任務(wù)最典型的就是批量日志統(tǒng)計(jì)、BI報(bào)表的DataFrame聚合、多維指標(biāo)累加。這類任務(wù)規(guī)模大、數(shù)值計(jì)算多、各維度之間天然沒有依賴非常適合用Fork/Join切分到幾十個(gè)子任務(wù)并列計(jì)算最后再做匯總。我曾經(jīng)把一個(gè)單線程跑3秒的統(tǒng)計(jì)邏輯用Fork/Join拆到8線程后壓到800毫秒以內(nèi)效果非常直觀。5.2 遞歸遍歷與目錄解析文件目錄遍歷是另一個(gè)高頻場景統(tǒng)計(jì)某個(gè)大目錄下所有文件夾大小、搜索特定類型文件數(shù)量。每個(gè)子目錄天然就是一個(gè)子任務(wù)不需要額外設(shè)計(jì)拆分邏輯RecursiveAction正好派上用場。不過要注意目錄遍歷里別在任務(wù)里直接做打印輸出會(huì)頻繁搶鎖打印獨(dú)占鎖的大坑我踩過一次。5.3 分治算法重寫歸并排序與快速排序歸并排序和Fork/Join是天生一對。單線程歸并排序?qū)κf級(jí)數(shù)據(jù)已經(jīng)很快但百萬級(jí)以上時(shí)并行歸并的優(yōu)勢會(huì)逐漸體現(xiàn)。代碼結(jié)構(gòu)本質(zhì)上就是invokeAll(left, right)然后等待兩邊排序完成后合并?？焖倥判蛞差愃泼看芜x定基準(zhǔn)把數(shù)據(jù)一分為二左右分區(qū)互不干擾并行化以后的分區(qū)操作可以讓大數(shù)組排序吞吐量提升一截。但這里要給你潑盆冷水別為了一道排序題把整個(gè)系統(tǒng)重構(gòu)成Fork/Join。JDK已經(jīng)提供了Arrays.parallelSort()底層就是Fork/Join只要你確認(rèn)自己的數(shù)據(jù)結(jié)構(gòu)和排序需求滿足它的前置條件直接用就好。自己手寫并行排序多數(shù)情況下只適合教學(xué)學(xué)習(xí)或特種算法定制。6. 寫在最后我這個(gè)老用戶的一點(diǎn)心得Fork/Join框架上手不難難在能不能正確衡量“該不該用它”。我自己用過很多輪之后最大的感受是它解決的是結(jié)構(gòu)化分治任務(wù)的并行問題不是所有多線程任務(wù)的銀彈。你一定要先判斷自己的任務(wù)是否符合“可遞歸拆、子任務(wù)獨(dú)立、結(jié)果可合并”這三個(gè)特征再?zèng)Q定入手。參數(shù)調(diào)優(yōu)不要靠猜靠“分而治之”的辦法固定其他變量只動(dòng)閾值跑一組對比再固定閾值只動(dòng)并行度跑一組對比。每次記錄熱度和耗時(shí)曲線自然告訴你最佳工作點(diǎn)在哪。學(xué)習(xí)階段多寫幾個(gè)小Demo比閱讀十篇原理文章有用得多像合計(jì)求和、數(shù)組最大值、遞歸目錄統(tǒng)計(jì)每一個(gè)都能幫你把fork、join、invokeAll、工作竊取之間的關(guān)系揉進(jìn)手感里。最后再分享一個(gè)小技巧寫給團(tuán)隊(duì)用的通用并行工具時(shí)務(wù)必把閾值和并行度做成可配置參數(shù)而不是常量寫死在類里。這樣換機(jī)器、換數(shù)據(jù)規(guī)模時(shí)不用改代碼重新編譯直接通過配置調(diào)整就能快速適配。這個(gè)習(xí)慣讓我在跨平臺(tái)部署時(shí)少走了很多彎路真心建議所有用Fork/Join做組件化開發(fā)的人都保留。