std::thread在linux默认栈仅2mb,远小于主线程的8mb,易因递归或大数组导致栈溢出崩溃;需通过pthread_attr_setstacksize或windows的createthread显式设置更大栈空间。

std::thread 默认栈太小,Linux 下只有 2MB
主线程默认有 8MB 栈(ulimit -s 查到),但 std::thread 在 Linux 上不继承这个值,而是用 pthread 默认的 2MB。哪怕主线程跑得好好的,子线程一进递归或分配大数组就崩——gdb bt 看起来只有几层帧,却报 Cannot access memory at address 或直接 abort,大概率是它。
这不是代码逻辑错,是资源配额不足。别急着改算法,先确认是不是这问题:
- 用
pthread_attr_t查当前线程栈大小:pthread_attr_getstacksize(&attr, &stacksize),注意stackaddr是栈底(低地址),不是栈顶 - 临时验证:在创建线程前加
pthread_attr_setstacksize(&attr, 8 * 1024 * 1024),再试运行 - 别漏掉
pthread_attr_init(&attr)和pthread_attr_destroy(&attr),否则内存泄漏
Windows 下用 CreateThread 指定栈大小更直接
Windows 线程默认仅 1MB,比 Linux 更容易触雷。C++ 标准库没暴露栈大小接口,所以得绕过 std::thread,直接调系统 API:
- 用
CreateThread(NULL, 8 * 1024 * 1024, thread_func, arg, 0, &tid),第二个参数就是栈大小(字节) - 函数签名要匹配
DWORD WINAPI thread_func(LPVOID),不能直接传 lambda - 返回的
HANDLE记得CloseHandle,不然句柄泄漏 -
GetThreadStackLimits只对当前线程有效,想监控只能在线程函数开头调
std::jthread + 自定义分配器不是银弹
C++20 的 std::jthread 本身也不带栈大小控制,所谓“更稳妥”其实是靠搭配自定义线程启动逻辑。真要可控,得组合:
- 写个封装函数,内部用
pthread_create(Linux)或CreateThread(Windows)创建,再把 native handle 包进std::jthread - 避免用
boost::thread的set_stack_size,它底层仍是封装 pthread/WinAPI,且 musl libc 不支持pthread_attr_setstacksize - 如果项目已重度依赖
std::thread,改用std::jthread并不会自动解决栈问题,只是多了 RAII 式 join/detach
增大栈只是临时手段,别跳过根本修复
放宽到 64MB 能让程序跑通,但掩盖了设计缺陷。尤其要注意:
- 栈大小是 per-thread 的,开 100 个线程 × 64MB = 6.4GB 虚拟内存,可能触发 OOM killer
- 大栈不解决局部变量爆炸问题:
char buf[1024*1024]还是会单次压入 1MB,哪怕总栈有 64MB - 调试时
gdb bt显示帧数正常,不代表安全——栈溢出可能静默覆盖相邻变量,行为不可复现
C++免费学习笔记(深入):立即使用
在学习笔记中,你将探索 C++ 的入门与实战技巧!











