关于Tomcat 9（含9.0.80+版本）NIO连接器优雅关机机制的疑问

嘿，我来帮你把Tomcat 9.0.80+版本里NIO连接器的优雅关机逻辑理清楚，结合你的配置和遇到的问题来说明：

首先看你给出的Connector配置：

<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
gracefulStopAwaitMillis="15000"
bindOnInit="false"
protocol="org.apache.coyote.http11.Http11NioProtocol" />

这里两个参数是优雅关机的核心：

• gracefulStopAwaitMillis="15000"：这就是Tomcat留给正在处理中的请求收尾的最大时间窗口。触发关机后，Tomcat会立刻停止接受新连接，然后等着已经在跑的请求完成，最多等15秒。如果到点还有请求没处理完，Tomcat会直接强制终止这些请求再退出。你的测试结果是对的——正常情况下，Tomcat确实会等现有请求处理完再关机。
• bindOnInit="false"：这个延迟绑定的配置完全是为了适配负载均衡场景（比如你的ALB+HAproxy架构）。重启时Tomcat不会一开始就占着端口，而是等自身完全启动就绪后再绑定端口；关机时则是先解绑端口，让负载均衡把新流量直接导去其他健康后端，之后再安心处理剩余请求。

那为什么偶尔会出现502呢？我给你分析几个大概率的原因：

• 健康检查的时间差：哪怕你配了健康检查，ALB和HAproxy的检查都是有间隔的。比如Tomcat开始优雅关机，先解绑了端口，但健康检查还没检测到它下线，这时候ALB把新请求发过来，自然就会因为端口无响应返回502。
• 长连接复用的坑：如果你的HAproxy和Tomcat用了HTTP长连接，Tomcat关机时会主动关闭这些长连接，但HAproxy可能还在复用旧连接发请求，这时候就会出现连接失败导致的502。可以检查下HAproxy里的长连接相关配置，比如timeout http-keep-alive，确保它能及时发现失效连接并重建。
• 等待时长不够用：如果你的业务里有处理时间超过15秒的请求，Tomcat到点就会强制终止这些请求，这时候客户端收到的错误经过负载均衡转发后，就可能表现为502。可以根据你实际的最长请求耗时，调整gracefulStopAwaitMillis的数值。

最后给你几个优化方向：

• 缩短HAproxy的健康检查间隔，比如改成1-2秒一次，让它更快感知到Tomcat的状态变化，减少时间差带来的502。
• 确保HAproxy的redispatch和retries配置生效（你已经在用了），同时可以用option httpchk做更精准的HTTP层面健康检查，而不是单纯的TCP端口检查。
• 查看Tomcat的关机日志，看看有没有“强制终止请求”的相关记录，这能直接判断是不是gracefulStopAwaitMillis设置得太短。

备注：内容来源于stack exchange，提问作者Daniel Sandberg