1. 从网络通讯到Netty先搞清楚我们在解决什么问题做Java后端的人几乎都逃不开Netty。我最早接触它是在某次内部系统改造里要给一套老旧的HTTP轮询服务换成实时推送网上搜了一圈几乎所有方案都指向同一个答案用Netty自己写一套socket通讯。当时啃了好几篇源码分析发现真正的门槛不在API怎么调而在“连接通讯”这件事在Netty里到底是怎么串起来的。这篇笔记就是我当时学习过程的浓缩版——从零实现一个客户端和服务端之间的socket连接把建连、收发数据、断线重连这些最核心的环节彻底跑通。这篇文章适合两类人一类是刚看完Netty的Hello World对ServerBootstrap、NioEventLoopGroup这些类名很熟但不知道它们之间怎么配合的初学者另一类是写过一些Netty代码但遇到“客户端连不上服务端”“消息发出去了但对方收不到”这类问题只能靠猜的开发者。我会先用最简单的栗子把通讯骨架搭起来再逐步拆解每个核心组件的职责最后把我在实际调试中踩过的坑全部摆出来。需要提前说明的是本文基于Netty 4.1.x版本所有代码都是直接可运行的不需要额外引入复杂组件一个纯Java工程加一个Maven依赖就够。这意味着你可以边读边动手五分钟跑出一个能互发消息的控制台程序。2. 搭建工程与依赖从Maven坐标开始2.1 依赖引入的版本选择Netty的依赖坐标非常简单官方仓库直接就能拉到下面是Maven的写法dependency groupIdio.netty/groupId artifactIdnetty-all/artifactId version4.1.100.Final/version /dependency如果你对包体积比较敏感也可以不引netty-all而是分开引netty-transport、netty-codec、netty-handler这几个核心模块。但学习阶段我建议直接用netty-all省去因为缺模块导致的NoClassDefFoundError等之后做性能调优或者上线部署时再考虑精简依赖。Gradle用户对应加一行implementation io.netty:netty-all:4.1.100.Final版本这块我额外多说一句Netty 4.0.x已经进入维护末期5.0.x曾经长期停留在alpha阶段稳定性口碑远不如4.1.x所以绝大多数生产项目都在用4.1.x。尽量选择较新的4.1.x补丁版本老版本可能存在已公开的安全漏洞和内存泄漏问题。选版本时可以去Maven中央仓库看一下发布时间选最近一年内有过更新且版本号稳定的那个。2.2 工程结构的整体规划我用一个最普通的Maven工程不需要Spring不需要Web容器干干净净跑Java标准库。工程结构是这样规划的netty-socket-demo ├── pom.xml └── src/main/java └── com/example/netty ├── server │ ├── MyServer.java │ ├── ServerInitializer.java │ └── ServerHandler.java └── client ├── MyClient.java ├── ClientInitializer.java └── ClientHandler.java把服务端和客户端分成两个包Initializer负责把自定义的Handler编排进流水线Handler里放真正的业务处理逻辑。这种分层方式来自Netty官方的示例结构在真实项目里也最通用——即使后面接入Spring Boot、加上protobuf编解码骨架依然不用变。提示初次尝试时不要想着一步到位把所有代码都写完再启动。我见过很多人在学习阶段把服务端、客户端、多个Handler全部堆在一个类里出问题后根本没法定位。拆开写单独跑通服务端再用telnet或nc连接验证最后启动客户端联调这个顺序能帮你节省大量排查时间。2.3 第一个能跑起来的服务端骨架先把服务端最小可用版本写出来只做一件事绑定端口等待连接收到数据后原样打印。代码如下package com.example.netty.server; import io.netty.bootstrap.ServerBootstrap; import io.netty.channel.ChannelFuture; import io.netty.channel.ChannelInitializer; import io.netty.channel.ChannelOption; import io.netty.channel.EventLoopGroup; import io.netty.channel.nio.NioEventLoopGroup; import io.netty.channel.socket.SocketChannel; import io.netty.channel.socket.nio.NioServerSocketChannel; public class MyServer { private final int port; public MyServer(int port) { this.port port; } public void start() throws Exception { EventLoopGroup bossGroup new NioEventLoopGroup(1); EventLoopGroup workerGroup new NioEventLoopGroup(); try { ServerBootstrap bootstrap new ServerBootstrap(); bootstrap.group(bossGroup, workerGroup) .channel(NioServerSocketChannel.class) .option(ChannelOption.SO_BACKLOG, 128) .childOption(ChannelOption.SO_KEEPALIVE, true) .childHandler(new ChannelInitializerSocketChannel() { Override protected void initChannel(SocketChannel ch) { ch.pipeline().addLast(new ServerHandler()); } }); ChannelFuture future bootstrap.bind(port).sync(); System.out.println(Server started on port port); future.channel().closeFuture().sync(); } finally { workerGroup.shutdownGracefully(); bossGroup.shutdownGracefully(); } } public static void main(String[] args) throws Exception { new MyServer(8080).start(); } }这个骨架里的bossGroup和workerGroup是多线程模型的核心下面单独展开。3. 服务端实现连接生命周期的完整拆解3.1 为什么需要两个EventLoopGroup很多初学者看到bossGroup和workerGroup就开始懵。这里我用一个生活化的类比来解释bossGroup的角色相当于餐厅门口的迎宾员只负责接待客人、把客人带到座位workerGroup相当于服务员客人落座之后的点菜、上菜、结账都由服务员负责。具体到Netty里bossGroup负责处理OP_ACCEPT事件也就是接受客户端的连接请求它做的事情很轻量从操作系统层面拿到一个已建立的连接把它注册到workerGroup中的某个EventLoop上然后就完事了。workerGroup负责处理已经建立好的连接上的读写事件也就是OP_READ和OP_WRITE这部分才是真正的业务流量。写服务端时bossGroup的线程数建议设置为1。因为对单端口监听来说一个线程完全够用多设置几个反而增加了线程切换的开销。workerGroup的线程数默认是CPU核心数乘以2这个默认值在绝大多数场景下都合理不需要手动指定。写客户端时就要注意了客户端只需要一个EventLoopGroup不需要分两组——因为客户端不需要“接受连接”只需要发起连接和读写数据。用一个NioEventLoopGroup就够了。3.2 Channel类型的选择与NIO模型代码里我指定了.channel(NioServerSocketChannel.class)Netty还提供了OioServerSocketChannel和EpollServerSocketChannel等类型。其中OIO是阻塞IO模型性能差且在新版本里有被移除的趋势NIO是基于Java NIO的非阻塞模型跨平台性最好Epoll则是在Linux上使用epoll系统调用性能更好但只能运行在Linux系统上。日常开发和绝大多数生产环境直接选NIO就行。只有当你明确知道自己的部署环境固定在Linux并且想要让系统调用走epoll的更快路径时才考虑换成Epoll对应的线程工厂也要换成EpollEventLoopGroup。Netty有一个工具方法可以直接判断当前平台是否支持Epoll就是Epoll.isAvailable()感兴趣的话可以在项目里打印一下返回值看看。3.3 自定义Handler处理读写事件ServerHandler继承了ChannelInboundHandlerAdapter复写了channelRead方法用来处理从客户端发过来的数据。先写一个极简版本打印收到的消息内容package com.example.netty.server; import io.netty.channel.ChannelHandlerContext; import io.netty.channel.ChannelInboundHandlerAdapter; public class ServerHandler extends ChannelInboundHandlerAdapter { Override public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { System.out.println(Server received: msg); ctx.writeAndFlush(Server ack: msg); } Override public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) { cause.printStackTrace(); ctx.close(); } }这个版本有个问题msg到底是什么类型如果你没有在pipeline里加任何编解码器msg是ByteBuf直接打印的话会输出一堆二进制内容而不易阅读。要让msg直接变成字符串需要在initChannel里加一行ch.pipeline().addLast(new StringDecoder()); ch.pipeline().addLast(new StringEncoder());StringDecoder负责把字节流解码成StringStringEncoder负责把String编码成字节流写回客户端。两个配套使用处理文本协议特别方便。如果做的是二进制协议比如传递对象或自定义结构体那么StringDecoder就不适用了需要引入netty-codec包里的ProtobufDecoder或者自定义ByteToMessageDecoder。文本协议场景先用StringDecoder理解流程后面再做二进制协议时会容易很多。3.4 服务端启动的完整链路解析把ServerBootstrap比作一辆整装待发的汽车group()是发动机channel()是车身底盘childHandler()是载货系统bind()就是踩下油门。这个bind()操作其实经历了一个非常清晰的过程底层创建JDK的ServerSocketChannel向bossGroup注册OP_ACCEPT事件。操作系统层面执行bind端口和listen监听。bind()返回一个ChannelFuture调用sync()的目的是阻塞当前线程直到真正的端口绑定完成。端口绑定成功后main线程进入阻塞状态等待closeFuture()完成。我见过有人把sync()去掉结果程序启动后没报错但过一会儿就莫名退出根因就是sync()保证了启动动作的完成以及后续阻塞等待。去掉sync()主线程可能直接跑完main方法进程随之结束。这一点对于初学者尤其容易踩坑建议第一次练习时保留sync()调用。4. 客户端实现主动连接背后的五个关键动作4.1 Bootstrap与ServerBootstrap的差异服务端用ServerBootstrap客户端用Bootstrap两者的继承关系是同级的但使用方式有明显差异。客户端的Bootstrap只需要绑定一个EventLoopGroup不需要bossGroup因为客户端不负责接受连接。客户端的启动代码package com.example.netty.client; import io.netty.bootstrap.Bootstrap; import io.netty.channel.ChannelFuture; import io.netty.channel.ChannelInitializer; import io.netty.channel.EventLoopGroup; import io.netty.channel.nio.NioEventLoopGroup; import io.netty.channel.socket.SocketChannel; import io.netty.channel.socket.nio.NioSocketChannel; import io.netty.handler.codec.string.StringDecoder; import io.netty.handler.codec.string.StringEncoder; public class MyClient { private final String host; private final int port; public MyClient(String host, int port) { this.host host; this.port port; } public void connect() throws Exception { EventLoopGroup group new NioEventLoopGroup(); try { Bootstrap bootstrap new Bootstrap(); bootstrap.group(group) .channel(NioSocketChannel.class) .handler(new ChannelInitializerSocketChannel() { Override protected void initChannel(SocketChannel ch) { ch.pipeline().addLast(new StringDecoder()); ch.pipeline().addLast(new StringEncoder()); ch.pipeline().addLast(new ClientHandler()); } }); ChannelFuture future bootstrap.connect(host, port).sync(); future.channel().closeFuture().sync(); } finally { group.shutdownGracefully(); } } public static void main(String[] args) throws Exception { new MyClient(127.0.0.1, 8080).connect(); } }4.2 connect操作的事件传播路径客户端的connect()调用内部分几个步骤理解这些步骤对于排查“连接不上”的问题很有帮助初始化一个NioSocketChannel这个通道对应操作系统层面新建的socket。向EventLoop注册通道指定关注OP_CONNECT事件。发起TCP三次握手。非阻塞模式下connect()会立刻返回真正的连接结果通过OP_CONNECT事件通知。OP_CONNECT触发后Netty在内部完成finishConnect()操作并发布ChannelActive事件。ChannelFuture的回调或者sync()的阻塞返回标记连接成功。这里要解释一个易误解的点bootstrap.connect(host, port).sync()阻塞的并不是网络连接过程本身而是等待连接结果的事件循环通知。Netty把异步结果封装成Futuresync()只是让当前线程等待这个Future完成。在实际异步编程场景中你完全可以不调用sync()而是用addListener注册回调等连接成功后再触发后续业务动作。4.3 客户端Handler的三个典型周期ClientHandler中我建议至少要关注三个方法它们的触发时机与服务端不同package com.example.netty.client; import io.netty.channel.ChannelHandlerContext; import io.netty.channel.ChannelInboundHandlerAdapter; public class ClientHandler extends ChannelInboundHandlerAdapter { Override public void channelActive(ChannelHandlerContext ctx) throws Exception { System.out.println(Connected to server); ctx.writeAndFlush(Hello from client); } Override public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { System.out.println(Client received: msg); } Override public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) { cause.printStackTrace(); ctx.close(); } }channelActive对客户端来说意味着TCP连接已经建立成功。在真实业务里一个很常见的做法是在channelActive里做首次登录或身份认证把鉴权信息发给服务端。channelRead收到服务端响应的数据处理完业务后可以选择关闭连接也可以选择继续复用这条连接。这里先不做关闭方便循环测试交互效果。channelInactive也是我特别关注的钩子它触发时说明连接已经断开通常在这里做重连逻辑。4.4 客户端与服务端联调测试把服务端和客户端分别启动执行顺序是先服务端后客户端。在客户端控制台会看到“Connected to server”服务端控制台会看到“Server received: Hello from client”随后客户端收到“Server ack: Hello from client”整个链路就是通的。如果你手边没有客户端代码只想快速验证服务端是否正常可以直接用系统自带的telnet连接telnet 127.0.0.1 8080连接成功后输入任意字符串服务端会把这些内容打印出来。这可以说是调试服务端最轻量的方式比启动一个完整客户端快得多。5. 连接请求如何被处理核心链路与运行原理5.1 ChannelPipeline上的Handler旅行过程Netty的连接处理机制核心就在ChannelPipeline上。可以把它想像成一条工厂流水线一个数据进来后按顺序经过每个工位Handler每个工位决定自己是加工处理、修改转换还是扣下拦截。服务端的pipeline在ServerInitializer里定义这个initChannel方法会在每次新连接建立时被调用。有一点我需要重点提醒ServerHandler不加上Sharable注解的话每个新连接都会new一个独立的Handler实例。也就是说每个连接有一份自己的pipeline。如果你把多个连接共享的状态放进Handler的成员变量要注意线程安全问题因为同一个Handler实例可能被多个EventLoop并发调用。对于客户端来说Bootstrap的handler()方法配置的是客户端Channel的pipeline在连接建立前就会初始化好。5.2 EventLoop线程模型与I/O事件的分发规则Netty的线程模型可以简单概括为一句话一个EventLoop对应一个线程一个连接在生命周期内始终由同一个EventLoop来处理。这意味着你用ctx.writeAndFlush()发送数据和从channelRead里收到数据发生线程都在同一个EventLoop上。这样设计的好处是Netty的应用层处理逻辑天然避开了锁竞争——你不用考虑多线程同时写同一个Channel的问题因为同一个Channel上的所有操作都被串行化到同一个线程上执行了。但代价也随之而来一旦某一个Handler里执行了耗时操作比如同步查数据库、调用外部API这个EventLoop就会被卡住导致所有分配在这个EventLoop上的连接都出现延迟甚至超时。这是Netty编程最常见的性能陷阱没有之一。实际项目中耗时的业务逻辑必须丢到独立的业务线程池执行不要让Netty的I/O线程被业务阻塞。这是新手使用Netty最应该铭记的一条铁律。5.3 编解码器与粘包拆包的初体验我在服务端和客户端的pipeline里都加了StringDecoder和StringEncoder这样消息就能以字符串形式直接收发。不过这里隐藏着一个重要问题——TCP是面向字节流的协议它本身不划分消息边界。连续发送多条消息时接收方可能一次读到多个消息粘在一起也可能一条消息被拆成两半这就是常说的粘包与拆包。加StringDecoder只是把字节流按照平台默认字符集解码成字符串它并不负责按消息边界切割。初学者用StringDecoder做实验时如果发送频率不高、数据量不大通常一次读到的就是一条完整消息不容易暴露问题。但在高并发或大流量场景下粘包拆包几乎必然出现。解决粘包拆包问题最经典的方式是增加LineBasedFrameDecoder或DelimiterBasedFrameDecoder按换行符或自定义分隔符来划分消息边界。启动类里调整为这样ch.pipeline().addLast(new LineBasedFrameDecoder(1024)); ch.pipeline().addLast(new StringDecoder()); ch.pipeline().addLast(new StringEncoder());这里的LineBasedFrameDecoder(1024)表示每条消息最大1024字节超过这个大小会抛出异常。这样客户端发送消息时末尾带上\n服务端就能按行正确切分。5.4 ChannelFuture与异步通知机制Netty里大量使用ChannelFuture来传递异步结果。它和Java 8的CompletableFuture不同Netty的Future没有提供类似thenApply那种链式调用但提供了addListener方式注册回调future.addListener((ChannelFutureListener) f - { if (f.isSuccess()) { System.out.println(连接成功); } else { System.out.println(连接失败); f.cause().printStackTrace(); } });用回调而不是sync()的好处是你完全可以在EventLoop线程里以非阻塞方式处理后续动作避免同步等待造成的线程浪费。学习Netty的初期先熟练使用sync()确保理解执行顺序再逐渐过渡到Listener和Future模式这个过程不用着急。6. 踩坑实录与性能优化建议6.1 客户端连不上服务端的排查清单这个问题的原因多种多样我整理了一份按出现频率排序的排查清单实际工作中按这个顺序检查往往立竿见影检查点检查方法常见原因服务端是否启动成功看控制台有没打印启动日志或用netstat -an检查端口监听状态bind()失败或端口被占用端口是否一致核对客户端连接端口和服务端监听端口配置不一致防火墙规则本机telnet 127.0.0.1能通远程连不通优先查防火墙端口未放行客户端connect异常处理不要只打日志要打印cause()堆栈DNS解析失败、连接超时端口被占用是很常见的一个问题。如果服务端启动时没有打印异常但进程退了基本就是bind失败或者被防火墙拦截。开发调试时如果频繁重启服务端还可能遇到Address already in use的报错这时可以用下面的命令找到占用端口的进程lsof -i:8080找到进程PID后确认是否是残留的服务进程如果是直接杀掉重启如果不是就需要关注别的服务占用了这个端口。6.2 消息发送成功但对方收不到的三大元凶看起来最简单的问题往往背后隐藏着好几类原因。我把自己排查这类问题时用到的思路整理一下第一个原因是Handler顺序不对。pipeline中Handler的顺序决定了数据流的处理顺序服务端入站时数据按照添加顺序从前向后经过各个入站Handler出站时则从后向前经过各个出站Handler。如果收数据时打印日志的Handler加在编解码器前面那么它拿到的还是ByteBuf而不是String你打印出来自然是一堆看不懂的二进制。这个不看源码还真容易忽略。第二个原因是消息发出后没有flush。ctx.write(msg)只是把消息放进了发送缓冲区真正写到底层socket的是flush或者writeAndFlush。如果一个项目中某处用了write而忘记flush在低流量测试中几乎发现不了上线后突然丢消息才体现出问题。我的习惯是统一使用writeAndFlush除非有明确的批量刷出需求那时候才拆开操作。第三个是数据格式不匹配。服务端用StringDecoder解码客户端用自定义二进制的Encoder发送两边编解码不匹配服务端解析出来是乱码或者根本无法解析。出现这种问题先在pipeline设计上统一编解码标准再检查两端启动类的Handler配置是不是一致。6.3 进程退出的线程管控问题服务端和客户端代码里finally块中调用了shutdownGracefully()。这个方法是不断推荐的优雅退出方式它会在所有任务执行完毕、连接关闭后释放线程资源。如果你写完一个简单的客户端没有阻塞等待而是直接执行完main方法退出你会发现程序跑完就立刻进程结束这其实是正确的。想保持进程存活等待用户输入可以在connect()之后增加阻塞逻辑比如等待closeFuture().sync()或者用一个CountDownLatch来保持主线程不退出。直接杀掉进程则不推荐很容易导致内存泄漏或外部资源没有释放。6.4 消费端业务的线程池隔离在Handler里同步调用耗时方法的问题我说了很多次。这里给一个最直接的补救方案引入一个固定的业务线程池来执行耗时动作。ExecutorService bizExecutor Executors.newFixedThreadPool(8); Override public void channelRead(ChannelHandlerContext ctx, Object msg) { bizExecutor.execute(() - { // 模拟耗时业务处理 String result doBizWork(msg); ctx.writeAndFlush(result); }); }注意一点ctx.writeAndFlush()在别的线程调用是线程安全的Netty内部已经处理了线程切换所以从业务线程池里直接写回数据没有问题。但这样做会引出另一个话题如果同时有大量连接产生消息业务线程池可能会成为新的瓶颈而这实际上正好说明了为什么很多大型项目要引入消息队列来削峰填谷让Netty只负责接入和数据收发真正的处理逻辑放到下游系统。6.5 日志观测技巧让调试变得轻松前面提到的代码里我大量使用了System.out.println。这适合学习阶段但在项目里请务必使用日志框架。Netty自身的日志可以通过-Dio.netty.leakDetectionLeveladvanced来开启更严格的内存泄漏检测。内存泄漏这个点非常隐蔽尤其是用ByteBuf的时候忘记release()就会造成堆外内存泄漏表现为GC正常但内存持续增长最终被系统杀掉。简单总结我的日志观察三步法第一步在服务端启动类里打印bind()的结果确认端口监听成功第二步在channelActive和channelInactive里打印连接建立和断开事件确认连接生命周期正常第三步在channelRead里打印收到的原始消息确认数据链路正常。三步都通剩下的大概率就是业务逻辑或编解码问题。7. 从Demo到实战写给正在学习Netty的你7.1 这版Demo可以扩展出的几个方向前面实现的Demo是Netty客户端和服务端通讯的核心骨架。在这个基础上你可以按这样的顺序逐步扩展成接近生产可用的系统第一个方向是支持多客户端在线管理。服务端需要维护一个ChannelGroup连接建立时把Channel加入集合连接断开时移除。这样服务端可以主动向所有在线客户端推送消息这就是简易群聊和实时通知系统的基础。第二个方向是自定义协议替代字符串。实际项目中几乎不会直接传裸字符串常见做法是设计一个消息头包含魔数、版本、消息长度再加上消息体。Netty提供了ByteToMessageDecoder来支持自定义解码器这是摆脱StringDecoder后的必然一步。第三个方向是心跳机制与断线重连。服务端用IdleStateHandler检测读空闲事件对长时间没有消息的连接发起心跳探测或直接关闭客户端在channelInactive里触发重连并用指数退避算法控制重连频率。这个机制在长连接业务中必不可少。第四个方向是整合到Spring Boot里。把Netty服务端做成一个独立模块由Spring的ApplicationRunner启动通过ApplicationContext共享业务Bean是一种比较常见的落地姿势。7.2 固定学习路径从这份Demo到Netty高手很多初学者问我Netty怎么学才不会半途而废。我的答案很直接把这条链路反复做三遍。第一遍照抄本文代码跑通连接和数据收发不用追问每个细节第二遍不带任何参考自己从头写一遍遇到卡壳的地方再回头查资料第三遍把StringDecoder替换成自定义的编解码器加上心跳和重连做成一个能在测试环境稳定运行一整天的程序。三遍做完Netty的核心模型基本就掌握了。之后再去啃源码重点看NioEventLoop的任务循环机制和ChannelPipeline的事件传播机制这些点能理解透的话Netty的绝大多数问题你都能自己解决。7.3 最后聊一点我自己的体会我学习Netty过程中最大的感受是Netty的API设计和原生Java NIO相比已经把复杂度降低了不止一个量级但它的门槛依然很高因为你能写出一个可运行的Demo不意味着你理解了事件循环。真正让我把这个框架用明白的是开始用Netty处理真实项目中的连接管理问题之后——大量连接的接入并发、反压机制的处理、系统异常夯住时的现场排查这些书本上写不细的东西只能在实战里一次次长教训。回到最开始的问题客户端和服务端的连接通讯看起来只是两个类、几个方法的事但Netty把这套机制设计得如此完整和健壮说明这背后值得花时间研究的内容远比想象中要多。这份Demo只是个起点里面涉及的事件循环、pipeline、编解码、线程模型每一个单独拿出来都够写几篇长文。如果你顺着这条链路一路研究下去等到你能不看文档、只靠思路写出任意一种自定义协议和通讯模型时就会明白Netty为什么会是Java后端最重要的网络基石之一。