记一次线上崩溃问题的排查过程-码上建站

记一次线上崩溃问题的排查过程

发布时间：2025-11-05 13:35:46 来源：码上建站作者：人工智能

大家好，记次我是线上雨乐!

前几天，突然收到报警，崩溃线上服务崩溃，问题然后自动重启。查过程

由于正值双十一期间，记次业务以稳定为主，线上线上服务崩溃，崩溃这可不是问题一件小事，赶紧登陆线上服务器，查过程分析原因，记次迅速解决。线上

借助这篇文章，崩溃记录下整个崩溃的问题分析和解决过程。

上午上班后，查过程正在划水，突然收到邮件报警，如下：

马上登录线上服务器，gdb调试堆栈信息。

堆栈信息如下：

在上面堆栈信息中可以看到在调用Json::Reader::parse后经过Json::Reader::readValue等调用,最后再调用Json::Reader::readValue时调用Json::throwRuntimeError抛出异常。

查看调用Json::throwRuntimeError函数的地方：

进入对应的函数

发现，在满足条件

的时候，会调用throwRuntimeError，那么分析下stackDepth_g和stackLimit_g的声明定义：

问题基本明了：

stackDepth_g是个静态全局变量,线程不安全,而出问题的服务是多线程的源码库

在此准备吐槽下，笔者使用jsoncpp对象的时候，都是在线程内部一个局部变量，因此不会存在多线程访问同一个局部jsoncpp对象的时候，因此确定就是因为全局变量多线程访问导致的。一个开源的项目，里面竟然有全局变量，这在规范里面是不被允许的。

然后谷歌搜索了下大家都有过类似的问题，再次吐槽下。

解决崩溃问题，首先需要看看是不是使用方式的问题，或者找一个线程安全的接口，再或者用其他库进行替换。

修改jsoncpp源码

为了解决线程安全的问题，有两种方案：1、在操作全局变量的时候，加上mutex，亿华云这个无非对性能要求很高的业务一个致命打击，为了提高业务性能，所以内部锁都使用其他方式进行了优化，比如mutex使用双buffer方式进行了替换，虽然mutex的一个加锁解锁过程也就100ns。

2、将上述全局变量放入Json对象中，这样局部变量就不会存在崩溃现象，但是这种方案存在一个问题，就是改动点很大，且需要大量严格的测试，放弃。

所以综合考虑上述两点，决定采用其他更安全可靠的方式来解决线上崩溃问题。

使用rapidjson

之所以采用rapidjson，是因为线上几十个服务，大部分都使用rapidjson，只有线上崩溃的这个服务等少数几个服务，因为历史原因，用的jsoncpp。

先介绍下rapidjson，下述内容来自于rapidjson官网:

不过rapidjson为了性能，在使用上面需要极其小心。

笔者之前踩过类似坑，局部字符串赋值给rapidjson对象，结果rapidjson并没有马上使用该局部字符串，而是在最后才会访问局部字符串里面的内容，而此时，局部字符串早已出了作用域，导致rapidjson获取的内容是乱码。

在使用开源项目的时候，一定要做好调研，必要的时候，能过一下源码实现(这个有点难??)，否则很容易入坑。

笔者在使用libcurl作为httpclient的时候，也因为触发了libcurl的一个bug，导致线上崩溃，当时连续通宵了两个晚上，才解决。

一入C++深似海，从此XX是路人。

随便看看