我也谈谈JAVA并发程序设计的现状和前景

最近我也是在涉及并发Java方面的东西, 说说我的心得.

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

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, 如果有时间精力一起研究发展当然最好了.

j.u.c最有价值的应当是引入了非阻塞算法和原子变量吧，我相信如果不是写底层设施，做应用开发的以后会越来越多使用j.u.c提供的框架，j.u.c提供的新的并发类无论从性能上，还是易用性上都超过了传统的同步机制。重要的应当是，无论使用传统并发机制，还是新的标准库，对于并发原理以及应用原则的掌握才是根本吧，就算是使用j.u.c仍然是会写出很糟糕的并发代码。

对分布式和并行计算研究还很浅，看了下HBI的简介，但未能理解透，介绍中提到的：

能简单介绍下实现原理的吗？如何做到上面所说的
make all code executed natively and locally whereas asynchronously

概括的说, HBI就是把分布的软件组件都设计为一个一个本地的Domain, 然后按照需要某些Domain被动接受HBI线路连接, 某些主动建立HBI线路连接, 但是原则上都是对等的, 没有服务端/客户端之分.

HBI线路是对等的异步双向双工的二进制数据通道(通过Plain Socket或者HTTP包装的双向数据流实现), 也就是说两个方向上的通信没有主次之分, 不互相依赖(不用同步等待特定传输状态), 可以同时进行.

在HBI线路上传输的是 Task Agent Life Script, 具体讲就是一种二进制优化的脚本, 包括无参构造Task Agent对象, 调用构造好Task Agent对象的特定方法(可以带参数), 和完成Task Agent对象任务 3 种脚本指令. 由发送方Domain提供包装类, 让应用程序通过调用包装类对象透明产生出 Task Agent Life Script, 然后经由HBI线路发送到目标Domain. 目标Domain则履行东道, 通过ThreadPool等等方式, 解释执行接收到的 Life Script.

由脚本调用的Task Agent对象的方法必须基于对方Domain的Native语言/平台和环境实现. 这些Native的方法, 包括构造方法, 和完成任务的方法, 在目标Domain的环境中本地执行, 执行过程中可以向它的发起Domain回送其他的Task Agent对象, 以达到异步通知或者异步更新数据的目的.

协调性质的Domain可以设计自身的对象模型和逻辑, 让域对象的状态变更实时翻译成若干特定的Task Agent Life Script, 即时发送到需要通知到的其他Domain, 特别是用户界面性质的Domain去, 直接支持实时的协作能力. 类似于Google Docs上同时编辑一个文档的所有协作用户可以通过即时消息协同工作.

一个Domain实现可以选择缓存接收到的Task Agent Life Script, 这样当发生一些有可能重试的异常时, 比如数据库乐观事务提交被强制回滚, 就可以透明的重试这个Life Script特定的次数.

数据服务性质的Domain提供这个能力尤其有用, 可以利用MVCC等乐观锁机制提高并发性能的同时简单的降低强制回滚的次数, 缓解强制事务回滚造成的用户体验损失. 如果继续深入发展, 则有可能类似于多处理器利用原子内存访问(CAS)进行同步的相同原理, 衍生出并发性高, 而且不会强制回滚的某些系统来.

目前为止的HBI实现还需要发起Domain在目标Doman环境进行Task Agent类代码的静态部署, 下一步的实现, 会利用Java, Flash等环境的动态代码部署能力, 基于密钥签名, 或者SSH线路连接的代码专用通道的方式实现动态部署.

安全性要求高的场合, Domain之间的线路连接有必要通过 SSH 的机制进行连接鉴权和通信加密, 进而某台服务器即使有非特权帐户被攻破, 也没法通过伪造或者监听本机网络通信而侵入Domain系统. 如果在这个SSH连接上增加一个专用SSH通道用来动态部署发起Domain的远程代码, 非常简单, 更安全, 且效率比HTTP, FTP等方式更高.

楼主为什么先实现了Flex/ActionScript3 的客户端？是否目前对Flex/ActionScript3客户端的需求比对Java客户端的需求更多

歆渊丰富了google上面的介绍后，显得有吸引力多了! 正研究代码



我一直把flex看作最好的UI解决方案，AS3,强大的IDE,丰富的文档……。

我 认为java在中国编程语言中 发展的前景是美好的，就是不知道以后还会有什么新的语言 来代替她！

j.u.c确实不错，控制更容易，可是相对于原先的线程池方式，性能又会有多大提高呢？

如果没有性能的提高，我宁愿使用原先的代码，换种方法造轮子太浪费了。

对于新提供的同步工具，有些情况下用一下还是不错的。不过这同步的问题，用的方式越多就会越难把握，这是双刃剑....