也談Java并發(fā)程序設計的現狀和前景
確實到了并發(fā)盛行的時期了， 我覺得最重要的原因還是多核處理器及其硬件體系的日趨成熟， 并且成本攤薄到大眾價格了。
j.u.c 包主要是為了性能來的， 其設計其實不如Java傳統(tǒng)的內置同步機制(synchronized塊和方法， 以及 Object.wait(); Object.notify())優(yōu)雅， 但是傳統(tǒng)同步機制的弊病是不區(qū)分共享同步(一般是并發(fā)的讀操作) 與 互斥同步 (一般是寫操作)， 所有同步都只能是完全排他的，只要有并發(fā)寫的可能性不得不把全部讀操作也互斥同步，從而喪失并發(fā)讀取的可能性。 這跟大多數應用的并發(fā)模式(讀遠多過于寫)存在嚴重偏離， 以至于硬件新增長出來的并發(fā)能力在普通應用中將被大部分折扣掉， 這個是不可能被應用軟件開發(fā)市場容忍的。 同時傳統(tǒng)同步機制也有一些靈活性方面的弊病， 比如 Object.wait(); Object.notify(); 必須在該對象的同步塊內執(zhí)行 (否則會拋IllegalMonitorStateException)， 并且一個對象只能wait/notify一個狀態(tài)。 j.u.c 類通過讓一個Lock可以建多個Condition去wait/notify增強了靈活性。
但是拋開性能和靈活性不管， 如果傳統(tǒng)Java同步機制能夠實現的話， 它還是更優(yōu)雅的， 你永遠沒法寫出加鎖以后忘記解鎖的代碼， 因為不匹配的 {} 會產生編譯錯誤。 同時已經有相當多的科研力量， 投入到降低傳統(tǒng)同步機制在單線程情況下最小化同步開銷的研發(fā)工作中， 使得現在的JVM執(zhí)行同步塊時， 如果是單線程情況， 效率非常高。 不過作為代價， 多線程情況下卻要比合理想像到的性能更低。
Excector、ScheduleExecutorService、Future、BlockingQueue這些其實是目前構建應用服務器的Building Block， 現在作為標準類庫提供， 有利于發(fā)展出更的Java框架， 但是主流應用開發(fā)是否也會架構于這些相對基層的工具庫之上， 我個人還是抱觀望態(tài)度。
j.u.c 庫確實比原來的 dl.u.c 庫性能會高， 因為 dl.u.c 是構建在Java傳統(tǒng)同步機制之上的， 而 j.u.c 是將其移植到了 JVM 的并發(fā)支持特性之上 (通過 sun.misc.Unsafe 與Hotspot VM打交道， 直接產生宿主CPU支持的原子內存訪問指令)， 可以認為是從軟件實現升級成了硬件實現， 其性能差別可想而知。
面向分布式并行計算/并發(fā)的應用程序設計方向上， 我在搞一個Apache協(xié)議開源的框架， 叫 Hosting Based Interfacing， 目前已經實現了 Java 的服務器端和 Flex/ActionScript3 的客戶端。 大家有興趣不妨看看 http://hbi.googlecode.com， 如果有時間精力一起研究發(fā)展當然了。