記一次線上崩潰問題的排查過程
大家好，我是雨樂!
前幾天，突然收到報(bào)警，線上服務(wù)崩潰，然后自動(dòng)重啟。
由于正值雙十一期間，業(yè)務(wù)以穩(wěn)定為主，線上服務(wù)崩潰，這可不是一件小事，趕緊登陸線上服務(wù)器，分析原因，迅速解決。
借助這篇文章，記錄下整個(gè)崩潰的分析和解決過程。
收到報(bào)警
上午上班后，正在劃水，突然收到郵件報(bào)警，如下：
問題分析
馬上登錄線上服務(wù)器，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<char, std::char_traits<char>, std::allocator<char> > 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<char, std::char_traits<char>, std::allocator<char> > const&, Json::Value&, bool) ()
- ......
在上面堆棧信息中可以看到在調(diào)用Json::Reader::parse后經(jīng)過Json::Reader::readValue等調(diào)用,最后再調(diào)用Json::Reader::readValue時(shí)調(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.");
進(jìn)入對(duì)應(yīng)的函數(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
的時(shí)候，會(huì)調(diào)用throwRuntimeError，那么分析下stackDepth_g和stackLimit_g的聲明定義：
- static int const stackLimit_g = 1000;
- static int stackDepth_g = 0;
問題基本明了：
stackDepth_g是個(gè)靜態(tài)全局變量,線程不安全,而出問題的服務(wù)是多線程的
在此準(zhǔn)備吐槽下，筆者使用jsoncpp對(duì)象的時(shí)候，都是在線程內(nèi)部一個(gè)局部變量，因此不會(huì)存在多線程訪問同一個(gè)局部jsoncpp對(duì)象的時(shí)候，因此確定就是因?yàn)槿肿兞慷嗑€程訪問導(dǎo)致的。一個(gè)開源的項(xiàng)目，里面竟然有全局變量，這在規(guī)范里面是不被允許的。
然后谷歌搜索了下大家都有過類似的問題，再次吐槽下。
問題解決
解決崩潰問題，首先需要看看是不是使用方式的問題，或者找一個(gè)線程安全的接口，再或者用其他庫進(jìn)行替換。
修改jsoncpp源碼
為了解決線程安全的問題，有兩種方案：1、在操作全局變量的時(shí)候，加上mutex，這個(gè)無非對(duì)性能要求很高的業(yè)務(wù)一個(gè)致命打擊，為了提高業(yè)務(wù)性能，所以內(nèi)部鎖都使用其他方式進(jìn)行了優(yōu)化，比如mutex使用雙buffer方式進(jìn)行了替換，雖然mutex的一個(gè)加鎖解鎖過程也就100ns。
2、將上述全局變量放入Json對(duì)象中，這樣局部變量就不會(huì)存在崩潰現(xiàn)象，但是這種方案存在一個(gè)問題，就是改動(dòng)點(diǎn)很大，且需要大量嚴(yán)格的測(cè)試，放棄。
所以綜合考慮上述兩點(diǎn)，決定采用其他更安全可靠的方式來解決線上崩潰問題。
使用rapidjson
之所以采用rapidjson，是因?yàn)榫€上幾十個(gè)服務(wù)，大部分都使用rapidjson，只有線上崩潰的這個(gè)服務(wù)等少數(shù)幾個(gè)服務(wù)，因?yàn)闅v史原因，用的jsoncpp。
先介紹下rapidjson，下述內(nèi)容來自于rapidjson官網(wǎng):
- RapidJSON 是一個(gè) C++ 的 JSON 解析器及生成器。它的靈感來自 RapidXml。
- RapidJSON 小而全。它同時(shí)支持 SAX 和 DOM 風(fēng)格的 API。SAX 解析器只有約 500 行代碼。
- RapidJSON 快。它的性能可與 strlen() 相比。可支持 SSE2/SSE4.2 加速。
- RapidJSON 獨(dú)立。它不依賴于 BOOST 等外部庫。它甚至不依賴于 STL。
- RapidJSON 對(duì)內(nèi)存友好。在大部分 32/64 位機(jī)器上，每個(gè) JSON 值只占 16 字節(jié)(除字符串外)。它預(yù)設(shè)使用一個(gè)快速的內(nèi)存分配器，令分析器可以緊湊地分配內(nèi)存。
- RapidJSON 對(duì) Unicode 友好。它支持 UTF-8、UTF-16、UTF-32 (大端序/小端序)，并內(nèi)部支持這些編碼的檢測(cè)、校驗(yàn)及轉(zhuǎn)碼。例如，RapidJSON 可以在分析一個(gè) UTF-8 文件至 DOM 時(shí)，把當(dāng)中的 JSON 字符串轉(zhuǎn)碼至 UTF-16。它也支持代理對(duì)(surrogate pair)及 "\u0000"(空字符)。
不過rapidjson為了性能，在使用上面需要極其小心。
筆者之前踩過類似坑，局部字符串賦值給rapidjson對(duì)象，結(jié)果rapidjson并沒有馬上使用該局部字符串，而是在最后才會(huì)訪問局部字符串里面的內(nèi)容，而此時(shí)，局部字符串早已出了作用域，導(dǎo)致rapidjson獲取的內(nèi)容是亂碼。
結(jié)語
在使用開源項(xiàng)目的時(shí)候，一定要做好調(diào)研，必要的時(shí)候，能過一下源碼實(shí)現(xiàn)(這個(gè)有點(diǎn)難??)，否則很容易入坑。
筆者在使用libcurl作為httpclient的時(shí)候，也因?yàn)橛|發(fā)了libcurl的一個(gè)bug，導(dǎo)致線上崩潰，當(dāng)時(shí)連續(xù)通宵了兩個(gè)晚上，才解決。
一入C++深似海，從此XX是路人。
