核心是将耗时操作从tomcat容器线程池剥离至独立业务线程池执行，以释放容器线程快速复用；必须分离因默认共用线程池会导致长延时操作阻塞请求处理，引发排队或拒绝；异步servlet仅提供挂起机制，需显式注入自定义threadpoolexecutor并调用submit而非start，配合@webservlet(asyncsupported=true)、及时返回、超时设置三要素才能生效。
核心是把耗时操作从 Tomcat 容器线程池中剥离出来，交由独立业务线程池执行，让容器线程快速归还、复用。
为什么必须分离线程池
Tomcat 默认用同一个线程池（如 Executor）处理请求接收、业务执行和响应写出。一旦某个请求里有数据库查询、远程调用或文件读写等长延时操作，该线程就会被卡住，无法服务新请求。线程池满后，后续请求只能排队或被拒绝。
异步 Servlet 本身不提升性能——它只是提供了一个机制：允许你在 service() 方法里“暂停”当前容器线程，保存 Request/Response 上下文，再把真正耗时的逻辑扔进另一个线程池去跑。
如何配置与注入业务线程池
不能依赖 AsyncContext.start(Runnable) 默认走容器线程池（那是陷阱）。必须显式使用自定义线程池：
Giga Coding Agent
下载
一款AI工具，主要用于通过后台进程运行 Codex CLI、Claude Code、OpenCode 或 Pi Coding Agent，实现程序化控制，适合需要提升相关任务效率的用户。
- 在应用启动时创建并存入
ServletContext，例如用ThreadPoolExecutor配置核心数、最大数、队列容量和拒绝策略 - Servlet 中通过
getServletContext().getAttribute("executor")获取该线程池 - 在异步任务中，用
executor.submit(() -> { /* 耗时逻辑 */ ctx.complete(); })替代ctx.start(...)
这样所有 IO 密集型任务都运行在你可控的池中，不会挤占 Tomcat 接收连接和分发请求的能力。
关键操作不能遗漏
启用异步支持只是第一步，以下三点决定是否真正生效：
-
声明支持：Servlet 类加
@WebServlet(asyncSupported = true)或 web.xml 中配置<async-supported>true</async-supported> -
及时释放容器线程：调用
req.startAsync()后，doGet/doPost方法应立即返回，不可再操作response.getWriter()或调用response.flushBuffer() -
超时兜底：设置
asyncContext.setTimeout(5000)，防止业务线程池过载或下游异常导致连接长期挂起
典型长延时场景适配建议
不是所有慢操作都适合直接丢进线程池：
- 远程 HTTP 调用：优先改用非阻塞客户端（如 WebClient），避免线程空等；若必须用 RestTemplate，确保线程池大小匹配预期并发量
- JDBC 查询：考虑配合连接池（如 HikariCP）+ 异步线程，但注意 Connection 不跨线程共享；更优解是迁移到 R2DBC
-
文件上传/下载：大文件建议用
ServletInputStream.setReadListener+ 非阻塞 IO，而非传统同步流 + 线程池搬运
线程池不是万能胶，它解决的是“阻塞等待”，而不是“高吞吐IO”。搭配非阻塞 IO 才是 Servlet 5.0 及以后的演进方向。
