C++多線程調(diào)試和測試的注意事項(xiàng)有哪些

這篇文章主要講解了“C++多線程調(diào)試和測試的注意事項(xiàng)有哪些”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“C++多線程調(diào)試和測試的注意事項(xiàng)有哪些”吧！

一、關(guān)于設(shè)置斷點(diǎn)和單步執(zhí)行

很多同學(xué)非常依賴于調(diào)試器的斷點(diǎn)功能和單步功能。這在單線程情況下倒還好（不過有些單線程但涉及GUI的程序，也會有點(diǎn)麻煩）。至于多線程程序的調(diào)試，這兩種手段簡直就是噩夢的開始。多線程造成的主要問題大都和競態(tài)條件（Race Condition，詳細(xì)解釋看“這里 ”）有關(guān)。

而設(shè)置斷點(diǎn)或單步跟蹤可能會嚴(yán)重干擾 多線程之間的競爭狀態(tài)。導(dǎo)致你看到的是一個假象。比如本來有兩個線程并發(fā)執(zhí)行，存在某些不和諧的Bug（由競態(tài)引起）。一旦你在某一個線程設(shè)置了斷點(diǎn)，該線程在斷點(diǎn)處停住了，只剩下另一個線程在跑。這時候，并發(fā)的場景已經(jīng)完全被破壞了，你通過調(diào)試器看到的可能 是一個和諧的場景。

稍微跑一下題。這很類似量子力學(xué)的“測不準(zhǔn)原理”，觀測者的觀測行為干擾了被測量的客體，導(dǎo)致觀測者看到的是一個干擾后的現(xiàn)象。

二、關(guān)于Log輸出

既然斷點(diǎn)和單步不好用。那咋辦捏？一個替代方案是輸出log日志。它可以有效減輕斷點(diǎn)和單步所導(dǎo)致的（針對競態(tài)條件的）副作用。

1、傳統(tǒng)Log機(jī)制的問題

傳統(tǒng)的log輸出主要是打印到屏幕或者輸出到文件。對于C++而言，標(biāo)準(zhǔn)庫內(nèi)置的類和函數(shù)（比如cout、printf、fputs）可能會有線程安全的問題（和編譯器的具體實(shí)現(xiàn)有關(guān)）。尤其是標(biāo)準(zhǔn)流類庫（iostream）的八個全局對象，更是要小心慎用。輕則輸出的log文本混雜，重則導(dǎo)致程序崩潰。

鑒于上述原因，應(yīng)該盡量使用第三方線程庫內(nèi)置的log機(jī)制來搞定log輸出功能。比如ACE內(nèi)置的ACE_Log_Msg等。

2、Log函數(shù)要短小精悍

很多情況下，我們會包裝一個公用的函數(shù)來實(shí)現(xiàn)log輸出功能。然后在該函數(shù)內(nèi)部調(diào)用線程庫的log類/函數(shù)。為了不影響線程的競態(tài)條件，這個log函數(shù)要盡可能簡單輕便：不要涉及太多雜七雜八的瑣事、千萬別進(jìn)行耗時的操作、盡量不操作一些全局的變量。

3、Log的副作用

不過捏，即使log函數(shù)再短小精悍，也還是有可能影響競態(tài)條件（畢竟log也有開銷，也要消耗CPU時間）。

萬一競態(tài)條件受到log的影響，那就比較棘手了。我以前就碰到過這種情況：加了log，程序沒有問題；去掉log，程序隨機(jī)崩潰。這種情況一般有兩種可能：要么是log功能本身有問題，要么是程序的競態(tài)條件非常敏感（連log的開銷都會有影響）。

這時候你能依靠的就只有肉眼和人腦了。先把相關(guān)的代碼和文檔仔細(xì)看上幾遍（***再找其他有經(jīng)驗(yàn)的人一起Code Review），然后大家一起開動腦筋使勁琢磨。

三、關(guān)于Debug版本和Release版本

C++程序經(jīng)常有Debug版本和Release版本的區(qū)別。有些時候，這也會導(dǎo)致一些多線程的問題。

由于Debug版本包含了一些調(diào)試信息、啟用了某些調(diào)試機(jī)制（比如assert宏）。所以就可能 影響到多線程的競爭狀態(tài)。在倒霉的時候，會碰上Debug版本工作正常，Release版本程序隨機(jī)崩潰。要避免這種情況，可以考慮下面兩個辦法：

1、放棄使用Debug版本

你可以干脆放棄使用Debug版本。在這種情況下，你需要考慮把諸如assert之類調(diào)試相關(guān)的宏替換成自己的一套宏，使得在非Debug版本下也可以生效。

2、兩種版本同步測試

使用此方法，程序員平時自測可以使用Debug版本，但是測試人員日常測試的必須是Release版本。具體的操作步驟可以利用每日構(gòu)建來輔助進(jìn)行（每日構(gòu)建的介紹參見“這里 ”）。一定要避免：在平時僅僅搞Debug版本的測試，等到發(fā)布前夕再制作Release版本。這種做法是非常危險的！

四、關(guān)于測試的機(jī)器（硬件）

說一個親身經(jīng)歷、印象深刻的事情。

當(dāng)年用ACE開發(fā)跨平臺程序的時候，公司內(nèi)的的開發(fā)環(huán)境和測試環(huán)境都是單CPU的機(jī)器。因?yàn)楫?dāng)時多核的機(jī)器還沒有面世，多CPU的機(jī)器又挺貴，公司沒舍得花錢配置。

軟件開發(fā)完之后，測試人員經(jīng)過幾輪回歸測試，也沒發(fā)現(xiàn)太大問題。但是拿到客戶的環(huán)境中運(yùn)行，卻經(jīng)常會隨機(jī)性崩潰。因?yàn)椴荒茉诳蛻舡h(huán)境中Debug，自己的環(huán)境又死活沒問題，開發(fā)組的幾個人只好充分發(fā)揮肉眼和人腦的功能（盯著代碼和設(shè)計(jì)文檔猛想）。經(jīng)過N長時間，差點(diǎn)把腦袋想破，***才意識到客戶的機(jī)器是多CPU的。然后趕緊從其它部門借了一臺多CPU機(jī)器，裝上軟件調(diào)試，***查出是一個第三方庫有問題。此事過后，我立即想出各種法子，去申請了幾臺多CPU機(jī)器給測試人員用。

由于上述的前車之鑒，所以我強(qiáng)烈建議：如果是開發(fā)多線程的應(yīng)用程序，盡量給每一個 編程人員和測試人員都配置多核/多CPU的機(jī)器。畢竟現(xiàn)在多核機(jī)器已經(jīng)很普及了，即使多CPU的機(jī)器，價格也還湊合。實(shí)在沒必要為了省那點(diǎn)小錢而引入開發(fā)風(fēng)險（不光會浪費(fèi)開發(fā)/測試人員的時間，還可能增加實(shí)施和維護(hù)的成本）。

感謝各位的閱讀，以上就是“C++多線程調(diào)試和測試的注意事項(xiàng)有哪些”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對C++多線程調(diào)試和測試的注意事項(xiàng)有哪些這一問題有了更深刻的體會，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識點(diǎn)的文章，歡迎關(guān)注！