java 并发包_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 包中).