线程栈大小直接影响并发线程数与内存效率，过大导致内存浪费和OOM，过小引发栈溢出；应通过ulimit、pthread_attr_setstacksize或-Xss实测调优，在安全前提下贴近实际需求。
Linux中线程栈大小直接影响可创建线程总数和内存使用效率，设置不当会导致“Cannot allocate memory”错误或大量内存浪费。
线程栈大小如何限制并发线程数
每个线程在用户空间默认分配固定大小的栈（通常为8MB），该内存从进程的虚拟地址空间中预留。系统能创建的线程数 ≈ 进程可用虚拟内存 / 单线程栈大小。例如：32位进程地址空间约3GB，设栈为8MB，则理论最多约384个线程；64位进程虽地址空间极大，但受RLIMIT_STACK和物理内存/swap限制，实际仍受限。
- 栈空间由mmap分配，计入进程的VSZ（虚拟内存大小）和部分RSS（常驻内存）
- ulimit -s 显示当前软限制（单位KB），超过则线程创建失败
- 即使线程只用几KB栈，只要未被内核回收（如线程未退出或未调用pthread_detach），8MB就持续占用
默认8MB栈在高并发场景下的问题
现代服务（如Web服务器、消息队列客户端）常需成千上万轻量级线程，沿用默认栈会迅速耗尽内存资源：
- 1000个线程 × 8MB = 8GB虚拟内存，远超多数应用实际需求
- 大量空闲栈页导致TLB压力增大、页表膨胀，影响上下文切换性能
- 在容器或低内存环境（如1GB RAM容器）中，可能因OOM killer终止进程
合理调整线程栈大小的方法
应根据线程实际栈深度动态设定，而非统一调大或调小：
- 启动前用 ulimit -s [KB] 设置全局默认值（如 ulimit -s 512 将栈设为512KB）
- 编程时通过 pthread_attr_setstacksize() 在创建线程前指定（注意单位是字节，且需 ≥ PTHREAD_STACK_MIN）
- Java可通过 -Xss 参数控制线程栈（如 -Xss256k），Go则无需手动设（goroutine栈初始仅2KB，按需增长）
- 建议实测：用 perf record -e syscalls:sys_enter_clone 或 /proc/[pid]/maps 观察线程栈真实使用量
过度缩减栈的风险与规避
栈太小易引发栈溢出，表现为段错误（SIGSEGV）或静默数据损坏（尤其递归调用、大局部数组、深度回调）：
- C语言中局部数组如 char buf[1024*1024] 在1MB栈下即越界
- 某些库（如glibc的getaddrinfo）内部使用较大临时栈空间
- 安全做法：先压测确定最小安全值（如用stress-ng或自定义递归函数探测），再留20%余量
- 启用编译选项 -fstack-protector-strong 和运行时 ASLR 可缓解溢出危害
线程栈不是越大越好，也不是越小越优——关键是在栈安全水位之上，尽可能贴近真实负载所需。一次合理的测量+一次谨慎的下调，往往比盲目接受默认值提升数倍并发上限。
