Java AIO中限制连接数需在AsynchronousServerSocketChannel的completed()回调中用AtomicInteger计数，超限时立即close通道并减计数；同时启用SO_REUSEADDR、设置SO_KEEPALIVE及应用层超时，并配合ulimit调优和fd监控防泄漏。
Java NIO 本身不直接提供“限制连接数”的开关，但可以通过编程方式在连接建立的第一时间做拦截和计数，实现精准、轻量、非阻塞的并发连接控制。核心思路是：在 AsynchronousServerSocketChannel 的 completed() 回调中检查当前活跃连接数，超限时主动关闭新通道，不分配资源、不触发后续读写逻辑。
用 AtomicInteger + CompletionHandler 控制接入连接数
这是最常用且低开销的做法，适用于基于 AsynchronousServerSocketChannel 的服务端（如自研网关、协议服务器）：
- 定义一个全局原子计数器：
private static final AtomicInteger activeConnections = new AtomicInteger(0); - 在
CompletionHandler的completed()方法开头，先执行int count = activeConnections.incrementAndGet(); - 立即判断：
if (count > MAX_CONNECTIONS) { channel.close(); activeConnections.decrementAndGet(); return; } - 若未超限，才继续设置读缓冲区、注册读事件、保存连接上下文等操作
- 在连接断开时（
failed()或业务层显式 close 后），务必调用activeConnections.decrementAndGet()
配合 SO_REUSEADDR 和连接超时避免假堆积
仅靠计数还不够，需防止因 TIME_WAIT 连接残留或客户端异常断连导致计数失真：
- 创建监听通道时启用地址复用：
serverChannel.setOption(StandardSocketOptions.SO_REUSEADDR, true); - 为每个新连接设置合理的空闲超时：
channel.setOption(StandardSocketOptions.SO_KEEPALIVE, true);并配合应用层心跳或读超时（如AsynchronousSocketChannel的 read 设置 timeout） - 避免使用
SO_LINGER强制关闭，否则可能延迟释放 fd，影响计数准确性
与系统级限制协同，防止被 ulimit 卡住
NIO 层的逻辑控制再严密，也绕不开操作系统对文件描述符的硬限制：
- 确保运行 Java 进程的用户已提升
nofile限制（如ulimit -n 65535），否则即使 Java 计数允许，socket()系统调用也会失败并抛出IOException: Too many open files - 可在启动时校验：
try (ServerSocket ignored = new ServerSocket(0)) { }判断是否能成功分配 fd - 监控实际连接数与
/proc/下文件描述符数量是否接近，可辅助定位泄漏/fd/
对比 Netty 等框架的内置限流
如果使用 Netty，可直接利用其 ConnectionLimitHandler 或自定义 ChannelInboundHandler 在 channelActive() 中做类似计数；Spring Boot + WebFlux 场景则更适合通过 WebServerFactoryCustomizer 调整底层 Reactor Netty 的连接参数，而非手动编码计数。NIO 原生方式的优势在于无额外依赖、可控粒度细（比如按 IP 分组限流）、内存占用极低。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
