大多情況下，並行對複雜度影響過大，並間接導致測試困難---多線程或多進程導致的問題往往是有時發生，有時不發生，一般的測試手段並不足以發現這類問題。
所以原則上應該儘可能不用，除非收益足夠大。或則說在滿足需求的前提下，線程數和進程數應該儘可能少。
以多線程和多進程而論，確定“什麼時候適合使用這種技術”是比“怎麼使用這項技術”困難的多的事情。
現實中人們往往對事件，號誌等同步處理手段關注過多，而對究竟應不應該啟用多線程/進程關注的太少。這裡來簡單做個總結，對於下面這些情境，一般來講啟用多線程/進程是合適的：
- 資料很容易分割，處理不同資料時彼此間沒有什麼互動。比如說：你有10萬個檔案需要處理，每個檔案的處理彼此獨立。這時候顯然要做並行，這樣最終資料處理速度將依賴於並行分布的程度。這好像很簡單，但卻觸發了MapReduce這樣著名的模型(參見《軟體隨想錄》)。在待處理資料持續增長的情形下，如果不啟用並行，那幾乎沒有辦法保證速度不會下降，這並不是單純靠最佳化演算法可以解決的問題。
- 監控裝置響應（連接埠監視也應該屬於這個類別）。這時候我們會希望能及時響應裝置的事件，而不希望裝置上的資料擷取和對資料的處理彼此幹涉。比如：Windows中就單獨建立了Raw Input Thread(RIT)來監控整個系統的鍵盤和滑鼠訊息，而後再分發給各個進程中的線程。（詳見《Windows核心編程》）。
- 最佳化UI響應速度。比如：用文檔編輯器開啟大檔案時，如果不分離UI響應和實際處理，UI會掛起，很典型的應用是進度條的處理。使用了MVC(Model-View-Controller)模式的應用中大多時候可以適用這條，因為很多時候都需要View和Controller總是保持響應。
- 待處理的請求天生就是並行的。比如：當瀏覽不同網站時，不同的網站的顯示會在不同的視窗中處理，這類處理天生就是並行的，既可以用多線程也可以用多進程。客戶-伺服器體系也是這類情形。
- 計算量很大，並且演算法可以分割。有些傳說中的領域（大氣類比、基因工程等）事實上是並行計算的主戰場，比如在展示MPI(Message Passing Interface)的使用時，經常使用的計算π的例子，就是如此。但這離通用軟體開發的距離就有點遠，知之不詳，這裡就不列了。
這個列表應該進一步總結和加長，但限於精力，眼下卻只能列這麼多了。
對於多線程的誤用，在MSDN上可以找到一份很好的總結，這裡提取幾個典型的結果：
- 鎖爭用和順序執行。這時雖然啟用了多線程，但實際執行起來這些線程是串列的。
- 過度訂閱。如果系統的核心數遠少於線程數，同時啟動很多個線程，時間往往會浪費在搶佔上。
- I/O效率低。多線程被用來做頻繁的I/O操作，這會導致很多時間開銷在I/O操作上。
多進程的誤用眼下看到的總結還不多，這裡略過，有經驗的可以幫忙一起總結。
最後加一點關於並行種類的補充資料：
為並行分類並不是很容易的事，這裡只介紹一種最簡單的，依據記憶體架構對並行進行分類的方法。依據記憶體架構，並行可以分為三類：
- Shared Memory: 常說的多線程即是這一類，比較有名的實現是OpenMP。
- Distributed Memory：如果多台PC組合起來進行並行計算那就是這一類。比較有名的實現是MPI。
- Hybrid Distributed-Shared Memory：如果多台PC進行分布，每台PC上還啟用多核，那就是這類。
有人似乎還想進一步區分並行和並發，這就有點微妙了，個人不是很能分的清楚。
