1. 程式人生 > >Java7 java.util.concurrent 併發包計劃

Java7 java.util.concurrent 併發包計劃

原文連結譯文連結,譯者:DOM,校對:鄭旭東

 Java7釋出版本的具體計劃應該開始了,之前經常有人問我們關於JSR166的後續計劃包含哪些內容。下面是目前暫定的內容,歡迎提出你們的見 解和意見。 1.Phasers    一個通用的記憶體屏障實現。 2.LinkedTransferQueue (and TransferQueue interface)   一個具有非阻塞,阻塞和同步介面的佇列。 3. ConcurrentReferenceHashMap   併發Hash Map,其鍵和值可以是弱引用或者軟引用。 4. Fences (in java.util.concurrent.atomic)    底層的記憶體屏障實現 5. ForkJoin framework.    (具體見下面)        這些功能的初始版本可以在很多地方看到。Phasers 和 LinkedTransferQueues在JSR166y中, 說明文件還需要再做一些修改,同時Fences API也需要Java虛擬機器的支援。(目前任何Java虛擬機器上實現的Fences API都有效率問題,在Fences API能高效執行之前是沒有多大用處的) 加入這個Fences API也是為了更好的與即將到來的C++0x APIs相對應。        Jason Greene基於ConcurrentHashMap編寫了ConcurrentReferenceHashMap。我想最新的版本應該是在這裡 我們推遲整合ConcurrentHashMap,因為需要等待GC支援Ephemerons(一個弱引用鍵-值鏈的方案)。雖然此舉可以推動其它部門,但我不認為Ephemeron能很快得到支援,所以我們需要考慮在GC不支援Ephemerons情況下完成ConcurrentHashMap。       大多數人都知道目前的ForkJoin 框架有兩部分組成,基本ForkJoin{Pool,Task}框架,以及基於這個基本框架的並行集合(目前只有ParallelArray)。我考慮只把基本框架整合進JDK,把並行集合部分作為非JDK的包繼續開發。這樣做可以避免暴露介面(IntAndLongToInt 等96個介面)和表示式問題(閉包等),而且要把這些加入JDK也需要艱難的討論。推遲加入可以有更多的時間來激勵開發和使用併發集合的包,同時也可以有時間讓IDE,語言擴充套件和另外的JVM語言來支援。        同時我已經開始審閱把ForkJoin和Executor整合起來。ForkJoinPool會實現Executor的服務,ForkJoinTask會實現Future。(使之成為可能的主要思想是讓控制阻塞和建立備用執行緒之間保持併發)。這可以更好的滿足在Fortress and X10使用(這兩種語言編譯後會執行在JVM上)。但它也開始構建人們想要但卻未曾開始著手乾的基礎設施,比如建立一系列迴圈(非 ForkJoin型別),每個迴圈有時候會建立ForkJoin任務。

更多細節將繼續(獲得內部並行維護行之有效會慢),但只增加簡單的基礎框架到java.util.concurrent: 類 ForkJoinPool (類ForkJoinWorkerThread 仍會為高階使用者和效能調優者保留)和 抽象類ForkJoinTask,以及三個子類RecursiveAction,RecursiveTask, AsyncForkJoinAction(最新一次修訂後是為了用來在不提供類的情況下,構建諸如BinaryAsyncAction的類)。

       我會等待你們對這些內容的意見和建議,之後再把這些內容到恰當的地方。(恰當的地方的意思是,我會把這內容整合進JSR66y, 然後加入 java.util.concurrent 包中).