Linux线程数过多会导致系统负载升高、内存耗尽、调度延迟增大甚至触发OOM Killer，应通过定位源头、设置ulimit限制、调优内核参数及优化应用线程模型来综合治理。

Linux线程数过多会导致系统负载升高、内存耗尽、调度延迟增大，甚至触发OOM Killer。关键不是单纯“杀线程”，而是定位源头、合理设限、优化程序行为。

查清谁在创建大量线程

先确认是哪个进程或服务导致线程暴增：

• 用 ps -eLf | awk '{print $2}' | sort | uniq -c | sort -nr | head -10 查看线程数最多的前10个进程ID（PID）
• 再用 ps -T -p PID 查看该进程下所有线程的详细状态（LWP列即线程ID）
• 结合 cat /proc/PID/status | grep Threads 验证线程总数
• 若为Java应用，可加 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps 并检查是否因线程池未复用、new Thread()滥用导致

限制单进程最大线程数（ulimit）

防止某个进程无节制创建线程，可在启动前设置用户级限制：

• 临时生效：执行 ulimit -u 2048（限制该shell下进程总线程/进程数，注意 -u 是nproc，非专门线程数，但对多数场景有效）
• 永久生效：在 /etc/security/limits.conf 中添加
  username soft nproc 2048
  username hard nproc 4096
• 注意：systemd服务需额外在 service 文件中设 LimitNPROC=2048，否则 limits.conf 不生效

内核级防护：调整线程相关参数

避免全局资源被耗尽，可微调内核行为：

• 降低单个进程默认线程栈大小（节省内存）：ulimit -s 512（单位KB），Java可配合 -Xss256k
• 限制系统级最大线程数（不建议盲目调小）：echo 65536 > /proc/sys/kernel/threads-max，值建议设为 RAM(MB) × 2 左右
• 启用线程创建失败时快速报错而非卡死：echo 1 > /proc/sys/kernel/panic_on_oom（配合监控更稳妥）

从应用层根治：避免线程滥用

线程爆炸多源于设计缺陷，需代码和架构层面优化：

• 禁用“每请求一新线程”模式，改用线程池（如 Java 的 ThreadPoolExecutor、Go 的 goroutine + worker pool）
• 检查是否有未关闭的定时任务、监听器、回调注册，造成线程泄漏
• 异步I/O优先选 epoll/kqueue/io_uring，而非多线程阻塞模型
• 用 perf record -e sched:sched_process_fork 抓取频繁fork/clone行为，定位创建热点