谈谈JAVA并发程序设计现状和发展前景

最新推荐文章于 2024-10-01 18:51:18 发布

lilingshan003

最新推荐文章于 2024-10-01 18:51:18 发布

阅读量312

点赞数

文章标签： java 应用服务器 jvm 多线程框架工具

本文链接：https://blog.csdn.net/lilingshan003/article/details/5982999

版权

确实到了并发盛行的时期了, 我觉得最重要的原因还是多核处理器及其硬件体系的日趋成熟, 并且成本摊薄到大众价格了. 　　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 支持的原子内存访问指令), 可以认为是从软件实现升级成了硬件实现, 其性能差别可想而知.