多執行緒測試核心挑戰：競態條件與觀測效應
多執行緒 Bug 多源自競態條件：多執行緒並發存取共享資料，結果依賴執行順序。調試器斷點/單步嚴重干擾時序，類似量子力學「測不準原理」：觀測行為改變被觀測系統。
四大測試實戰策略
1. 斷點與單步：謹慎使用，理解副作用
- 斷點凍結某執行緒，破壞並發時序，可能掩蓋 Bug
- 單步執行序列化並發，看似和諧實則虛假
- 適用場景：單執行緒邏輯驗證、死鎖現場檢查 (凍結所有執行緒檢視呼叫堆疊)
2. Log 輸出：主要觀測手段，但需輕量
傳統 Log 陷阱
cout/printf 非執行緒安全，輸出交織、甚至崩潰- iostream 八大全域物件內部鎖爭用導致效能抖動
解決方案
- 使用執行緒安全 Log 庫 (ACE
ACE_Log_Msg、spdlog、log4cplus、Boost.Log)
- Log 函數極度精簡：無複雜邏輯、無耗時操作、少觸全域狀態
Log 副作用
即使極輕量，Log 仍消耗 CPU 時間，可能改變競態時序。遇到「加 Log 正常、去 Log 崩潰」：檢查 Log 庫本身、或競態極敏感需純靜態分析。
3. Debug vs Release 版本：必須同步測試
| 差異 | Debug | Release |
|---|
| 除錯資訊 | 完整 | 無 |
| 優化 | 關閉 | 開啟 (-O2/-O3) |
| 斷言 | 啟用 | 通常關閉 |
| 記憶體檢查 | 堆守衛、填充模式 | 無 |
危險模式：平時只測 Debug，發布前才建 Release → 發現大量時序 Bug。
對策
- 放棄 Debug 版本，自訂斷言巨集在 Release 也生效
- 雙版本同步測試：開發自測用 Debug，測試團隊日常跑 Release，每日建構雙版本
4. 硬體環境：多核/多 CPU 機器不可或缺
真實案例：單 CPU 開發/測試環境全通，客戶多 CPU 環境隨機崩潰。第三方庫在多核下暴露 Bug。單 CPU 無法觸發真正並發 (僅分時多工)，多核才能並行執行多執行緒。
強烈建議
- 每位開發/測試人員配置多核機器 (現代 CPU 皆多核，成本極低)
- 超執行緒 (Hyper-Threading) 效果遜於真實多核/多 CPU
- CI/CD 執行器亦需多核
進階除錯技巧
- 靜態分析：Clang Thread Safety Analysis、Coverity、PVS-Studio 偵測資料競爭
- 動態檢測：ThreadSanitizer (TSan,
-fsanitize=thread) 運行期偵測資料競爭、死鎖
- 模型檢查：CHESS、CBMC 系統探索執行路徑
- 壓力測試：高併發、長時間運行、注入延遲/失敗
- Code Review 專注共享狀態：鎖粒度、無鎖資料結構、原子操作正確性
總結：多執行緒測試鐵律
- 不信斷點，信 Log 與靜態/動態分析工具
- Log 庫必須執行緒安全、極度輕量
- Debug/Release 雙版本從 Day 1 同步測試
- 多核硬體是開發/測試/基礎設施標配
- 善用 ThreadSanitizer 等現代動態檢測工具
多執行緒正確性無法靠傳統調試保證，需「工具 + 硬體 + 流程 + 代碼審查」多層防禦體系。
