確實到了並發盛行的時期了, 我覺得最重要的原因還是多核處理器及其硬件體系的日趨成熟, 並且成本攤薄到大眾價格了.
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支持的原子內存訪問指令), 可以認為是從軟件實現升級成了硬件實現, 其性能差別可想而知
