栈溢出导致硬崩溃而非假死，表现为进程直接终止、日志中断、生成core dump；需通过ps、日志、core文件及ulimit确认，并用gdb回溯定位；修复须将大数组/缓冲区移至堆，禁用gets等危险函数，校验输入长度并改递归为迭代。
这类问题本质不是“假死”，而是栈溢出触发的硬崩溃——程序不会卡住、无响应或CPU飙高，而是直接终止并产生段错误（Segmentation fault）或 Windows 的 0xC00000FD 错误。所谓“假死”是误判，真正现象是：服务突然退出、日志戛然而止、核心转储（core dump）生成、监控显示进程消失。
确认是否为栈溢出而非其他假死
先排除 JVM Safepoint 卡住、GC 长时间 STW、线程死锁等真·假死场景：
- 查进程状态：
ps -p <pid></pid>若已不存在，不是假死，是崩溃 - 看日志末尾：是否有
*** stack smashing detected ***或Aborted (core dumped) - 检查是否存在
core.*或hs_err_pid*.log：有则大概率是崩溃，不是假死 - 用
ulimit -s查当前栈限制（如 8192 KB），再对比代码中最大可能栈占用（如char buf[1024*1024]就占 1MB）
定位超长字符串引发的栈越界点
关键不在“序列化”，而在字符串如何被接收、存放和处理。常见高危链路：
- 用
gets、fgets(buf, BIG_NUM, ...)但BIG_NUM超过栈空间 → 直接溢出 - 将 JSON/XML 字符串整体读入栈数组（如
char json[65536]），再调用解析函数 → 栈帧瞬间暴涨 - C++ 中
std::array<char></char>或大尺寸结构体按值传参 → 全量拷贝压栈 - 递归解析嵌套结构（如深层 JSON 对象）→ 每层都分配缓冲区，深度 × 单层开销 = 栈耗尽
快速验证与复现方法
不依赖用户输入，用可控方式触发：
- 写一个最小测试函数，声明
char dummy[1024*1024]并初始化，看是否立即崩溃 - 用
gdb ./app core后执行bt：若调用栈极深（>500 层）或出现重复函数名（如parse_value → parse_value → …），是递归栈溢出 - 若
bt只有 2–5 层，但崩溃在main或某个入口函数内，且该函数定义了大数组 → 是单帧栈溢出 - 在 Linux 下临时放宽栈限制：
ulimit -s 65536再运行，若不再崩溃 → 基本锁定为栈空间不足
修复路径：从栈到堆，从静态到受控
根本原则：任何可能超长的数据，绝不分配在栈上；所有字符串操作必须带长度约束。
- 替换危险接收方式：
gets→fgets(buf, sizeof(buf)-1, stdin)；sprintf→snprintf - 大缓冲区一律改用堆分配：
std::vector<char> buf(1024*1024)</char>或std::unique_ptr<char> buf = std::make_unique<char>(size)</char></char> - 禁止在栈上声明超限数组：编译时加
-Wstack-protector和/analyze:stacksize（MSVC）预警 - 对输入字符串做前置校验：解析前先
strlen或流式扫描，超长则拒绝或截断，不进解析逻辑 - 递归解析改为迭代：用
std::stack<parsestate></parsestate>管理上下文，避免函数调用栈累积
不复杂但容易忽略：真正的风险不在“字符串多长”，而在于“它被放在哪、怎么传、谁负责释放”。盯住内存归属，比优化算法更能守住上线底线。
