关键在于线程、连接、队列与系统资源协同优化：设minThreads为20–50、maxThreads为400–800，acceptQueueSize为1024，idleTimeout为30–60秒，配合Linux句柄数≥65536、JVM堆≥4GB及G1GC，并限制构建并发数与插件扫描。
要让 Jenkins 内置 Jetty 容器稳定支撑上千客户端并发调用，关键不是堆线程数，而是让线程、连接、队列、系统资源四者协同不卡顿。Jenkins 默认 Jetty 配置偏保守，直接面对高并发容易出现响应延迟、任务堆积甚至 503 错误。
Jetty 线程池参数精准配置
Jetty 使用 QueuedThreadPool，其核心是 minThreads 和 maxThreads，而非 JDK 的 core/max 概念。对 Jenkins 这类 IO 密集型 Web 应用（含大量插件调用、Git 拉取、日志流、API 响应），建议按以下逻辑设定：
- minThreads 设为 20–50：保证启动后总有足够线程处理日常请求（如 UI 加载、小规模构建触发），避免冷启动抖动
- maxThreads 设为 400–800：按「预期峰值并发请求数 × 1.25」估算（例如 600 个活跃构建+API 调用，对应 750 线程），上限不建议超 1000，否则 JVM GC 和上下文切换开销剧增
- 禁用
detailedDump（设为 false）：避免频繁线程快照拖慢性能 - 不依赖
minSpareThread/maxSpareThread：Jetty 9+ 已弃用这些旧参数，仅需配 min/max
连接器（Connector）与底层队列协同调优
Jenkins 默认使用 NIO 模式 SelectChannelConnector（Jetty 9 后为 ServerConnector + HttpConnectionFactory），必须同步调整其连接行为：
- acceptQueueSize 设为 1024：提升 TCP 连接排队能力，缓解瞬时洪峰冲击
- idleTimeout 控制在 30000–60000ms：避免长连接空耗线程，尤其 Jenkins 流水线日志流、Agent 心跳等场景
- acceptors 设为 CPU 核心数（如 4–8）：匹配内核调度能力，过多 acceptor 反而争抢锁
- lowResourcesConnections 设为 800：当活跃连接超此值，自动降级（如缩短 idleTimeout），防止雪崩
操作系统与 JVM 层面配套加固
Jetty 参数再合理，若 OS 或 JVM 托不住，一切优化归零：
-
Linux 文件句柄数：Jenkins 进程需至少 65536 句柄（
nofile=65536），否则大量 HTTP 连接或 Agent 通道会报 “Too many open files” -
TCP 队列与缓冲区：执行
sysctl -w net.core.somaxconn=4096和net.core.netdev_max_backlog=16384，避免连接被内核丢弃 -
JVM 堆与 GC：堆内存不低于 4GB（
-Xms4g -Xmx4g），推荐 G1GC，添加-XX:MaxGCPauseMillis=200控制停顿 -
禁用 DNS 反查：在
jenkins.xml或启动脚本中加-Dhudson.DNSMultiCast.disabled=true -Dsun.net.inetaddr.ttl=30，避免请求因 DNS 卡住
配套 Jenkins 自身配置收敛压力
线程池只是入口，真正压垮 Jenkins 的常是内部任务膨胀：
- 限制全局并发构建数（Manage Jenkins → Configure System → # of executors）：设为 20–40，避免单次构建拉满线程池
- 关闭非必要插件的后台扫描（如
CloudBees Folder Plugin的定期索引） - 将日志级别调至 WARN（Manage Jenkins → System Log → Add new log recorder），减少 I/O 写入竞争
- 对高频 API（如
/job/{name}/lastBuild/api/json）启用 Nginx 缓存或加限流（如令牌桶），减轻 Jetty 直接压力
