Clojure Web应用（Luminus+Ring+Undertow）何时启用多线程处理请求？

算力阿峰

2026-5-20

关于Luminus/Ring + Undertow的非阻塞请求处理时机

首先咱们先理清你测试里出现串行等待的核心原因：你用(Thread/sleep 20000)做的是纯阻塞操作，再加上两个浏览器层面的细节——Chrome对同一域名下的相同URL请求，默认会做串行处理（浏览器的缓存优化策略，避免重复请求同一资源）；同时Ring默认的同步处理模型下，每个请求会占用一个Undertow的工作线程，这个线程被sleep死死占住时，后续请求只能排队等线程释放，所以才会出现第二个标签页等20秒的情况。

接下来聊聊什么时候Undertow会用独立的非阻塞线程处理请求：

处理I/O密集型操作时（使用异步Ring Handler）
当你的请求涉及数据库查询、远程HTTP调用、文件读写这类I/O操作时，如果改用Ring的异步处理方式（比如返回core.async的Channel，或者实现AsyncHandler接口），Undertow的I/O线程会把请求的后续处理交给专门的非阻塞线程池，自己立刻回去处理其他请求。这样就不会因为单个I/O操作拖慢整体并发能力。
对接Undertow原生非阻塞API
Luminus默认集成了Undertow，如果你直接使用Undertow的原生非阻塞API（比如实现io.undertow.server.HttpHandler的异步逻辑），再通过Ring适配器对接，Undertow会自动调度非阻塞线程来处理请求，避免阻塞核心线程池。
将阻塞操作移到独立线程池
如果你不得不做一些阻塞操作（比如测试里的sleep，或者某些仅支持同步调用的第三方库），别直接在请求处理线程里执行，而是把它放到自定义线程池（比如clojure.core.async的线程池，或者java.util.concurrent提供的线程池）里，让请求线程快速返回，由后台线程完成阻塞操作后再响应客户端。这样Undertow的核心线程不会被占用，能同时处理更多请求。

举个简单的异步改造例子，用core.async改写你的测试Handler：

(ns your-app.handler
  (:require [clojure.core.async :as async]
            [ring.util.response :as response]))

(defn sleep-handler [request]
  (async/go
    (Thread/sleep 20000)
    (response/response "Done!")))

这个Handler返回的是一个Channel，Ring的异步适配器会通知Undertow不要占用当前线程，等Channel里有结果了再发送响应。这时候你换不同URL测试（或者关闭Chrome缓存强制并行），就能看到两个请求同时处理了。

最后补充个细节：Undertow的线程模型分为I/O线程（负责处理网络连接，本身是非阻塞的）和工作线程（处理请求逻辑），只有当你的Handler是异步实现时，工作线程才会被及时释放，真正实现非阻塞的并发处理。

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