關注公衆号【高性能架構探索】，背景回複【pdf】，免費擷取計算機經典書籍
大家好，我是雨樂！
前幾天，突然收到報警，線上服務崩潰，然後自動重新開機。
由于正值雙十一期間，業務以穩定為主，線上服務崩潰，這可不是一件小事，趕緊登陸線上伺服器，分析原因，迅速解決。
借助這篇文章，記錄下整個崩潰的分析和解決過程。
收到報警
上午上班後，正在劃水，突然收到郵件報警，如下：
問題分析
馬上登入線上伺服器，gdb調試堆棧資訊。
堆棧資訊如下：
#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) ()
...... 在上面堆棧資訊中可以看到在調用Json::Reader::parse後經過Json::Reader::readValue等調用,最後再調用Json::Reader::readValue時調用Json::throwRuntimeError抛出異常。
檢視調用Json::throwRuntimeError函數的地方：
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."); 進入對應的函數
bool Reader::readValue() {
if (stackDepth_g >= stackLimit_g) throwRuntimeError("Exceeded stackLimit in readValue().");
++stackDepth_g;
... ...
--stackDepth_g;
return successful;
} 發現，在滿足條件
stackDepth_g >= stackLimit_g 的時候，會調用throwRuntimeError，那麼分析下stackDepth_g和stackLimit_g的聲明定義：
static int const stackLimit_g = 1000;
static int stackDepth_g = 0; 問題基本明了：
❝
stackDepth_g是個靜态全局變量,線程不安全,而出問題的服務是多線程的
❞
在此準備吐槽下，筆者使用jsoncpp對象的時候，都是線上程内部一個局部變量，是以不會存在多線程通路同一個局部jsoncpp對象的時候，是以确定就是因為全局變量多線程通路導緻的。一個開源的項目，裡面竟然有全局變量，這在規範裡面是不被允許的。
然後谷歌搜尋了下大家都有過類似的問題，再次吐槽下。
問題解決
解決崩潰問題，首先需要看看是不是使用方式的問題，或者找一個線程安全的接口，再或者用其他庫進行替換。
修改jsoncpp源碼
為了解決線程安全的問題，有兩種方案：1、在操作全局變量的時候，加上mutex，這個無非對性能要求很高的業務一個緻命打擊，為了提高業務性能，是以内部鎖都使用其他方式進行了優化，比如mutex使用雙buffer方式進行了替換，雖然mutex的一個加鎖解鎖過程也就100ns。
2、将上述全局變量放入Json對象中，這樣局部變量就不會存在崩潰現象，但是這種方案存在一個問題，就是改動點很大，且需要大量嚴格的測試，放棄。
是以綜合考慮上述兩點，決定采用其他更安全可靠的方式來解決線上崩潰問題。
使用rapidjson
之是以采用rapidjson，是因為線上幾十個服務，大部分都使用rapidjson，隻有線上崩潰的這個服務等少數幾個服務，因為曆史原因，用的jsoncpp。
先介紹下rapidjson，下述内容來自于rapidjson官網:
- RapidJSON 是一個 C++ 的 JSON 解析器及生成器。它的靈感來自 RapidXml。
- RapidJSON 小而全。它同時支援 SAX 和 DOM 風格的 API。SAX 解析器隻有約 500 行代碼。
- RapidJSON 快。它的性能可與 strlen() 相比。可支援 SSE2/SSE4.2 加速。
- RapidJSON 獨立。它不依賴于 BOOST 等外部庫。它甚至不依賴于 STL。
- RapidJSON 對記憶體友好。在大部分 32/64 位機器上，每個 JSON 值隻占 16 位元組（除字元串外）。它預設使用一個快速的記憶體配置設定器，令分析器可以緊湊地配置設定記憶體。
- RapidJSON 對 Unicode 友好。它支援 UTF-8、UTF-16、UTF-32 (大端序／小端序)，并内部支援這些編碼的檢測、校驗及轉碼。例如，RapidJSON 可以在分析一個 UTF-8 檔案至 DOM 時，把當中的 JSON 字元串轉碼至 UTF-16。它也支援代理對（surrogate pair）及 "\u0000"（空字元）。
不過rapidjson為了性能，在使用上面需要極其小心。
筆者之前踩過類似坑，局部字元串指派給rapidjson對象，結果rapidjson并沒有馬上使用該局部字元串，而是在最後才會通路局部字元串裡面的内容，而此時，局部字元串早已出了作用域，導緻rapidjson擷取的内容是亂碼。
結語
在使用開源項目的時候，一定要做好調研，必要的時候，能過一下源碼實作(這個有點難?)，否則很容易入坑。
筆者在使用libcurl作為httpclient的時候，也因為觸發了libcurl的一個bug，導緻線上崩潰，當時連續通宵了兩個晚上，才解決。
一入C++深似海，從此XX是路人。
以候捷在<<STL 源碼剖析>>上的一句話作為本文的結束語：
源碼面前，了無秘密。
共勉。