Tomcat 8.5中JSR 356 WebSocket线程模型技术咨询

先直接给你明确核心结论：客户端与服务器建立WebSocket持久会话后，不同的消息（无论是客户端发送还是服务器主动推送）并不会绑定到同一线程处理，而是由Tomcat共享的Worker线程池中的不同线程来处理。下面我会一步步拆解这个模型的运作逻辑：

1. WebSocket连接的生命周期与线程分工 #

WebSocket的整个流程分为两个关键阶段，每个阶段的线程处理逻辑完全不同：

（1）握手阶段：HTTP线程池处理 #

WebSocket的连接建立始于HTTP握手请求，这个阶段完全由Tomcat的HTTP Worker线程池（默认命名类似nio-8080-exec-*）处理。线程会完成握手协议验证、协议升级，最终将连接从HTTP切换到WebSocket协议，之后这个连接就会被交给Tomcat的NIO连接器管理。

（2）会话阶段：NIO多路复用+共享线程池处理 #

握手完成后，WebSocket连接进入持久会话阶段，Tomcat的NIO模型会用三类线程协同处理：

• Acceptor线程：仅负责监听TCP端口，接收新的连接请求，然后将连接转交给Poller线程，它不处理具体的消息逻辑。
• Poller线程：这是Selector线程，负责轮询所有已建立的WebSocket连接的IO事件（比如客户端发送消息的可读事件）。当检测到某个连接有可读事件时，它会将读取消息的任务封装成SocketProcessor，提交到共享的Worker线程池。
• Worker线程池：这是核心的业务处理线程池，负责执行消息的读取、解码，以及调用你实现的WebSocket端点类中的@OnMessage、@OnClose等注解方法。同一个WebSocket连接的不同消息，大概率会被不同的Worker线程处理，因为Worker线程是共享的，Tomcat会根据线程池的负载情况分配空闲线程。

2. 为什么不采用“专属线程”模式？ #

这种设计完全是为了应对高并发场景：

• 如果为每个WebSocket连接分配一个专属线程，当并发连接数达到数千甚至上万时，线程上下文切换的开销会急剧增加，服务器CPU、内存资源会被快速耗尽。
• NIO多路复用的核心优势就是用少量线程（Poller线程通常只有几个，Worker线程池可配置）处理大量并发连接，大幅提升服务器的承载能力。

3. 服务器主动推送消息的线程处理 #

如果你的业务逻辑需要从非WebSocket端点线程（比如定时任务线程、其他HTTP请求线程）主动给客户端推送消息，直接调用RemoteEndpoint.sendText()或sendBinary()即可——Tomcat的实现保证了这个操作是线程安全的。底层会将发送任务放入对应连接的队列中，由Poller线程或Worker线程在合适的时机执行发送操作，不需要你额外处理线程同步。

4. 开发时的注意事项 #

• 因为同一连接的消息可能由不同线程处理，如果你在WebSocket端点类中维护了状态变量（比如用户的会话数据），一定要确保这些变量的线程安全性，比如使用volatile、ConcurrentHashMap等线程安全的工具类。
• Worker线程池的大小可以通过Tomcat的server.xml配置文件调整，比如修改Executor标签的maxThreads参数，来适配你的并发需求。

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