客户端端口耗尽需启用SO_REUSEADDR/SO_REUSEPORT、扩端口范围、启用tcp_tw_reuse；服务端需调高ulimit、配置limits.conf与systemd LimitNOFILE；EventLoopGroup线程数应按场景适配CPU核心数，禁用SO_LINGER，并通过ss -s定位真实瓶颈。
客户端端口不够用：bind() 失败或 Address already in use
单台客户端机器默认能建立的 TCP 连接数受限于可用本地端口范围（通常是 32768–65535，共约 3.2 万个），再加上 TIME_WAIT 状态连接占着端口不释放，很容易在压测时遇到 Cannot assign requested address 或反复 bind() 失败。
解决思路不是堆机器，而是让客户端复用本地地址+端口，绕过端口耗尽瓶颈：
- Java 客户端（如 Netty
Bootstrap）调用option(ChannelOption.SO_REUSEADDR, true)和option(ChannelOption.SO_REUSEPORT, true)（Linux 3.9+） - 操作系统层面确保
/proc/sys/net/ipv4/ip_local_port_range范围足够宽（例如设为1024 65535） - 降低
TIME_WAIT占用：设置/proc/sys/net/ipv4/tcp_fin_timeout（不建议低于 30），更安全的做法是启用tcp_tw_reuse = 1（仅对客户端有效）
服务端扛不住：java.io.IOException: Too many open files
Netty 服务端每个连接至少占用 1 个文件描述符（fd），加上日志、配置文件、JVM 自身开销，实际能支撑的并发连接数直接受限于系统级 ulimit -n 值。默认通常只有 1024，连 1 万连接都撑不住。
必须同时调整三处，缺一不可：
- 当前 Shell 会话：运行
ulimit -n 1048576（注意：仅对当前终端及子进程生效） - 系统级持久配置：编辑
/etc/security/limits.conf，添加两行：* soft nofile 1048576* hard nofile 1048576 - systemd 服务（如用
systemctl启动 Java 进程）：需在 service 文件中显式设置LimitNOFILE=1048576，否则 limits.conf 不生效
Netty 自身配置没跟上：EventLoopGroup 线程数与连接数失配
很多人以为只要调大 ulimit 就万事大吉，结果 CPU 打满、连接建立变慢、甚至部分连接超时——问题常出在 EventLoopGroup 的线程数没适配硬件和负载模型。
关键点在于区分两类连接场景：
- 高吞吐低延迟（如 RPC）：建议
NioEventLoopGroup线程数 ≈ CPU 核心数 × 2，避免过多线程上下文切换 - 高连接低活跃（如 IM 长连接）：可适当增加线程数（如 ×3～×4），但超过 64 后收益急剧下降，此时应优先检查 GC 和内存分配
- 务必禁用
SO_LINGER（即不设ChannelOption.SO_LINGER或设为-1），否则关闭连接时会阻塞 EventLoop
验证是否真到极限：别只看连接数，要看 ESTABLISHED + TIME_WAIT 分布
用 ss -s 或 netstat -s | grep -i "connection" 看统计比单纯数 ss -tn state established | wc -l 更靠谱。真实瓶颈往往藏在细节里：
- 如果
ss -s显示memory行接近上限，说明内核 socket buffer 耗尽，需调大net.core.wmem_max/rmem_max - 若大量连接卡在
SYN_RECV，可能是服务端 backlog 队列溢出，需增大ServerBootstrap.option(ChannelOption.SO_BACKLOG, 1024)并同步调高系统net.core.somaxconn - JVM 层面记得加
-XX:+UseG1GC -XX:MaxGCPauseMillis=50，否则 GC STW 会导致 accept 队列堆积，现象就是新连接迟迟建不上
真正卡住的点，从来不在你预设的路径上。比如改完 ulimit 发现还是连不上，先 cat /proc/<pid>/limits</pid> 确认进程实际生效值，再查 dmesg | tail 看有没有内核 OOM killer 杀进程的痕迹。
