當心多任務設計被濫用

經過合理建立任務（或線程）的方式，能夠有效地提升軟件設計的模塊性。經過讓一個任務關注於某一類事務，有助於簡化任務體函數的實現，以及提升程序的可維護性。另外，多任務在很多情形下，將提升系統的運行效率，由於一個任務在等待所需資源時，另外一個任務能夠利用處理器作更多的事。儘管多任務有它的好處，但使用多任務的「度」很重要。就做者的觀察，多任務設計方法大有被濫用之勢，乃至有的工程師習慣於一作設計就想到運用多任務。出現這種情況的緣由，是由於沒有意識到多任務設計所帶來的問題。

運用多任務的設計方法，每每須要使用到任務同步的方法（互斥鎖、信號量、事件和消息隊列等），以保證多個任務有序地協同工做，以便避免出現競爭問題。可是，使用任務同步的方法並非每一個人都很擅長，乃至即便以爲本身很擅長，也很容易一糊塗就設計出存在競爭問題的代碼。再則，對於大型項目，因爲代碼量的急劇增加，多任務所帶來的競爭問題更加不容易被發現，一旦發生問題就相對嚴重，並且不容易查錯。

任務數量使用得過多，所帶來的另外一個問題是，由於多個任務的存在，將帶來更多的任務切換。也由於任務過多，而使得任務之間的通信開銷更大。總的來講是，有可能形成系統性能問題。

做者也經歷了從大量使用多任務設計到迴歸避免使用多任務的成長曆程，也明白在不少情形下，採用多任務設計的衝動源於賣弄本身具有多任務的編程能力，以及愧疚於不採用多任務會形成系統性能問題。其實，一旦咱們冷靜下來思考多任務設計時會發現，自認爲多任務所帶來的好處，在系統中極可能並非關鍵。另外，咱們也頗有可能沒有考慮採用多任務設計所帶來的不良反作用。

從用戶的體驗來看，一個軟件產品最終必須具有良好的魯棒性，即穩定。不然，不管多麼好的功能特性，產品最終都將被用戶給拋棄。所以，軟件在開發活動中的主旨之一，應是採用容易得到高質量的方法，而不是運用更多的「高科技」。這種策略，容許適當地下降對團隊能力的要求，畢竟，要得到一個能力都很是強的團隊不是一件易事。

做者曾在一個項目中，開發出了一個運行於Linux操做系統之上的、基於TCP套節字的網絡通信框架，採用的是單線程的設計思想。這個框架經過採用select()函數，能夠處理多個套接字的建鏈和通信。在設計的過程當中，由衷地感嘆採用單線程的方式大大地簡化了設計和調試工做。看成者將這一設計思路與一些同事交流時，他們所表現出來的不理解卻截然不同。由於在他們看來，套接字通信不管如何也得考慮用多線程的設計方法。有一點須要交代一下，做者採用單線程的設計方法，也是基於應用場景並不存在大負荷的通信數據。

不管如何，當咱們考慮運用多任務設計時，靜下心來思考一下它所帶來的利與弊，有助於咱們克服魔鬼般的衝動。一旦考慮清楚了應當採用多任務設計，那仍是應當一往無前。

最後，即便是使用更少的任務，也並不妨礙軟件的模塊化設計。由於經過設計，徹底能夠實現模塊與任務相分離，也就是即便不採用多任務，一樣能夠得到良好的軟件模塊化。