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

评论

22 楼 ken1984 2007-11-16  

读写锁,这个概念几十年前就有了,*nix下应用的很广泛。JAVA如果能支持那是更好的，第三方库就算了吧，越搞越多库，一个项目数不清的开源库，简直就是个糟糕的项目。

21 楼 whyandwhat 2007-10-31  

可惜无法下载源码看看写得怎样。。
不然，我参与进来。。。。。。

20 楼 totobacoo 2007-10-26  

使用 j.u.c 的工程在并发控制的代码编写上，明显比传统的 synchronized wait notify 组合来得简单得多

19 楼 cuijunrong 2007-10-24  

不知道LZ的Hosting Based Interfacing和移动代理的差异。个人觉得非常相像。

18 楼 qingyuan914 2007-10-16  

<br/>
<strong>phantomhu 写道：</strong><br/>
<div class='quote_div'>
<p><font>明年CPU都是4核主打了， 并发是必然的，而且现在的web开发很多也都采用的ajax很多ajax的解决方案也都使后台人员只需要关注把xml传回，使用new io并发来减少堵塞的情况的出现。传统线程模式在交互上也有诸多不便</font></p>
</div>
<br/>
<br/>
<br/>
<br/>
并发和并行都没分清还说什么并发是必然的,搞不懂你们在说什么呢.

17 楼 qingyuan914 2007-10-16  

<p>“并行”是指无论从微观还是宏观，二者都是一起执行的，就好像两个人各拿一把铁锨在挖坑，一小时后，每人一个大坑。多核处理器适用于并行。 而“并发”在微观上不是同时执行的，只是把时间分成若干段（时间片），使多个进程快速交替的执行，从宏观外来看，好像是这些进程都在执行，这就好像两个人用同一把铁锨，轮流挖坑，一小时后，两个人各挖一个小一点的坑，要想挖两个大一点得坑，一定会用两个小时。 <br/>
</p>

16 楼 phantomhu 2007-10-11  

<p><font>明年CPU都是4核主打了， 并发是必然的，而且现在的web开发很多也都采用的ajax很多ajax的解决方案也都使后台人员只需要关注把xml传回，使用new io并发来减少堵塞的情况的出现。传统线程模式在交互上也有诸多不便</font></p>

15 楼 offspring 2007-10-11  

就是多线程呗，多线程没什么好书，学得也是二乎乎的。

14 楼 Godlikeme 2007-10-11  

galaxystar 写道

j.u.c中, 为了解决大量读操作, 少量写操作而致使全同步的性能低下问题, 提出了ReadWriteLock的概念.

当读取操作时, 使用读锁, 写入操作时, 用写锁.

普通读取操作, 它将忽略同步, 性能与不采用锁相差无几.
当写操作触发时, 才迫使读锁进行工作, 此时, 读取操作将被等待.

这种机制也是从一定程度上解决了我们常见的问题.

至于用CAS实现非阻塞算法, 与原子变量, 感觉意义不大了.
毕竟, 全用原子变量的程序, 逻辑更难理解.

很古老的概念了，很古老就有实现了。。。

13 楼 sunhengxin 2007-10-10  

引用

至于用CAS实现非阻塞算法, 与原子变量, 感觉意义不大了.

一个钻了　也说这话？

12 楼 galaxystar 2007-10-09  

j.u.c中, 为了解决大量读操作, 少量写操作而致使全同步的性能低下问题, 提出了ReadWriteLock的概念.

当读取操作时, 使用读锁, 写入操作时, 用写锁.

普通读取操作, 它将忽略同步, 性能与不采用锁相差无几.
当写操作触发时, 才迫使读锁进行工作, 此时, 读取操作将被等待.

这种机制也是从一定程度上解决了我们常见的问题.

至于用CAS实现非阻塞算法, 与原子变量, 感觉意义不大了.
毕竟, 全用原子变量的程序, 逻辑更难理解.

11 楼 zgd 2007-09-28  

说的太浅。。。

10 楼 timerri 2007-09-28  

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

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

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

9 楼 想想就是这样 2007-09-28  

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

8 楼 SunMicro 2007-09-28  

引用

Synchronous programming habit will be broken, programmers will have to consciously know that some blocks of their code will run asynchronously at environments (domains) other than the local application they are developing.

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

javavsnet 写道

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

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

7 楼 javavsnet 2007-09-28  

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

6 楼 lordhong 2007-09-26  

牛人。。。无比葱白中。。。

5 楼 歆渊 2007-09-25  

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

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

4 楼 歆渊 2007-09-25  

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

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

3 楼 歆渊 2007-09-25  

概括的说, 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上同时编辑一个文档的所有协作用户可以通过即时消息协同工作.