java nio不内置连接数上限拒绝策略，需在acceptor线程中于accept前用原子计数器检查阈值，超限则立即close新channel、记录日志并异步上报指标，配合空闲超时、前置限流等容量治理手段。
Java NIO 本身不内置“连接数上限拒绝策略”，它只提供底层通道（Channel）、选择器（Selector）和缓冲区等机制；连接数限制与拒绝逻辑必须由应用层显式实现。关键不是等连接涌进来再拦，而是从 接入入口主动控制，并配合清晰的反馈行为。
在 Acceptor 线程中做连接数检查
NIO 服务端通常用一个或多个 NioSocketAcceptor（如使用 Apache Mina）或基于 ServerSocketChannel + Selector 自建 Acceptor。无论哪种，都应在 OP_ACCEPT 事件触发后、调用 serverChannel.accept() 前，判断当前活跃连接数是否已达阈值：
- 维护一个原子计数器（如
AtomicInteger connectedCount），在成功建立连接后incrementAndGet() - 若已达上限，直接关闭新来的
SocketChannel，不注册到 Selector，也不分配任何资源 - 可选：向客户端发送简短拒绝提示（如写入 "BUSY" 后关闭），但注意避免阻塞或写超时
拒绝时的典型响应方式
连接被拒不是静默丢弃，而应让客户端快速感知失败，避免重试风暴：
- 立即 close() 新 Channel：不注册、不读写、不放入连接池，这是最轻量的做法
-
记录日志 + 上报指标：例如用 Micrometer 记录
reject_connections_total{reason="max_limit"}，便于监控告警 - 避免在 Acceptor 线程中执行耗时操作：如写数据库、发 HTTP 告警、序列化大对象——这些必须异步化，否则会拖慢整个 accept 循环
配套的容量治理手段
仅靠拒绝不够，要从源头缓解压力：
- 设置合理的最大连接数，参考系统可用文件描述符数（
ulimit -n）、内存与业务并发模型 - 为每个连接配置空闲超时（
readTimeout/idleStateHandler），及时释放僵尸连接 - 在网关或前置负载均衡层做连接限流（如基于 IP 或 token 的连接数限制），减轻后端 NIO 服务压力
- 如果用 Netty，可结合
ConnectionLimitHandler或自定义ChannelInboundHandler在 pipeline 前置拦截
与线程池拒绝策略的本质区别
连接数拒绝 ≠ 线程池拒绝策略（如 AbortPolicy）。前者发生在网络接入层（TCP 连接建立阶段），后者发生在任务执行层（任务提交到 ExecutorService）。两者目标一致——防止雪崩，但作用域和时机完全不同。不要试图把线程池的 RejectedExecutionHandler 拿来处理连接拒绝。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
