1. 简介
本文将深入探讨主流 Java Web 应用服务器（如 Apache Tomcat、GlassFish 和 Oracle WebLogic）中线程池的配置方式。对于高并发场景，合理配置线程池是性能调优的关键一环，踩坑了轻则响应变慢，重则服务雪崩。
2. 服务器线程池概述
✅ 服务器线程池由 Web 容器本身管理，独立于部署的应用程序，这意味着它们的生命周期不受应用启停的影响。
与应用内创建的线程不同，服务器线程在应用停止后依然可能存活。这些线程主要用于处理 HTTP 请求的接收与分发，属于容器基础设施的一部分。
⚠️ 注意：线程池配置不当可能导致资源耗尽或上下文切换开销过大，需结合实际负载谨慎调整。
3. Apache Tomcat 线程池配置
Tomcat 使用 Executor 组件来管理线程池，可在 server.xml 中进行声明式配置：
<Executor
name="tomcatThreadPool"
namePrefix="catalina-exec-"
maxThreads="150"
minSpareThreads="25"/>
关键参数说明：
minSpareThreads：初始化及空闲时保持的最小线程数（默认 25）maxThreads：最大并发处理线程数，超过后请求将被排队（默认 200）
上面配置将最大线程数从默认的 200 降低至 150，适用于资源受限但请求处理较快的场景。
3.1 嵌入式 Tomcat（Spring Boot）
在 Spring Boot 项目中，可通过配置文件直接设置线程池参数：
# Spring Boot 2.3 之前
server.tomcat.max-threads=250
从 Spring Boot 2.3 开始，属性命名更规范：
server:
tomcat:
threads:
max: 250
min-spare: 25
✅ 推荐使用 YAML 格式，结构更清晰，避免拼写错误。
4. GlassFish 线程池配置
GlassFish 采用命令行工具 asadmin 进行线程池管理，与 Tomcat 的 XML 配置形成对比。
创建线程池的基本命令如下：
asadmin> create-threadpool \
--maxthreadpoolsize 250 \
--minthreadpoolsize 25 \
--idletimeout=2 \
threadpool-1
参数说明：
--maxthreadpoolsize：最大线程数（等效于 Tomcat 的maxThreads）--minthreadpoolsize：最小空闲线程数--idletimeout=2：线程空闲 2 秒后回收
⚠️ 注意：idletimeout 单位是秒，过短可能导致频繁创建/销毁线程，增加开销。
5. WebLogic 线程池配置
WebLogic 采用 WorkManager 机制实现自适应线程池（Self-Tuning Thread Pool），其核心特点是：
✅ 动态调整：基于实时吞吐量自动增减线程数
✅ 智能分析：定期评估性能指标，优化线程利用率
虽然可以设置上下限，但最终线程数由容器动态决策，开发者无法完全控制。
配置入口
通过 WebLogic Admin Console 进行设置：
关键配置项：
- Self Tuning Minimum Thread Pool Size：最小线程数
- Self Tuning Thread Maximum Pool Size：最大线程数
- Stuck Thread Max Time：判定线程“卡住”的阈值（单位：秒）
- Stuck Thread Timer Interval：检测卡顿线程的时间间隔
💡 举个例子：若某接口因数据库慢查询导致处理时间超过 Stuck Thread Max Time，WebLogic 会认为该线程“卡住”，并尝试创建新线程补偿，但这只是治标不治本。
❌ 踩坑提醒：频繁出现卡顿线程通常是代码问题（如死锁、长事务、同步阻塞），应优先排查根本原因，而非盲目调大超时时间或线程上限。
6. 总结
本文对比了三种主流 Java Web 服务器的线程池配置方式：
| 服务器 | 配置方式 | 是否支持动态调整 |
|---|---|---|
| Tomcat | XML / 配置文件 | ❌ 静态 |
| GlassFish | asadmin 命令 | ❌ 静态 |
| WebLogic | WorkManager | ✅ 自适应 |
✅ 核心建议：
- 线程池调优不能掩盖低效代码，性能问题优先从应用层解决
- 生产环境调整前务必压测验证
- 监控线程状态（活跃数、队列长度、卡顿情况）是调优前提
合理配置线程池是系统稳定的基石，但切记：架构决定上限，代码决定下限。