1.首先第一步應該是先**審閱，在審閱多執行緒**時，重點要檢查與併發相關的錯誤。
審閱多執行緒**需要考慮的問題：
這裡，列一下我的清單：
併發訪問時，那些資料需要保護？
如何確定訪問資料受到了保護？
是否會有多個執行緒同時訪問這段**？
這個執行緒獲取了哪個互斥量？
其他執行緒可能獲取哪些互斥量？
兩個執行緒間的操作是否有依賴關係？如何滿足這種關係？
這個執行緒載入的資料還是合法資料嗎？資料是否被其他執行緒修改過？
當假設其他執行緒可以對資料進行修改，這將意味著什麼？並且，怎麼確保這樣的事情不會發生？
可測試性設計
通常，如果**滿足一下幾點，就很容易進行測試：
1.每個函式和類的關係都很清楚。
2.函式短小精悍。
3.測試用例可以完全控制被測試**周邊的環境。
4.執行特定操作的**應該集中測試，而非分布式測試。
5.需要在完成編寫後，考慮如何進行測試。
最後乙個因素尤為重要：即使不在寫完**後，去寫測試用例，這也是乙個很好的建議，能讓你在寫**之前，想想應該怎麼去測試它——用什麼作為輸入，什麼情況看起來會讓結果變得糟糕，以及如何激發**中潛在的問題，等等。
例如，當應用設計為乙個多執行緒狀態機時，可以將其分為若干塊。將每個邏輯狀態分開，就能保證對於每個可能的輸入事件、轉換或其他操作的結果是正確的；這就是使用了單執行緒測試的技巧，測試用例提供的輸入事件將來自於其他執行緒。之後，核心狀態機和訊息路由的**，就能保證時間能以正確的順序，正確的傳遞給可單獨測試的執行緒上，不過對於多併發執行緒，需要為測試專門設計簡單的邏輯狀態。或者，如果將**分割成多個塊(比如：讀共享資料/變換資料/更新共享資料)，就能使用單執行緒來測試變換資料的部分。麻煩的多執行緒測試問題，轉換成單執行緒測試讀和更新共享資料，就會簡單許多。
一件事需要小心，就是某些庫會用其內部變數儲存狀態，當多執行緒使用同一庫中的函式，這個狀態就會被共享。這的確是乙個問題，並且這個問題不會馬上出現在訪問共享資料的**中。不過，隨著你對這個庫的熟悉，就會清楚這樣的情況會在什麼時候出現。之後，可以適當的加一些保護和同步，或使用b計畫——讓多執行緒安全併發訪問的功能。
構建多執行緒測試**
在特定時間內，你需要安排一系列執行緒，同時去執行指定的**段。最簡單的情況：兩個執行緒的情況，就很容易擴充套件到多個執行緒。
首先，你需要知道每個測試的不同之處：
1.環境布置**，必須首先執行
2.執行緒設定**，需要在每個執行緒上執行
3.執行緒上執行的**，需要有併發性
4.在併發執行結束後，後續**需要對**的狀態進行斷言檢查
最終，我們還了解了一些對測試很有幫助的工具。
以上摘抄自《c++併發程式設計實戰》
比如說：
1.visual studio提供了「執行緒」視窗、「gpu 執行緒」視窗、「並行監視」視窗和其他可簡化多執行緒除錯的功能。
2.thread checker，thread profiler，能以較直觀的方式發現問題。
多執行緒程式的除錯
gdb對於多執行緒程式的除錯有如下的支援 gdb r starting program root thread new thread 1073951360 lwp 12900 new thread 1082342592 lwp 12907 以下三個為新產生的執行緒 new thread 109073...
GDB除錯多執行緒程式
info threads 顯示當前可除錯的所有執行緒，每個執行緒會有乙個gdb為其分配的id，後面操作執行緒的時候會用到這個id。前面有 的是當前除錯的執行緒。thread id 切換當前除錯的執行緒為指定id的執行緒 break thread test.c 123 thread all 在所有執行...
Gdb 除錯多執行緒程式
gdb多執行緒除錯的基本命令。info threads顯示當前可除錯的所有執行緒，每個執行緒會有乙個gdb為其分配的id，後面操作執行緒的時候會用到這個id。前面有 的是當前除錯的執行緒。thread id切換當前除錯的執行緒為指定id的執行緒。break thread test.c 123 thr...