記一次線上崩潰問題的排查過程
前幾天，突然收到報警，線上服務崩潰，然后自動重啟。
由于正值雙十一期間，業(yè)務以穩(wěn)定為主，線上服務崩潰，這可不是一件小事，趕緊登陸線上服務器，分析原因，迅速解決。
借助這篇文章，記錄下整個崩潰的分析和解決過程。
收到報警
上午上班后，正在劃水，突然收到郵件報警，如下：
問題分析
馬上登錄線上服務器，gdb調(diào)試堆棧信息。
堆棧信息如下：
#0??0x0000003ab9a324f5?in?raise?()?from?/lib64/libc.so.6
#1??0x0000003ab9a33cd5?in?abort?()?from?/lib64/libc.so.6
#2??0x0000003abcebea8d?in?__gnu_cxx::__verbose_terminate_handler()?()?from?/usr/lib64/libstdc++.so.6
#3??0x0000003abcebcbe6?in????()?from?/usr/lib64/libstdc++.so.6
#4??0x0000003abcebcc13?in?std::terminate()?()?from?/usr/lib64/libstdc++.so.6
#5??0x0000003abcebcd32?in?__cxa_throw?()?from?/usr/lib64/libstdc++.so.6
#6??0x00000000006966bf?in?Json::throwRuntimeError(std::basic_string,?std::allocator?>?const&)?()
#7??0x0000000000681019?in?Json::Reader::readValue()?()
#8??0x000000000068277c?in?Json::Reader::readArray(Json::Reader::Token&)?()
#9??0x0000000000681152?in?Json::Reader::readValue()?()
#10?0x00000000006823a6?in?Json::Reader::readObject(Json::Reader::Token&)?()
#11?0x00000000006810f5?in?Json::Reader::readValue()?()
#12?0x0000000000680e6e?in?Json::Reader::parse(char?const*,?char?const*,?Json::Value&,?bool)?()
#13?0x0000000000680c52?in?Json::Reader::parse(std::basic_string,?std::allocator?>?const&,?Json::Value&,?bool)?()
......
在上面堆棧信息中可以看到在調(diào)用Json::Reader::parse后經(jīng)過Json::Reader::readValue等調(diào)用,最后再調(diào)用Json::Reader::readValue時調(diào)用Json::throwRuntimeError拋出異常。
查看調(diào)用Json::throwRuntimeError函數(shù)的地方：
src/lib_json/json_writer.cpp:????throwRuntimeError("commentStyle?must?be?'All'?or?'None'");
src/lib_json/json_reader.cpp:??if?(stackDepth_g?>=?stackLimit_g)?throwRuntimeError("Exceeded?stackLimit?in?readValue().");
src/lib_json/json_reader.cpp:??if?(stackDepth_?>=?features_.stackLimit_)?throwRuntimeError("Exceeded?stackLimit?in?readValue().");
src/lib_json/json_reader.cpp:????if?(name.length()?>=?(1U<<30))?throwRuntimeError("keylength?>=?2^30");
src/lib_json/json_reader.cpp:????throwRuntimeError(errs);
src/lib_json/json_value.cpp:????throwRuntimeError(
src/lib_json/json_value.cpp:????throwRuntimeError(
src/lib_json/json_value.cpp:JSONCPP_NORETURN?void?throwRuntimeError(JSONCPP_STRING?const&?msg)
src/lib_json/json_valueiterator.inl:??throwRuntimeError("ConstIterator?to?Iterator?should?never?be?allowed.");
進入對應的函數(shù)
bool?Reader::readValue()?{
??if?(stackDepth_g?>=?stackLimit_g)?throwRuntimeError("Exceeded?stackLimit?in?readValue().");
??++stackDepth_g;
??...?...
??--stackDepth_g;
??return?successful;
}
發(fā)現(xiàn)，在滿足條件
stackDepth_g?>=?stackLimit_g
的時候，會調(diào)用throwRuntimeError，那么分析下stackDepth_g和stackLimit_g的聲明定義：
static?int?const?stackLimit_g?=?1000;
static?int???????stackDepth_g?=?0;?
問題基本明了：
?stackDepth_g是個靜態(tài)全局變量,線程不安全,而出問題的服務是多線程的
?
在此準備吐槽下，筆者使用jsoncpp對象的時候，都是在線程內(nèi)部一個局部變量，因此不會存在多線程訪問同一個局部jsoncpp對象的時候，因此確定就是因為全局變量多線程訪問導致的。一個開源的項目，里面竟然有全局變量，這在規(guī)范里面是不被允許的。
然后谷歌搜索了下大家都有過類似的問題，再次吐槽下。
問題解決
解決崩潰問題，首先需要看看是不是使用方式的問題，或者找一個線程安全的接口，再或者用其他庫進行替換。
修改jsoncpp源碼
為了解決線程安全的問題，有兩種方案：1、在操作全局變量的時候，加上mutex，這個無非對性能要求很高的業(yè)務一個致命打擊，為了提高業(yè)務性能，所以內(nèi)部鎖都使用其他方式進行了優(yōu)化，比如mutex使用雙buffer方式進行了替換，雖然mutex的一個加鎖解鎖過程也就100ns。
2、將上述全局變量放入Json對象中，這樣局部變量就不會存在崩潰現(xiàn)象，但是這種方案存在一個問題，就是改動點很大，且需要大量嚴格的測試，放棄。
所以綜合考慮上述兩點，決定采用其他更安全可靠的方式來解決線上崩潰問題。
使用rapidjson
之所以采用rapidjson，是因為線上幾十個服務，大部分都使用rapidjson，只有線上崩潰的這個服務等少數(shù)幾個服務，因為歷史原因，用的jsoncpp。
先介紹下rapidjson，下述內(nèi)容來自于rapidjson官網(wǎng):
RapidJSON 是一個 C++ 的 JSON 解析器及生成器。它的靈感來自 RapidXml。
RapidJSON 小而全。它同時支持 SAX 和 DOM 風格的 API。SAX 解析器只有約 500 行代碼。
RapidJSON 快。它的性能可與 strlen() 相比。可支持 SSE2/SSE4.2 加速。
RapidJSON 獨立。它不依賴于 BOOST 等外部庫。它甚至不依賴于 STL。
RapidJSON 對內(nèi)存友好。在大部分 32/64 位機器上，每個 JSON 值只占 16 字節(jié)（除字符串外）。它預設使用一個快速的內(nèi)存分配器，令分析器可以緊湊地分配內(nèi)存。
RapidJSON 對 Unicode 友好。它支持 UTF-8、UTF-16、UTF-32 (大端序／小端序)，并內(nèi)部支持這些編碼的檢測、校驗及轉(zhuǎn)碼。例如，RapidJSON 可以在分析一個 UTF-8 文件至 DOM 時，把當中的 JSON 字符串轉(zhuǎn)碼至 UTF-16。它也支持代理對（surrogate pair）及 "\u0000"（空字符）。
不過rapidjson為了性能，在使用上面需要極其小心。
?筆者之前踩過類似坑，局部字符串賦值給rapidjson對象，結(jié)果rapidjson并沒有馬上使用該局部字符串，而是在最后才會訪問局部字符串里面的內(nèi)容，而此時，局部字符串早已出了作用域，導致rapidjson獲取的內(nèi)容是亂碼。
?
結(jié)語
在使用開源項目的時候，一定要做好調(diào)研，必要的時候，能過一下源碼實現(xiàn)(這個有點難??)，否則很容易入坑。
筆者在使用libcurl作為httpclient的時候，也因為觸發(fā)了libcurl的一個bug，導致線上崩潰，當時連續(xù)通宵了兩個晚上，才解決。
一入C++深似海，從此XX是路人。
以候捷在<
?源碼之前，了無秘密。
?
共勉。