资讯频道 → 企业架构
阅读更多

10顶
2踩

企业架构

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

2007-09-25 01:37 by 见习记者 歆渊 评论(3) 有12446人浏览
Java 设计模式 大众软件 大众硬件

声明：ITeye资讯文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！

最近我也是在涉及并发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, 如果有时间精力一起研究发展当然最好了.
10
顶
2
踩
评论 共 3 条 请登录后发表评论
3 楼 young7 2014-06-27 13:20
除非传统的同步方式不能满足需求，否则没有理由去用juc里面的东西，《并发编程实践里》说的
2 楼 cha_bill 2014-02-25 17:37
传统的内置锁也是有优点的，起码代码写起来不凌乱, 以后由jdk1.6内置锁的性能可以看出未来版本的jdk肯定会继续优化内置锁的。
在我看来外置锁除了性能之外，更加的面向OO。在业务相对复杂的并发系统中，外置锁的优势是不言而喻的。
1 楼 huhang1986 2011-04-26 10:20
所有同步都只能是完全排他的,只要有并发写的可能性就不得不把全部读操作也互斥同步,从而丧失并发读取的可能性. 这跟大多数应用的并发模式(读远多过于写)存在严重偏离,

精辟！

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

Global site tag (gtag.js) - Google Analytics