確實到了并發盛行的時期了, 我覺得最重要的原因還是多核處理器及其硬件體系的日趨成熟, 并且成本攤薄到大眾價格了.
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執行同步塊時, 如果是單線程情況, 效率非常高. 不過作為代價, 多線程情況下卻要比合理想像到的性能更低.
文章來源于領測軟件測試網 http://www.kjueaiud.com/
