C語言多模塊協作中的時序問題排查實戰

在多模塊協同的軟件系統中，消息處理時序往往是導致疑難雜症的隱形殺手。本文基於真實項目經驗，詳細記錄一次由「發送後休眠導致全局變量未及時賦值」引發的用戶號碼匹配失敗問題，完整呈現從現象觀察、日志分析、假設驗證到根因定位與修復的全過程。

問題背景

系統包含模塊A與模塊B，通信流程如下：

1. 模塊A發送攜帶「用戶號碼+序列號」的消息給模塊B。
2. 發送成功後，模塊A依序列號將用戶號碼存入全局變量。
3. 模塊B接收處理後，原樣返回「用戶號碼+序列號」。
4. 模塊A收到回復，按序列號查找全局變量中的用戶號碼，與返回值比對，一致則繼續業務流程。

異常現象

自測階段發現：strncmp 比對用戶號碼失敗，業務流程中斷。日志顯示發送與接收的用戶號碼、序列號打印均一致，但比對卻不通過。

排查過程

1. 加密日志定位差異

在比對代碼前添加日志，打印「發送側存儲的用戶號碼/序列號」與「接收側解析的用戶號碼/序列號」。

驚人發現：接收側數據正確，發送側數據卻為空值。

2. 回溯賦值邏輯

在「拷貝用戶號碼到全局變量」代碼後加日志，發現賦值本身成功。為什麼比對時變成空值？

3. 時序日志揭示真相

仔細對比日志時間戳：接收回復消息的時間，早於拷貝全局變量的時間！

4. 代碼邏輯確認

// 模塊A 發送邏輯（簡化）
SendMsgToB(msg);           // 發送消息
Sleep(100);                // 休眠 100ms —— 禍根在此！
CopyToGlobalVar(seq, user); // 休眠結束後才拷貝

模塊B處理極快，在模塊A休眠期間已返回消息。此時全局變量尚未賦值，比對自然失敗。

5. 驗證假設

註釋掉 Sleep(100)，重新運行，問題消失，業務流程正常。

根因與修復

經驗總結

1. 詳盡日志是定位利器：關鍵節點（發送、接收、賦值、比對）務必打印時間戳與關鍵數據。
2. 理清前後依賴關係：消息交互場景下，發送、存儲、接收、比對的時序必須嚴格設計，防止「越位」執行。
3. 膽大假設，小心求證：對每個疑點（如休眠）立即通過代碼修改驗證，勿憑臆測。
4. 拥抱Bug，提升能力：Bug不可避免，掌握系統化排查方法，方能「以不變應萬變」。

代碼修復示意

// 修復前：休眠導致賦值滯後
SendMsgToB(msg);
Sleep(100);
CopyToGlobalVar(seq, user);  // 太晚了！

// 修復後：先賦值，再發送，休眠不影響邏輯
CopyToGlobalVar(seq, user);  // 先存好
SendMsgToB(msg);
Sleep(100);                  // 業務無關的休眠放這兒無妨

總結

這是一個典型的「時序竝發」缺陷，看似邏輯正確，實則違背了「先準備數據，再觸發動作」的基本原則。通過日志時間戳的微觀對比，還原了微秒級的時序倒置。記住：全局變量賦值必須早於可能讀取它的任何操作，這在異步、多線程、分布式場景下尤為關鍵。