确实到了并发盛行的时期了， 我觉得最重要的原因还是多核处理器及其硬件体系的日趋成熟， 并且成本摊薄到大众价格了。

　　j.u.c 包主要是为了性能来的， 其设计其实不如Java传统的内置同步机制(synchronized块和方法， 以及 Object.wait(); Object.notify())优雅， 但是传统同步机制的最大弊病就是不区分共享同步(一般是并发的读操作) 与 互斥同步 (一般是写操作)， 所有同步都只能是完全排他的，只要有并发写的可能性就不得不把全部读操作也互斥同步，从而丧失并发读取的可能性。 这跟大多数应用的并发模式(读远多过于写)存在严重偏离， 以至于硬件新增长出来的并发能力在普通应用中将被大部分折扣掉， 这个是不可能被应用软件开发市场容忍的。 同时传统同步机制也有一些灵活性方面的弊病， 比如 Object.wait(); Object.notify(); 必须在该对象的同步块内执行 (否则会抛IllegalMonitorStateException)， 并且一个对象只能wait/notify一个状态。 j.u.c 类通过让一个Lock可以建多个Condition去wait/notify增强了灵活性。

　　但是抛开性能和灵活性不管， 如果传统Java同步机制能够实现的话， 它还是更优雅的， 你永远没法写出加锁以后忘记解锁的代码， 因为不匹配的 {} 会产生编译错误。 同时已经有相当多的科研力量， 投入到降低传统同步机制在单线程情况下最小化同步开销的研发工作中， 使得现在的JVM执行同步块时， 如果是单线程情况， 效率非常高。 不过作为代价， 多线程情况下却要比合理想像到的性能更低。

　　Excector、ScheduleExecutorService、Future、BlockingQueue这些其实就是目前构建应用服务器的Building Block， 现在作为标准类库提供， 有利于发展出更优秀的Java框架， 但是主流应用开发是否也会架构于这些相对基层的工具库之上， 我个人还是抱观望态度。

　　j.u.c 库确实比原来的 dl.u.c 库性能会高， 因为 dl.u.c 是构建在Java传统同步机制之上的， 而 j.u.c 是将其移植到了最新 JVM 的并发支持特性之上 (通过 sun.misc.Unsafe 与Hotspot VM打交道， 直接产生宿主CPU支持的原子内存访问指令)， 可以认为是从软件实现升级成了硬件实现， 其性能差别可想而知。

　　面向分布式并行计算/并发的应用程序设计方向上， 我在搞一个Apache协议开源的框架， 叫 Hosting Based Interfacing， 目前已经实现了 Java 的服务器端和 Flex/ActionScript3 的客户端。 大家有兴趣不妨看看 http://hbi.googlecode.com， 如果有时间精力一起研究发展当然最好了。