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