应用ForkJoin –从最佳到快速
到目前為止，JDK 7已很好地掌握在開發人員手中，并且大多數人都聽說過ForkJoin，但是沒有多少人有時間或機會去嘗試它。
它引起了，并且可能仍然引起一些混亂，與普通線程池有什么不同。 [1]
我在本文中的目標是通過一個代碼示例來呈現一個更詳細，但仍然簡單的ForkJoin使用示例。
我計時并測量串行 ， 線程池和ForkJoin方法的性能 。
這是github的前期內容： https : //github.com/fbunau/javaadvent-forkjoin
實際問題
想象一下，我們的系統中有某種組件可以在每毫秒時間內保持股票的最新價格。
這可以作為整數數組保存在內存中。 （如果我們以bps為單位）
該組件的客戶進行如下查詢：價格最低的是time1和time2之間的時間點？
這可以是自動算法，也可以只是GUI中進行矩形選擇的人。
示例圖像中有7個查詢
讓我們還想象一下，我們從一個Task中批處理的客戶端中獲得了許多這樣的查詢。
可以將它們分批處理，以減少網絡流量和往返時間。
我們有組件可能獲得的不同大小的任務，最多10個查詢（帶有GUI的人），最多100個，..最多1 000 0000個（某種自動化算法）。 我們的組件有很多這樣的客戶，每個客戶都會產生不同大小的任務。 請參閱Task.TaskType
核心問題與解決方案
我們必須解決的核心問題是RMQ問題。 這是維基百科[2] ：
“鑒于從一組有序集合（例如數字）中獲取的對象數組，從i到j的范圍最小查詢（或RMQ）要求最小元素在子數組A[i, j] ?！?
“例如，當A = [0, 5, 2, 5, 4, 3, 1, 6, 3]時，則A[3, 8] = [2, 5, 4, 3, 1, 6]的范圍最小查詢的答案A[3, 8] = [2, 5, 4, 3, 1, 6]是7 ，因為A[7] = 1 ”
存在一種用于解決該問題的有效數據結構，稱為“細分樹”。
我不會對此進行詳細介紹，因為這篇經典的Topcoder文章[3]對此進行了很好的介紹。 對于ForkJoin示例，這本身并不重要，我選擇它是因為它比簡單的總和更有趣，并且其本質是基于fork-join的精神。 它劃分要計算的任務，然后加入結果！
數據結構具有O(n)初始化時間和O(log N)查詢時間，其中N是每個時間單位值數組的價格中的元素數量。
因此，任務T包含M要進行的查詢。
在學術計算機科學方法中，您只是說我們將使用這種高效的數據結構處理每個任務，而復雜性將是：
您再沒有比這更有效率的了！ 是的，在理論上是馮·諾依曼機器上，但是您可以在實踐中。
一個容易引起混淆的是，因為O(n/4) == O(n) ，所以在編寫程序時，常數因子不計算在內，但確實如此！
停下來想一想，等待10或40分鐘/小時/年是否一樣？
平行進行
因此，考慮要解決的問題，我們如何使其更快？ 由于現在每個計算設備都有更多的計算核心，因此讓我們充分利用它們并立即執行更多操作。
我們可以使用Fork Join框架輕松地做到這一點。
我最初很想嘗試一下RMQ數據結構并并行執行它的操作。 我攻擊了本來已經是log N的東西。但這是一個很大的失敗，對于調度程序來說，管理如此短時間的邏輯開銷太大。
答案是最終攻擊M_i恒定因子。
線程池
在介紹如何應用ForkJoin解決方案之前，讓我們想象一下如何應用線程池。 請參閱： TaskProcessorPool.java
我們可以有4名工作人員的池，當我們有一個任務要做時，我們將其添加到隊列中。 一旦有工作人員可用，它將從隊列的開頭檢索待執行的任務，然后執行該任務。
盡管這對于具有相同大小的任務是很好的，并且大小相對中等且可預測，但是當要執行的任務大小不同時，就會遇到問題。 一名工人可能會因長期運行的任務而煩惱，而其他工人則無所事事。
在此圖像中，如果不將更多任務添加到隊列中，則線程池將在4個時間單位內完成16個可能的工作單位中的9個（效率為56％）
叉連接
當您位于問題域中時，可以將要解決的任務拆分為較小的任務，因此前叉聯接很有用。
fork-join池的特殊之處在于它是一個竊取工作的線程池。
每個工作線程都維護任務的本地出隊。 在執行新任務時，可以執行以下任一操作：
- 將任務拆分為較小的任務
- 如果任務足夠小，則執行任務
當一個線程的出隊中沒有本地線程時，它將“竊取”，從另一個隨機線程的隊列后面彈出任務，并將其放入自己的線程中。 此任務尚未拆分的可能性很高。 因此，他將有很多工作要做。
與線程池相比，它們可以將現有任務拆分為較小的線程，而不是其他線程等待某些新工作，并幫助另一個線程處理較大的任務。
這是Doug Lea的原始論文，提供了更詳細的解釋： http : //gee.cs.oswego.edu/dl/papers/fj.pdf
回到我們的示例中，可以將一大批操作分為幾批較少數量的操作。 請參閱： TaskProcessorFJ.java
大多數問題都具有像這樣的線性運算，它不一定是特殊的并行問題，對此我們需要應用專門的并行算法來利用處理器上的核心。
你分多少錢？ 您拆分任務，直到達到通常不再有意義的閾值為止。 例子：（拆分+獲得工作的線程+上下文切換比實際執行任務更為重要）
對于大型XXL，我們必須執行1000000個查詢操作。 我們可以將其分為2 500000個操作任務，并并行執行。 500000仍然很大嗎？ 是的，我們可以進一步拆分。 我選擇了一組10000個操作作為閾值，在該閾值下沒有任何拆分用途，我們可以在當前線程上執行它們。
Fork join并不會預先拆分所有任務，而是通過它進行工作。
績效結果
在干凈重啟后，我對i5-2500 CPU @ 3.30GHz上具有4核/ 4線程的i5-2500 CPU的每種處理器實現進行了4次迭代。
結果如下：
結論
即使您選擇了正確的最佳數據結構，它也不會很快，直到您使用所有的資源。 即利用所有核心
在某些問題域中，ForkJoin絕對是對線程池的改進，值得探索在哪里可以應用它，我們將看到越來越多的并行代碼。
您今天可以購買這種處理器 ，即12核/ 24線程。 現在，我們只需要編寫軟件來利用我們擁有的，將在將來獲得的出色硬件即可。
代碼在這里： https : //github.com/fbunau/javaadvent-forkjoin如果您想使用它的話
感謝您的寶貴時間，如果發現任何錯誤或需要添加的內容，請刪除一些評論。
翻譯自: https://www.javacodegeeks.com/2013/12/applying-forkjoin-from-optimal-to-fast.html
總結
以上是生活随笔為你收集整理的应用ForkJoin –从最佳到快速的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 一种替代的多生产者方法
- 下一篇： RMI强制Full GC每小时运行一次