多線程環境下全局布爾標誌變量被意外修改的排查思路

現象描述

全局 bool bflag 在線程執行某對象函數後發生變化，但該函數內無賦值代碼。經排查，發現 TimeOut() 函數中對其重新賦值且未加鎖，且在睡眠期間可能被其他線程通過消息機制觸發修改。

根因分析

1. 非原子操作：bool 讀寫在某些架構上非原子，可能發生撕裂讀寫。
2. 無同步機制：多線程並發讀寫同一變量，缺乏 mutex/atomic 保護。
3. 隱式調用鏈：sleep() 期間消息泵處理其他消息，間接調用修改該標誌的函數。

解決方案

方案一：使用 std::atomic<bool> (C++11)

std::atomic bflag{false};
// 線程 A
bflag.store(true, std::memory_order_release);
// 線程 B
if (bflag.load(std::memory_order_acquire)) { ... }

方案二：互斥鎖保護

std::mutex mtx;
bool bflag = false;

// 寫入
{
    std::lock_guard lock(mtx);
    bflag = true;
}
// 讀取
bool val;
{
    std::lock_guard lock(mtx);
    val = bflag;
}

方案三：條件變量替代標誌輪詢

std::condition_variable cv;
std::mutex mtx;
bool ready = false;

// 等待線程
std::unique_lock lk(mtx);
cv.wait(lk, []{ return ready; });

// 通知線程
{
    std::lock_guard lock(mtx);
    ready = true;
}
cv.notify_one();

最佳實踐建議

• 盡量避免全局變量，改用線程安全的消息隊列或 Actor 模型傳遞狀態。
• 若必須共享，優先用 atomic，複雜邏輯用鎖 + 條件變量。
• 代碼審查重點關注跨線程調用的共享變量，添加 TSAN (ThreadSanitizer) 檢測數據競爭。

通過原子操作或鎖機制保護共享標誌，並梳理調用鏈消除隱式修改，即可解決多線程下布爾變量異常變化問題。