上周像往常一樣例行檢查線(xiàn)上機器性能，突然發(fā)現一個(gè)服務(wù)的內存使用率是這樣的：

很顯然該服務(wù)存在內存泄漏問(wèn)題，趕緊排查問(wèn)題。

問(wèn)題排查

首先確定內存泄漏問(wèn)題出現的時(shí)間，發(fā)現在該時(shí)間點(diǎn)的上線(xiàn)有兩次代碼提交，其中一個(gè)就是我的。于是立刻排查這兩次代碼的改動(dòng)，確定了另一個(gè)同事的代碼不可能會(huì )有內存問(wèn)題后(因為另一個(gè)同事的上線(xiàn)僅僅修改了配置)我知道肯定是自己的代碼出現了問(wèn)題。

確定了問(wèn)題所在后趕緊把自己的代碼回滾掉，接下來(lái)就可以放心debug了。

Debug

什么是內存泄漏？

簡(jiǎn)單的講就是程序員申請的內存在使用完后沒(méi)有還給操作系統，由于筆者使用的是C++語(yǔ)言，因此內存泄漏一般是這樣的：

obj* o = new obj();  

...  

// 使用完obj后沒(méi)有delete掉 

肯定有什么地方申請了內存后沒(méi)有調用delete釋放內存。

在這里介紹一下筆者的代碼改動(dòng)，我的任務(wù)其實(shí)是重構一段代碼，把這段代碼并行化。也就是舊的邏輯是在一個(gè)線(xiàn)程中串行執行的，現在我要把這段邏輯放到兩個(gè)線(xiàn)程中并行執行，這是最讓人頭疼的任務(wù)之一，并行化改造是比較容易出bug的。

接下來(lái)梳理了一遍中所有內存的申請和釋放，這其中包括：

 使用new/delete分配釋放的內存

 使用內存池分配釋放的內存

仔細梳理一遍后沒(méi)有發(fā)現任何問(wèn)題，該釋放的內存都已經(jīng)釋放掉了，這時(shí)筆者已經(jīng)開(kāi)始懷疑人生了 :) ，很顯然還有一段沒(méi)有注意到的地方出現了問(wèn)題，這是必然的，雖然知道問(wèn)題必然出現在改動(dòng)的這些代碼里但是我并不能確定出現的位置。

沒(méi)有辦法，到這里基本上已經(jīng)要放棄自己人肉debug了，想利用一些內存檢測工具來(lái)幫助自己確定問(wèn)題。

常見(jiàn)的內存泄漏檢測工具包括valgrind、gperftools等，valgrind的好處在于無(wú)需重新編譯代碼即可進(jìn)行內存檢測，但是缺點(diǎn)是會(huì )使得程序運行非常緩慢，官方文檔給的說(shuō)法是會(huì )比正常的程序運行慢20-30倍；gperftools則需要重新編譯可執行程序。這些工具需要下載安裝測試，其中還涉及到申請機器權限等問(wèn)題，筆者覺(jué)得還是比較麻煩，況且這個(gè)問(wèn)題也不是大海撈針一樣，問(wèn)題肯定出在了并行化的這段代碼中。

到這里我決定再換一個(gè)思路來(lái)排查問(wèn)題，既然代碼重構后開(kāi)始并行執行，那么出現問(wèn)題大概率是因為多線(xiàn)程問(wèn)題，遇到多線(xiàn)程問(wèn)題首先重點(diǎn)排查的就是線(xiàn)程間的共享數據。

多線(xiàn)程問(wèn)題的關(guān)鍵——共享數據

我們知道如果線(xiàn)程之間沒(méi)有共享數據那么就不會(huì )有線(xiàn)程安全問(wèn)題，我們使用的鎖、信號量、條件變量等其實(shí)都是用來(lái)保護共享數據的，比如鎖通常是用來(lái)包括臨界區的，臨界區中的代碼操作的就是線(xiàn)程共享數據；信號量使用的一個(gè)經(jīng)典場(chǎng)景就是生產(chǎn)者消費者問(wèn)題，生產(chǎn)者線(xiàn)程以及消費者線(xiàn)程都會(huì )操作同一個(gè)隊列，這里的隊列就是共享數據。

沿著(zhù)這個(gè)思路開(kāi)始找在兩個(gè)線(xiàn)程中都使用到的共享數據，果不其然，在一個(gè)角落中發(fā)現了這樣一段代碼：

auto* pb = global->mutable_obj(); 

這是分配protobuf對象的一段代碼，protobuf是Google開(kāi)發(fā)是一種類(lèi)似于JSON、XML的技術(shù)，因此常用于網(wǎng)絡(luò )通信和數據交換等場(chǎng)景，比如RPC等。

如果你不了解protobuf也沒(méi)有關(guān)系，實(shí)際上上面的這段代碼的要做的事情是這樣的：

if (global->obj == NULL) {  

  global->obj = new obj();  

}  

return global->obj; 

值得注意的是這段代碼現在會(huì )在兩個(gè)線(xiàn)程中執行，顯然問(wèn)題就出現在了這里。

那么問(wèn)題是怎么出現的呢？

我們假設有兩個(gè)線(xiàn)程，線(xiàn)程A和線(xiàn)程B，當這樣一段代碼在線(xiàn)程AB中同時(shí)執行時(shí)可能會(huì )有以下場(chǎng)景：

 線(xiàn)程A拿到global->obj并檢測到此時(shí)的global->obj為空，因此決定為其分配內存，但不巧的是此時(shí)發(fā)生線(xiàn)程切換，線(xiàn)程A在為global->obj分配內存前被暫停運行，如下所示： 

if (global->obj == NULL) {  

    <------- 線(xiàn)程切換，線(xiàn)程A被暫停執行   

    global->obj = new obj();  

}  

return global->obj; 

 線(xiàn)程A被暫停運行后線(xiàn)程B開(kāi)始執行，這段代碼同樣會(huì )在線(xiàn)程B中執行一遍，因此線(xiàn)程B會(huì )首先檢查global->obj發(fā)現為空，因此為global->obj分配內存，分配完內存后發(fā)生線(xiàn)程切換，線(xiàn)程B被暫停運行，如下所示： 

if (global->obj == NULL) {  

    global->obj = new obj();  

    <------- 線(xiàn)程切換，線(xiàn)程B被暫停執行   

}  

return global->obj; 

線(xiàn)程B被暫停運行后調度器決定重新運行線(xiàn)程A，此時(shí)線(xiàn)程A開(kāi)始從被中斷的地方繼續運行，還記得線(xiàn)程A是從哪里被中斷的嗎，沒(méi)錯，就是在為global->obj分配內存前被中斷的，此時(shí)線(xiàn)程A繼續運行，也就是說(shuō)global->obj = new obj()這段代碼又被執行了一次，雖然線(xiàn)程B已經(jīng)為global->obj分配了內存。

Oops，典型的內存泄漏，線(xiàn)程B分配的內存再也無(wú)法被正常釋放掉了。

至此，我們已經(jīng)找到了問(wèn)題的原因，罪魁禍首就是共享數據，關(guān)鍵的一點(diǎn)是要意識到你的線(xiàn)程會(huì )隨時(shí)被中斷執行，CPU會(huì )隨時(shí)切換到其它線(xiàn)程。

代碼修復也非常簡(jiǎn)單，再新增一個(gè)變量，兩個(gè)線(xiàn)程不在使用共享數據，到這里問(wèn)題就解決了，從發(fā)現問(wèn)題到完成修復耗時(shí)大概4小時(shí)。

經(jīng)驗教訓

代碼的并行化重構是一件非常棘手的任務(wù)，很容易出現線(xiàn)程安全問(wèn)題，解決線(xiàn)程安全問(wèn)題首先要考慮的不是要不要加鎖，而是多個(gè)線(xiàn)程是否真的有必要使用共享數據，沒(méi)有必要的話(huà)多個(gè)線(xiàn)程操作私有數據根本就不會(huì )出現線(xiàn)程安全問(wèn)題。

當出現線(xiàn)程安全問(wèn)題時(shí)，第一時(shí)間重點(diǎn)排查線(xiàn)程使用的共享數據。

內存泄漏檢測工具

雖然這些沒(méi)有使用檢測工具全靠人肉debug其實(shí)還是因為問(wèn)題排查范圍比較小，如果我們根本就不知道問(wèn)題出現在了那次代碼改動(dòng)那么檢測工具就非常重要了，在這里簡(jiǎn)單介紹一下valgrind的使用，詳細的介紹請參考官方文檔。

假設有這樣一段問(wèn)題代碼：

#include <stdlib.h>  

void f(void)    

{  

   int* x = malloc(10 * sizeof(int));  

   x[10] = 0;        // 問(wèn)題1: 越界  

}                    // 問(wèn)題2: 內存泄漏，x沒(méi)有被釋放掉   

int main()   

{  

   f();  

   return 0;  

} 

這段代碼中有兩個(gè)問(wèn)題：一個(gè)是數據的越界訪(fǎng)問(wèn)；另一個(gè)是內存泄漏。將該程序編譯為myprog。

接下來(lái)使用valgrind來(lái)檢查該程序，使用以下命令：

valgrind --leak-check=yes myprog 

運行完成后valgrind會(huì )給出檢測報告，關(guān)于程序越界訪(fǎng)問(wèn)會(huì )給出這樣的輸出：

==19182== Invalid write of size 4  

==19182==    at 0x804838F: f (example.c:6)  

==19182==    by 0x80483AB: main (example.c:11)  

==19182==  Address 0x1BA45050 is 0 bytes after a block of size 40 alloc'd  

==19182==    at 0x1B8FF5CD: malloc (vg_replace_malloc.c:130) 

==19182==    by 0x8048385: f (example.c:5)  

==19182==    by 0x80483AB: main (example.c:11) 

第一行告訴你代碼中存在Invalid write，也就是無(wú)效的寫(xiě)，并給出了問(wèn)題出現的位置。

關(guān)于內存泄漏問(wèn)題會(huì )給出這樣的輸出：

==19182== 40 bytes in 1 blocks are definitely lost in loss record 1 of 1  

==19182==    at 0x1B8FF5CD: malloc (vg_replace_malloc.c:130)  

==19182==    by 0x8048385: f (example.c:5)  

==19182==    by 0x80483AB: main (example.c:11) 

這里第一行報告了內存"definitely lost"，也就是說(shuō)一定會(huì )存在內存泄漏，并給出了問(wèn)題出現的位置。

實(shí)際上除了"definitely lost"，valgrind還會(huì )給出"probably lost"的報告，這兩種報告的含義是這樣的：

 "definitely lost"：你的程序一定存在內存泄漏問(wèn)題，修復。

 "probably lost"：你的程序看起來(lái)像是有內存泄漏，有可能你在使用指針完成一些特定操作，因此不一定100%存在問(wèn)題。

總結

編寫(xiě)正確的多線(xiàn)程代碼從來(lái)不是一件容易的事情，線(xiàn)程安全問(wèn)題的根源在于共享資源，因此在使用共享資源前務(wù)必確認我們一定要用共享資源嗎？