谈谈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支持的原子内存访问指令), 可以认为是从软件实现升级成了硬件实现, 其性能差别可想而知.

最新相关文章

• ·J2EE开发技术基础入门
• ·Java和JSP编程应注意的六个常见问题
• ·Web Services的测试模型与代码摘录
• ·当前流行的J2EE WEB应用架构分析
• ·Java初学者必看：Java自动设置环境变量
• ·保存Java程序状态及设置Properties文件
• ·只支持单表映射的持久化框架──EasyDBO
• ·提高J2EE层与数据库层交互操作能力的优势
• ·提高J2EE层与数据库层交互操作能力的优势
• ·只支持单表映射的持久化框架──EasyDBO
• ·开发J2EE应用时应该遵循的几个基本准则
• ·开发J2EE应用时应该遵循的几个基本准则
• ·实例讲解如何用Struts向MySQL中储存图片
• ·J2SE综合：彻底理解JavaHelp结构的好处
• ·讨论手动部署EJB 亲自体验EJB开发流程
• ·J2SE综合－－有关 JAVA 的多线程浅析