资源受限高连接场景下Spring WebSocket（非STOMP）服务器选型咨询

1. Tomcat是否适用？ #

不适用。
你提到的“每个请求一个线程”是Tomcat早期BIO模式的情况，但现在Tomcat默认用NIO模式（多路复用IO），不过它的WebSocket实现依然依赖线程池处理连接的IO事件和业务逻辑。普通PC的线程资源有限，默认线程池最大仅200左右，就算强行调大线程数，线程上下文切换开销会指数级上升，且每个线程1MB左右的栈内存会快速耗尽普通PC的内存——数百万连接对应的线程规模根本不是普通PC能承载的。另外Tomcat架构相对臃肿，资源占用高，在数百万长连接场景下，普通PC的CPU、内存、文件句柄会很快耗尽。

2. Undertow是否合适？ #

依然不合适，但比Tomcat表现更好。
Undertow是轻量级NIO服务器，采用IO线程+工作线程的模型，IO线程负责监听和分发事件，工作线程处理业务，资源占用比Tomcat低很多。但普通PC的硬件瓶颈无法突破：数百万长连接需要大量文件句柄（每个连接对应一个），普通PC默认文件句柄数仅几千，就算调优到几万也远达不到数百万量级；同时每个连接会占用少量内存，数百万连接累加的内存开销，普通PC也难以承受。所以Undertow虽比Tomcat高效，但在普通PC上扛数百万长连接仍超出硬件极限。

3. 切换至WebFlux+Netty是否可行？ #

这是当前场景下唯一有可能实现的方案。
WebFlux基于响应式编程模型，底层依赖Netty服务器，Netty是异步非阻塞的事件驱动框架，采用Reactor模式，不需要为每个WebSocket连接创建单独线程——少数几个IO线程就能处理数千甚至上万连接，线程上下文切换开销极低，内存占用远低于Tomcat和Undertow。

不过要在普通PC上扛数百万连接，还需做大量调优：

• 调整Netty参数：开启SO_REUSEADDR、TCP_NODELAY，优化接收/发送缓冲区大小，调整连接超时时间等；
• 优化操作系统参数：大幅调高文件句柄上限（比如至数百万），调整TCP相关参数（如tcp_tw_reuse、tcp_fin_timeout等）；
• 优化应用代码：确保所有业务逻辑非阻塞，避免在响应式链中调用阻塞API，否则会拖垮整个线程池。

即便如此，普通PC的内存、CPU、网络带宽依然是最大限制——数百万长连接所需的内存和吞吐量，普通PC可能仅能勉强支撑，但相比前两种方案，这是唯一有机会达成目标的选择。

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