生产环境Spring Boot应用线程创建失败（pthread_create EAGAIN）求助

错误原因分析 #

日志中的pthread_create failed (EAGAIN)是核心问题，说明系统无法为JVM创建新的本地线程，通常由以下原因导致：

• 进程已达到系统允许的最大线程数限制
• Hikari连接池配置不合理，导致过度创建数据库连接及关联线程
• 应用存在线程泄漏，未及时回收闲置线程

分步解决方案 #

1. 检查并调整系统线程限制 #

• 查看当前用户的线程数上限：

  ulimit -u
  

  查看系统全局线程数上限：

  cat /proc/sys/kernel/threads-max
  

• 查看应用进程的当前线程数（替换<pid>为你的Spring Boot进程ID）：

  ps -eLf | grep <pid> | wc -l
  

• 如果线程数接近上限，可临时调整用户线程限制：

  ulimit -u 4096
  

  永久调整需修改/etc/security/limits.conf文件，添加：

  <your-username> soft nproc 4096
  <your-username> hard nproc 4096
  

2. 优化Hikari连接池配置（修正不合理建议） #

ChatGPT给出的maximum-pool-size=200过大，会导致大量数据库连接及关联线程，反而加重线程耗尽问题。合理配置需结合CPU核心数和数据库承载能力：

# Hikari连接池优化配置
spring.datasource.hikari.maximum-pool-size=20  # 建议值：CPU核心数*2+1，避免过度创建连接
spring.datasource.hikari.minimum-idle=5       # 保持少量闲置连接，避免频繁创建销毁
spring.datasource.hikari.idle-timeout=30000    # 闲置连接超时回收
spring.datasource.hikari.max-lifetime=1800000  # 连接最大生命周期（30分钟），强制回收旧连接
spring.datasource.hikari.pool-name=MyHikariCP  # 自定义池名，方便日志排查

3. 排查应用线程泄漏 #

• 使用JVM工具导出线程栈分析：

  jstack <pid> > thread_dump.txt
  

  查看thread_dump.txt中是否存在大量处于WAITING或BLOCKED状态的线程，尤其是自定义线程池、异步任务相关的线程。
• 检查应用中是否存在未正确关闭的线程池、异步任务，确保所有线程池都配置了合理的corePoolSize、maximumPoolSize及keepAliveTime，避免线程无限增长。

4. 调整JVM线程栈大小 #

日志中显示线程栈大小为1024k，过大的栈会占用更多内存，限制可创建的线程总数。可通过JVM启动参数减小栈大小：

# 在启动脚本中添加
-Xss512k

注意：栈大小不宜过小，需避免出现StackOverflowError，可根据应用实际情况调整为512k-1024k之间。

内容的提问来源于stack exchange，提问作者SebastianDev