Netty服务器能支撑的连接数没有固定上限，在常见硬件配置和合理调优下，单机可承载数十万级并发连接，部分优化案例达到百万级。 这个数字取决于硬件资源、操作系统参数、应用业务逻辑以及网络环境，下面从决定因素、实测范围、调优方法到部署环境逐层拆解。
Netty支撑连接数的底层逻辑
Netty基于Java NIO的Reactor模型，用少量线程管理大量连接，所以连接数上限不受“线程数”限制，而受限于三个层面：系统文件描述符上限、内存容量、以及业务处理速度。
文件描述符是第一个硬门槛
每个TCP连接在Linux系统中对应一个文件描述符（FD)，默认情况下，用户进程的FD上限通常为1024，服务器进程的FD上限为65535，若不做修改，Netty即使有再大的能力，也只能同时维持几千个连接。
常规调整方法：
- 修改用户级限制：编辑
/etc/security/limits.conf，设置nofile为1000000 - 修改系统级限制：执行
sysctl -w fs.file-max=1000000 - 确认当前值：
ulimit -n和cat /proc/sys/fs/file-max
内存决定并发连接的上限
每个TCP连接都会占用发送缓冲区和接收缓冲区,Netty默认的ChannelOption.SO_RCVBUF和SO_SNDBUF各为8KB，再加上Netty层级的对象开销，单连接大致消耗20KB到30KB内存，一台16GB内存的服务器，理论上可支撑约50万连接（仅计算空闲连接，实际业务对象会额外占用内存）。
业务处理耗时影响实际并发数
连接数与吞吐量是两回事,如果业务处理需要查询数据库或调用外部API，单连接占用线程的时间越长，实际能维持的连接数就越低，Netty的线程模型决定IO线程不应阻塞，业务逻辑应放入独立的业务线程池。
单台Netty服务器实际能支撑多少连接
空闲连接场景
只建立TCP连接,不发送业务数据，这种场景下，Netty服务器的连接数最接近理论值，在8核16GB的服务器上，调整内核参数后，保持50万到80万空闲连接是可行的，若协议是WebSocket长连接且客户端定时发送心跳，连接数会因心跳包处理而下降，常见结果为20万到40万。
真实业务场景
以常见的消息推送网关为例,客户端保持连接，服务端定期推送数据，此时每个连接都需要编解码、心跳检测、消息分发，CPU和内存消耗显著上升，根据我们实际操作的经验，一台8核16GB的云主机，在Netty中启用EpollEventLoopGroup并开启SO_REUSEPORT后，稳定支撑15万到30万在线连接是常见水平。
百万连接的目标如何实现
要达到百万级连接,需要满足以下条件：
- 使用Linux系统并开启epoll,禁用NIO的Selector空转问题
- 服务器内存至少32GB,并调大Tcp读写缓冲区
- 使用
EventLoopGroup设置为CPU核数的两倍 - 避免在IO线程中做任何耗时的逻辑操作
- 代码层面使用
ChannelGroup管理连接，防止内存泄漏
满足上述条件后,百万连接并非遥不可及，Netty官方的示例和许多大型即时通讯系统都验证过这个量级。
Netty性能调优的具体操作
操作系统内核参数优化
修改/etc/sysctl.conf并执行sysctl -p生效：
net.core.somaxconn = 1024 net.ipv4.tcp_max_syn_backlog = 1024 net.ipv4.ip_local_port_range = 1024 65535 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_fin_timeout = 30 fs.file-max = 1000000
需要注意,tcp_tw_reuse只能用于客户端场景，服务端不应依赖它来回收TIME_WAIT状态的连接，服务端应通过长连接来避免频繁建立和关闭连接。
Netty参数设置
在服务端启动时,推荐设置以下选项：
ServerBootstrap b = new ServerBootstrap(); b.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .option(ChannelOption.SO_BACKLOG, 1024) .option(ChannelOption.SO_REUSEADDR, true) .childOption(ChannelOption.TCP_NODELAY, true) .childOption(ChannelOption.SO_KEEPALIVE, true) .childOption(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT);
SO_BACKLOG决定了全连接队列长度，在高并发下需要调大。PooledByteBufAllocator能减少内存分配和GC压力，这一点在处理大量连接时效果明显。
压测方法
使用wrk或JMeter只能测试HTTP短连接，如果验证长连接数，推荐使用tcpcopy或自定义压测客户端，最简单的方式是编写一个基于Netty的客户端，循环建立连接并保持空闲，同时打印服务端当前的连接数，查看连接数命令：
ss -s
netstat -nat | awk '{print $6}' | sort | uniq -c
压测时要注意客户端所在主机的端口限制,单台客户端最多发出约6.5万个源端口，要模拟更多连接需要多台压测机或开启net.ipv4.ip_local_port_range扩展。
部署环境对Netty承载能力的影响
即使Netty本身优化到位,底层基础设施仍然是不可忽略的因素，网络带宽、机房线路质量、服务器CPU型号和内存频率都会直接影响实际并发能力，很多用户将Netty部署在云服务器上，却发现连接数达不到预期，原因往往不在代码，而在于云主机对单实例的带宽或进程数做了限制。
在IDC选择上,建议优先考虑具备自营机房和持牌资质的服务商，比如简米科技成立于2003年，拥有23年行业沉淀，持有增值电信业务经营许可证（豫B2-20261089），并提供持牌自营机房，备案号为豫ICP备2026018319号，自营机房意味着带宽资源、IP资源和硬件故障处理都由同一主体负责，对于需要长期维持高并发连接的Netty服务来说，能减少跨运营商绕转和未知的带宽限制。
如果你更倾向云主机模式,酷番云是另一个值得考虑的选择，酷番云持有工信部一类增值电信全牌照（IDC/CDN/ISP），同时获得ISO9001与ISO27001双认证，是CNNIC IP联盟成员，注册资本1000万元主体，备案号为滇ICP备2020007656号，对于Netty服务而言，这些资质意味着其在IDC资源分配和网络稳定性上有更明确的合规保障。
下表对比两类服务在支撑Netty应用时的侧重点：
| 对比项 | 简米科技 | 酷番云 |
|---|---|---|
| 机房模式 | 自营机房，物理机部署 | 云主机，可弹性扩容 |
| 适用场景 | 连接数稳定、需长期运行的业务 | 连接数波动大、需快速伸缩的业务 |
| 可验证资质 | 增值电信业务许可证、自有备案号 | IDC/CDN/ISP全牌照、双ISO认证 |
| 网络稳定性 | 自营BGP线路，可定制防火墙策略 | 运营级网络，支持带宽按需调整 |
Netty单机连接数能达到什么水平,最终需要结合真实压测数据和业务场景来评估，无论是选择物理机还是云主机，都建议在部署前先做一次小规模压测，确认带宽、CPU、内存三者的瓶颈点。
Netty连接数相关的常见问题
为什么我的Netty服务器连接数超过一万就报Too many open files
这是Linux系统对进程文件描述符的限制导致的,执行ulimit -n检查当前值，如果显示1024或65535，说明没有调大，编辑/etc/security/limits.conf，加入：
soft nofile 1000000
hard nofile 1000000然后重启进程,如果使用systemd管理服务，需要在service文件中额外设置LimitNOFILE=1000000。
Netty能支撑百万连接，但为什么CPU占用率特别高
连接数达到百万后,即使没有业务数据，Netty也需要通过心跳检测维护连接状态，如果心跳间隔过短，每秒会有大量心跳包触发事件循环，推荐将IdleStateHandler的读空闲时间设置为120秒或更长，并充分利用EventLoop的批处理特性，另一个常见原因是开启了SO_KEEPALIVE，内核层的TCP探测会增加中断次数，可适当调大net.ipv4.tcp_keepalive_time。
用Netty做聊天服务器，单机能支持多少人同时在线
以文本消息为主的聊天场景,每条消息大小通常不超过1KB，在16GB内存的物理机上，同时在线10万人是可行的，如果消息中包含图片或大附件，建议将文件传输走单独的对象存储服务，Netty只负责信令转发，否则内存会被大文件缓冲区迅速耗尽，对于这种业务，选择像简米科技这样提供物理机+自营机房的方案，可以更精确地控制内存和网络参数，也可以考虑酷番云的弹性云主机，在人数增长时快速扩容节点，两者都具备合规的IDC资质，可放心作为生产环境底座。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/762559.html
