多线程栈溢出主因是各std::thread独立栈（linux默认2mb）耗尽，gdb bt仅显几层却报cannot access memory即典型表现；必须用thread_local控递归深度、大数组移至堆、显式pthread_create配栈大小或启用-fstack-protector-strong+asan预防。
多线程环境下，栈溢出无法靠全局 ulimit -s 统一控制，每个 std::thread 的栈是独立分配且默认大小受限（Linux 通常 2MB，Windows 仅 1MB），崩溃时 gdb bt 可能只显示几层调用却报 Cannot access memory at address —— 这大概率是单线程栈耗尽，而非程序级栈限制问题。
std::thread 栈大小不可靠，必须显式指定
默认构造的 std::thread 使用系统默认栈空间，但这个值在不同平台、不同 libc 版本下不一致，且无法在运行时查询。依赖它等于埋雷。
- Linux 下 pthread 默认栈大小由
pthread_attr_getstacksize决定，但 C++ 标准库未暴露该接口，std::thread构造时不提供栈尺寸参数 - 真正可控的方式只有：用
pthread_create手动传入pthread_attr_t配置栈大小，再用std::thread包装原生句柄（需小心生命周期） - 更现实的做法：避免在线程函数内做深度递归或声明大数组；把大内存需求移出栈 —— 比如把
char buf[65536]改成std::vector<char> buf(65536)</char>或std::unique_ptr<char> buf = std::make_unique<char>(65536)</char></char>
编译器栈保护对多线程有效，但有覆盖盲区
-fstack-protector-strong 对每个函数插入金丝雀（canary），无论它在哪条线程里执行。但它只保护“含局部数组或调用 alloca”的函数 —— 如果你的线程入口函数只是层层调用小函数、无大数组、无 alloca，那整个调用链可能完全不触发金丝雀检查。
- 验证是否生效：用
objdump -d your_binary | grep __stack_chk_fail，有输出才说明至少部分函数受保护 - 别依赖
-fstack-protector（弱模式），它只保护含数组的函数；必须用-fstack-protector-strong或-fstack-protector-all - 注意：金丝雀不能防止栈帧过大导致的直接耗尽，只能检测“被覆盖”，所以它防不了
char big[2*1024*1024]这种纯空间吞噬
递归深度必须线程本地化控制
主线程设了 depth > 1000 就 throw，不代表子线程安全 —— 每个线程有自己的栈，递归计数必须是线程局部变量，不能用全局或静态变量共享。
- 错误写法：
static int depth = 0; ++depth; if (depth > 1000) throw ...—— 多线程并发修改，结果不可预测 - 正确写法：用
thread_local int depth = 0;，或把 depth 作为函数参数向下传递（推荐，更清晰） - 若用
std::stack模拟递归，记得容量也得控制：比如if (node_stack.size() > 2000) throw std::runtime_error("stack-based recursion too deep");
崩溃现场难以捕获，不要指望 try/catch
Stack overflow 是操作系统信号（SIGSEGV 或 SIGBUS），不是 C++ 异常，try/catch(...) 完全无效。你无法在崩溃点附近加异常处理来“兜底”。
- 唯一可行的防御时机是在出问题之前：控制递归深度、禁用大栈变量、用地址 sanitizer 编译测试（
g++ -fsanitize=address,undefined） - 生产环境可注册
signal(SIGSEGV, handler)做有限日志（如打印线程 ID 和栈大小），但不能恢复执行 —— 栈已损坏，继续运行风险极高 - 最易被忽略的一点：调试时用
gdbattach 后看到的bt可能不完整，因为栈指针已乱；应优先看 core dump 文件，并用readelf -l core | grep STACK确认实际栈映射范围
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
