文章目录
1、概述
1.1、什么是Netty
Netty 是由 JBOSS 提供的一个 Java 开源框架，现为 Github 上的独立项目，是一个异步的、基于事件驱动的网络应用框架，用以快速开发高性能、高可靠性的网络 IO 程序
Netty本质是一个 NIO 框架，适用于服务器通讯相关的多种应用场景Netty 主要针对在 TCP 协议下，面向 Clients 端的高并发应用，或者 Peer-to-Peer 场景下的大量数据持续传输的应用
层次关系为：TCP/IP->Java原生IO/网络->NIO->Netty
1.2、Netty的地位
Netty 在 Java 网络应用框架中的地位就好比：Spring 框架在 JavaEE 开发中的地位
以下的框架都使用了 Netty，因为它们有网络通信需求！
- Cassandra - nosql 数据库
- Spark - 大数据分布式计算框架
- Hadoop - 大数据分布式存储框架
- RocketMQ - ali 开源的消息队列
- ElasticSearch - 搜索引擎
- gRPC - rpc 框架
- Dubbo - rpc 框架
- Spring 5.x - flux api 完全抛弃了 tomcat ，使用 netty 作为服务器端
- Zookeeper - 分布式协调框架
1.3、Netty的优势
- 相比于NIO，后者开发工作量大，bug 多，如下
- 需要自己构建协议
- 解决 TCP 传输问题，如粘包、半包
- epoll 空轮询导致 CPU 100%
- 对 API 进行增强，使之更易用，如 FastThreadLocal => ThreadLocal，ByteBuf => ByteBuffer
- 相比于其它网络应用框架
- Mina 由 apache 维护，将来 3.x 版本可能会有较大重构，破坏 API 向下兼容性，Netty 的开发迭代更迅速，API 更简洁、文档更优秀
- 久经16年考验，Netty 版本发布时间：
- 2.x 2004
- 3.x 2008
- 4.x 2013
- 5.x 已废弃（没有明显的性能提升，维护成本高）
2、Netty的Hello World
2.1、导入依赖
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-all</artifactId>
<version>4.1.70.Final</version>
</dependency>
2.2、编写服务器端代码
/**
* @author PengHuanZhi
* @date 2021年11月25日 18:52
*/
public class HelloServer {
public static void main(String[] args) {
// 1. 启动器，负责组装 netty 组件，启动服务器
new ServerBootstrap()
// 2. BossEventLoop, WorkerEventLoop(selector,thread), group 组
.group(new NioEventLoopGroup())
// 3. 选择 服务器的 ServerSocketChannel 实现
.channel(NioServerSocketChannel.class)
// 4. boss 负责处理连接 worker(child) 负责处理读写，决定了 worker(child) 能执行哪些操作（handler）
.childHandler(
// 5. channel 代表和客户端进行数据读写的通道 Initializer 初始化，负责添加别的 handler
new ChannelInitializer<NioSocketChannel>() {
@Override
protected void initChannel(NioSocketChannel nioSocketChannel) throws Exception {
// 6. 添加具体 handler
nioSocketChannel.pipeline().addLast(new LoggingHandler());
// 将 ByteBuf 转换为字符串
nioSocketChannel.pipeline().addLast(new StringDecoder());
// 自定义 handler
nioSocketChannel.pipeline().addLast(new SimpleChannelInboundHandler<String>() {
// 读事件
@Override
protected void channelRead0(ChannelHandlerContext channelHandlerContext, String msg) throws Exception {
// 打印上一步转换好的字符串
System.out.println(msg);
}
});
}
})
// 7. 绑定监听端口
.bind(8080);
}
}
2.3、编写客户端代码
/**
* @author PengHuanZhi
* @date 2021年11月25日 19:14
*/
public class HelloClient {
public static void main(String[] args) throws InterruptedException {
// 1. 启动类
new Bootstrap()
// 2. 添加 EventLoop
.group(new NioEventLoopGroup())
// 3. 选择客户端 channel 实现
.channel(NioSocketChannel.class)
// 4. 添加处理器
.handler(new ChannelInitializer<NioSocketChannel>() {
@Override // 在连接建立后被调用
protected void initChannel(NioSocketChannel ch) throws Exception {
ch.pipeline().addLast(new StringEncoder());
}
})
// 5. 连接到服务器
.connect(new InetSocketAddress("localhost", 8080))
.sync()
.channel()
// 6. 向服务器发送数据
.writeAndFlush("hello, world");
}
}
2.4、流程分析
- 服务端调用**new Bootstrap()**启动
- 向其中添加NioEventLoopGroup，事件循环组，里面可以有多个事件循环对象，默认为当前系统的核心数*2，一个事件循环对象可以简单理解为一个线程池**+Selector**
- 选择服务端的ServerSocketChannel的实现
- 添加ChannelInitializer，它可以为所有的SocketChannel（不是ServerSocketChannel）添加处理器，且只执行一次，每个客户端连接后，与其分配的SocketChannel都会执行initChannel方法，注意此时还没有开始执行，只是添加了这个初始化对象
- 然后绑定端口号8080
这时服务端的流程就暂时走完了，随时等待客户端调用
- 客户端也创建一个启动器
- 添加自己的NioEventLoopGroup（非必要）
- 选择客户端的Channel实现
- 同样需要添加一个初始化对象，用于和服务端建立了连接后添加处理器，内部initChannel代码同样还没有执行
- 开始连接服务器
- sync为阻塞方法，会一直阻塞到连接的建立
客户端在这里就阻塞住了，回到服务端
- 定义在服务端中的NioEventLoopGroup便收到一个accept事件，开始建立连接
- 所有客户端的连接事件都会交由ChannelInitializer来调用initChannel来处理，初始化好Channel（添加了StringDecoder解码处理器和自定义处理器）
服务端这时候流程又暂时走完了，再次回到客户端
- 连接建立后也会立即执行仅一次的initChannel方法，为我们网络数据传输添加一个StringEncoder，用于将字符串转换为一个ByteBuf
- 连接初始化完成后会返回一个Channel（实则自己选择的NioSocketChannel）
- 调用Channel开始向服务器发送数据
- 调用StringEncoder事件处理将字符串转换为一个ByteBuf
客户端的流程就走完了
- 回到服务端，服务端的NioEventLoopGroup中的Selector会处理这一个read事件，然后接收到ByteBuf对象，会使用StringDecoder处理器来讲ByteBuf解码为一个字符串
- 接着再执行自定义的处理器，因为重写了channelRead方法，所以当这个Read事件到达后会交给它去执行
- 打印信息
其中group方法有两个重载的方法需要提一下
- 一个是传入一个EventLoopGroup的单参来创建，则处理Accept事件的Boss和IO事件的Worker都会使用这个EventLoopGroup。
- 另一个是传入两个EventLoopGroup的双参创建，第一个Group用于处理Boss的Accept事件，第二个Group则用于处理Worker的IO事件。
2.5、概念理解
- 把 channel 理解为数据的通道
- 把 msg 理解为流动的数据，最开始输入是 ByteBuf，但经过 pipeline 的加工，会变成其它类型对象，最后输出又变成 ByteBuf
- 把 handler 理解为数据的处理工序
- 工序有多道，合在一起就是 pipeline，pipeline 负责发布事件（读、读取完成…）传播给每个 handler， handler 对自己感兴趣的事件进行处理（重写了相应事件处理方法）
- handler 分 Inbound 和 Outbound 两类，分别表示入站和出站
- 把 eventLoop 理解为处理数据的工人
- 工人可以管理多个 channel 的 io 操作，并且一旦工人负责了某个 channel，就要负责到底（绑定），下面马上会讲
- 工人既可以执行 io 操作，也可以进行任务处理，每位工人有任务队列，队列里可以堆放多个 channel 的待处理任务，任务分为普通任务、定时任务
- 工人按照 pipeline 顺序，依次按照 handler 的规划（代码）处理数据，可以为每道工序指定不同的工人
- childHandler，为什么是child呢？因为对于所有的accept事件都由Boss线程处理了，而所有的非accept事件，如read，write事件，则都需要交给非Boss线程的‘Child’去处理，所以这里叫ChildHandler
- 为什么要调用Sync来将当前线程阻塞住呢？因为Connect方法实际上是一个异步非阻塞的方法，当前Main线程调用Connect方法后，具体Connect并不是Main线程去做的，而是NioEventLoopGroup中的一个NIO线程，如果不使用Sync阻塞住，那么Main线程将直接执行完毕，此时连接并还没有建立，当连接调用完毕后，Sync才会释放继续向下执行。
3、各组件详解
3.1、EventLoop
事件循环对象，本质是一个单线程执行器，同时维护一个Selector，里面有run方法处理Channel上面的IO事件
- 它继承了两个接口，一个是EventLoopGroup，另一个是OrderedEventExecutor，这两个父接口也都继承自JUC下面的ScheduledExecutorService ，所以它也包含了线程池中所有的方法
3.2、EventLoopGroup
顾名思义，它是一组EventLoop，Channel一般会调用EventLoopGroup的register方法来绑定其中的一个EventLoop，后续所有的这个Channel上的IO事件都将交由这个EventLoop来处理（目的是为了IO事件处理的线程安全）
- 实现自Netty自己的EventExecutorGroup，因为EventExecutorGroup还实现了Iterable接口，所以一个EventLoopGroup也提供了遍历EventLoop的能力
简单实现一下
EventLoopGroup group = new NioEventLoopGroup(2); // io 事件，普通任务，定时任务
//EventLoopGroup group = new DefaultEventLoopGroup(); // 普通任务，定时任务
// 2. 获取下一个事件循环对象
for (int i = 0; i < 5; i++) {
System.out.println(group.next());
}
上面提到如果不指定EventLoop的数量默认是电脑核心的两倍吗，所以在创建EventLoopGroup的时候调用无参构造方法，循环打印12*2+1 = 25次再次测试（本机核心12个）
3.2.1、绑定
服务端创建两个NioEventGroup()，相当于两个工人
/**
* @author PengHuanZhi
* @date 2021年11月26日 9:48
*/
@Slf4j
public class EventLoopGroupServer {
public static void main(String[] args) {
new ServerBootstrap()
//第一个参数是Boss组，第二个参数是Worker组
.group(new NioEventLoopGroup(1), new NioEventLoopGroup(2))
//指定服务器端的ServerChannel实现
.channel(NioServerSocketChannel.class)
//指定普通
.childHandler(new ChannelInitializer<NioSocketChannel>() {
@Override
protected void initChannel(NioSocketChannel ch) throws Exception {
ch.pipeline().addLast(new StringDecoder());
ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
log.debug(msg.toString());
}
});
}
})
//绑定端口
.bind(8080);
}
}
客户端启动三次
/**
* @author PengHuanZhi
* @date 2021年11月26日 9:59
*/
public class EventLoopGroupClient {
//没有实际意义，仅仅是为了区分不同客户端发送的消息（有概率会重复）
private static final char CLIENT_NAME = UUID.randomUUID().toString().charAt(0);
public static void main(String[] args) throws Exception {
Channel channel = new Bootstrap()
.group(new NioEventLoopGroup(1))
.channel(NioSocketChannel.class)
.handler(new ChannelInitializer<NioSocketChannel>() {
@Override
protected void initChannel(NioSocketChannel ch) throws Exception {
ch.pipeline().addLast(new StringEncoder());
}
})
.connect("localhost", 8080)
.sync()
.channel();
for (int i = 0; i < 4; i++) {
channel.writeAndFlush(CLIENT_NAME + "客户端发送的第" + (i + 1) + "条消息");
Thread.sleep(3000);
}
}
}
观察日志
[nioEventLoopGroup-3-2] DEBUG - 9客户端发送的第1条消息
[nioEventLoopGroup-3-1] DEBUG - 7客户端发送的第1条消息
[nioEventLoopGroup-3-2] DEBUG - 9客户端发送的第2条消息
[nioEventLoopGroup-3-2] DEBUG - c客户端发送的第1条消息
[nioEventLoopGroup-3-1] DEBUG - 7客户端发送的第2条消息
[nioEventLoopGroup-3-2] DEBUG - 9客户端发送的第3条消息
[nioEventLoopGroup-3-2] DEBUG - c客户端发送的第2条消息
[nioEventLoopGroup-3-1] DEBUG - 7客户端发送的第3条消息
[nioEventLoopGroup-3-2] DEBUG - 9客户端发送的第4条消息
[nioEventLoopGroup-3-2] DEBUG - c客户端发送的第3条消息
[nioEventLoopGroup-3-1] DEBUG - 7客户端发送的第4条消息
[nioEventLoopGroup-3-2] DEBUG - c客户端发送的第4条消息
- 9号客户端首先被工人3-2接收处理
- 7号到达，分配给3-1处理
- 9号再次到达，因为已经绑定了3-2，所以还是它处理
- c号到达，没有绑定过，所以轮到3-2处理，至此三个客户端的Channel都绑定了对应的工人
再增加四个非NIO的工人（区别于开启三个客户端），修改服务端代码，新增一个LoggingHandler 处理器，这个处理器会交由NIO的工人处理，然后指定让Read事件交由我们创建的非NIO工人处理，客户端代码保持不变（仍然开启三次）
package com.phz.eventloopgroup;
import io.netty.bootstrap.ServerBootstrap;
import io.netty.channel.*;
import io.netty.channel.nio.NioEventLoopGroup;
import io.netty.channel.socket.nio.NioServerSocketChannel;
import io.netty.channel.socket.nio.NioSocketChannel;
import io.netty.handler.codec.string.StringDecoder;
import io.netty.handler.logging.LoggingHandler;
import lombok.extern.slf4j.Slf4j;
/**
* @author PengHuanZhi
* @date 2021年11月26日 9:48
*/
@Slf4j
public class EventLoopGroupServer {
public static void main(String[] args) {
DefaultEventLoopGroup normalWorker = new DefaultEventLoopGroup(3);
new ServerBootstrap()
//创建Worker组
.group(new NioEventLoopGroup(1), new NioEventLoopGroup(2))
//指定服务器端的ServerChannel实现
.channel(NioServerSocketChannel.class)
//指定普通
.childHandler(new ChannelInitializer<NioSocketChannel>() {
@Override
protected void initChannel(NioSocketChannel ch) throws Exception {
ch.pipeline().addLast(new StringDecoder());
ch.pipeline().addLast(new LoggingHandler());
ch.pipeline().addLast(normalWorker, "normalWorker", new ChannelInboundHandlerAdapter() {
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
log.debug("normal:" + msg.toString());
}
});
}
})
//绑定端口
.bind(8080);
}
}
再次观察日志信息（略有修改，便于观察）
[nioEventLoopGroup-4-1] - [id: 0x89965813, L:/127.0.0.1:8080 - R:/127.0.0.1:57398] READ: d客户端发送的第1条消息
[defaultEventLoopGroup-2-1] DEBUG com.phz.eventloopgroup.EventLoopGroupServer - normal:d客户端发送的第1条消息
[nioEventLoopGroup-4-1] - [id: 0x89965813, L:/127.0.0.1:8080 - R:/127.0.0.1:57398] READ: d客户端发送的第2条消息
[defaultEventLoopGroup-2-1] DEBUG com.phz.eventloopgroup.EventLoopGroupServer - normal:d客户端发送的第2条消息
[nioEventLoopGroup-4-2] - [id: 0x5e849282, L:/127.0.0.1:8080 - R:/127.0.0.1:57422] READ: 0客户端发送的第1条消息
[defaultEventLoopGroup-2-2] DEBUG com.phz.eventloopgroup.EventLoopGroupServer - normal:0客户端发送的第1条消息
[nioEventLoopGroup-4-1] - [id: 0x89965813, L:/127.0.0.1:8080 - R:/127.0.0.1:57398] READ: d客户端发送的第3条消息
[defaultEventLoopGroup-2-1] DEBUG com.phz.eventloopgroup.EventLoopGroupServer - normal:d客户端发送的第3条消息
[nioEventLoopGroup-4-2] - [id: 0x5e849282, L:/127.0.0.1:8080 - R:/127.0.0.1:57422] READ: 0客户端发送的第2条消息
[defaultEventLoopGroup-2-2] DEBUG com.phz.eventloopgroup.EventLoopGroupServer - normal:0客户端发送的第2条消息
[nioEventLoopGroup-4-1] - [id: 0xc82e3224, L:/127.0.0.1:8080 - R:/127.0.0.1:57443] READ: 5客户端发送的第1条消息
[defaultEventLoopGroup-2-3] DEBUG com.phz.eventloopgroup.EventLoopGroupServer - normal:5客户端发送的第1条消息
[nioEventLoopGroup-4-1] - [id: 0x89965813, L:/127.0.0.1:8080 - R:/127.0.0.1:57398] READ: d客户端发送的第4条消息
[defaultEventLoopGroup-2-1] DEBUG com.phz.eventloopgroup.EventLoopGroupServer - normal:d客户端发送的第4条消息
[nioEventLoopGroup-4-2] - [id: 0x5e849282, L:/127.0.0.1:8080 - R:/127.0.0.1:57422] READ: 0客户端发送的第3条消息
[defaultEventLoopGroup-2-2] DEBUG com.phz.eventloopgroup.EventLoopGroupServer - normal:0客户端发送的第3条消息
[nioEventLoopGroup-4-1] - [id: 0xc82e3224, L:/127.0.0.1:8080 - R:/127.0.0.1:57443] READ: 5客户端发送的第2条消息
[defaultEventLoopGroup-2-3] DEBUG com.phz.eventloopgroup.EventLoopGroupServer - normal:5客户端发送的第2条消息
[nioEventLoopGroup-4-2] - [id: 0x5e849282, L:/127.0.0.1:8080 - R:/127.0.0.1:57422] READ: 0客户端发送的第4条消息
[defaultEventLoopGroup-2-2] DEBUG com.phz.eventloopgroup.EventLoopGroupServer - normal:0客户端发送的第4条消息
[nioEventLoopGroup-4-1] - [id: 0xc82e3224, L:/127.0.0.1:8080 - R:/127.0.0.1:57443] READ: 5客户端发送的第3条消息
[defaultEventLoopGroup-2-3] DEBUG com.phz.eventloopgroup.EventLoopGroupServer - normal:5客户端发送的第3条消息
[nioEventLoopGroup-4-1] - [id: 0xc82e3224, L:/127.0.0.1:8080 - R:/127.0.0.1:57443] READ: 5客户端发送的第4条消息
[defaultEventLoopGroup-2-3] DEBUG com.phz.eventloopgroup.EventLoopGroupServer - normal:5客户端发送的第4条消息
- d号客户端率先被Nio的工人的4-1处理，然后是Normal工人的2-1处理
- 然后看到d再次请求到服务端，这时候处理它的Nio工程仍然是4-1，Normal工人也仍然是2-1，可以看到，不仅仅是Nio的EventLoop会和Channel进行绑定，非Nio的EventLoop仍然会和Channel绑定
- 继续观察，0号客户端被Nio的4-2工人和Normal的2-2工人绑定处理
- 由于Nio的工人只有两个，所以d号客户端又被Nio的4-1号工人绑定处理，然后再被Normal的2-3号工人处理，此时Normal工人还有一个剩余，但是已经没有新的客户端连接绑定了，所以它还会被闲置！
3.2.2、关闭
shutdownGracefully() 方法会首先切换 EventLoopGroup 到关闭状态从而拒绝新的任务的加入，然后在任务队列的任务都处理完成后，停止线程的运行。从而确保整体应用是在正常有序的状态下退出的
3.2.3、Netty是如何做到由一个Nio线程交换到Normal线程呢？
- 关键代码
io.netty.channel.AbstractChannelHandlerContext#invokeChannelRead()
static void invokeChannelRead(final AbstractChannelHandlerContext next, Object msg) {
final Object m = next.pipeline.touch(ObjectUtil.checkNotNull(msg, "msg"), next);
//
EventExecutor executor = next.executor();
//校验下一个 handler 的事件循环是否与当前的事件循环是同一个线程
//是，直接调用
if (executor.inEventLoop()) {
next.invokeChannelRead(m);
}
//不是，将要执行的代码（一个可以由下一个线程直接调用的Runnable接口对象）作为任务提交给下一个事件循环处理（换人）
else {
executor.execute(new Runnable() {
@Override
public void run() {
next.invokeChannelRead(m);
}
});
}
}
- 如果两个 handler 绑定的是同一个线程，那么就直接调用
- 否则，把要调用的代码封装为一个任务Runable对象，由下一个 handler 的线程来调用
3.2.4、处理非IO任务
- 处理普通任务，可以用来执行耗时较长的任务
NioEventLoopGroup nioWorkers = new NioEventLoopGroup(2);
log.debug("server start...");
Thread.sleep(2000);
nioWorkers.execute(()->{
log.debug("normal task...");
});
输出
22:30:36 [DEBUG] [main] c.i.o.EventLoopTest2 - server start...
22:30:38 [DEBUG] [nioEventLoopGroup-2-1] c.i.o.EventLoopTest2 - normal task...
- 处理定时任务
NioEventLoopGroup nioWorkers = new NioEventLoopGroup(2);
log.debug("server start...");
Thread.sleep(2000);
nioWorkers.scheduleAtFixedRate(() -> {
log.debug("running...");
}, 0, 1, TimeUnit.SECONDS);
输出
22:35:15 [DEBUG] [main] c.i.o.EventLoopTest2 - server start...
22:35:17 [DEBUG] [nioEventLoopGroup-2-1] c.i.o.EventLoopTest2 - running...
22:35:18 [DEBUG] [nioEventLoopGroup-2-1] c.i.o.EventLoopTest2 - running...
22:35:19 [DEBUG] [nioEventLoopGroup-2-1] c.i.o.EventLoopTest2 - running...
22:35:20 [DEBUG] [nioEventLoopGroup-2-1] c.i.o.EventLoopTest2 - running...
...
3.3、Channel
Channel主要作用有：
- 发送或刷出数据
- write()：将数据写入，不一定会立刻发出，如果数据缓冲区满了才会发出
- writeAndFlush()：将数据写入并刷出
- 添加处理器
- pipeline()：添加处理器
- 关闭连接
- close()：关闭Channel
- closeFuture()：通过获取到closeFuture对象，可以选择同步处理或者异步处理关闭
3.3.1、ChannelFuture
用于使用channel()方法获取Channel对象
public static void main(String[] args) throws InterruptedException {
ChannelFuture channelFuture = new Bootstrap()
.group(new NioEventLoopGroup())
.channel(NioSocketChannel.class)
.handler(new ChannelInitializer<Channel>() {
@Override
protected void initChannel(Channel ch) {
ch.pipeline().addLast(new StringEncoder());
}
})
.connect("127.0.0.1", 8080);
channelFuture
.sync()
.channel()
.writeAndFlush(new Date() + ": hello world!");
}
注意：connect()方法是一个异步方法，并不是等到连接建立了才返回，而是立刻返回，因此channelFuture对象用channel()方法获取到的Channel对象并不一定是正确的.
解决这个问题的办法有两种
- 执行一个**sync()**阻塞方法，等到连接建立了，程序才继续执行，这是同步的做法：
.connect("127.0.0.1", 8080);
channelFuture.sync();
- 对应的，还可以使用异步回调的方式：
ChannelFuture channelFuture = new Bootstrap()
.group(new NioEventLoopGroup())
.channel(NioSocketChannel.class)
.handler(new ChannelInitializer<Channel>() {
@Override
protected void initChannel(Channel ch) {
ch.pipeline().addLast(new StringEncoder());
}
})
.connect("127.0.0.1", 8080);
channelFuture.addListener((ChannelFutureListener) future -> {
future.channel().writeAndFlush(new Date() + ": hello world!");
});
3.3.2、CloseFuture
类比于ChannelFuture，CloseFuture是一个可以用来关闭Channel的一个对象，它同样有同步和异步两种方式去关闭Channel
- 同步方法
ChannelFuture closeFuture = channel.closeFuture();
channel.close();
clouseFuture.sync();
//......close后的操作，资源清理等
- 异步方法
ChannelFuture closeFuture = channel.closeFuture();
channel.close();
closeFuture.addListener((ChannelFutureListener) future -> {
log.debug("处理关闭之后的操作");
group.shutdownGracefully();
});
3.2.3、异步提升在哪里
为什么不在一个线程中去执行建立连接、去执行关闭 channel，那样不是也可以吗？非要用这么复杂的异步方式：比如一个线程发起建立连接，另一个线程去真正建立连接 ，一个线程就能执行完毕为什么还要用多个线程来回切换，这样反而会增加时间成本？
- 思考下面的场景，4 个医生给人看病，每个病人花费 20 分钟，而且医生看病的过程中是以病人为单位的，一个病人看完了，才能看下一个病人。假设病人源源不断地来，可以计算一下 4 个医生一天工作 8 小时，处理的病人总数是：
4 * 8 * 3 = 96
- 经研究发现，看病可以细分为四个步骤，经拆分后每个步骤需要 5 分钟，如下
- 因此可以做如下优化，只有一开始，医生 2、3、4 分别要等待 5、10、15 分钟才能执行工作，但只要后续病人源源不断地来，他们就能够满负荷工作，并且处理病人的能力提高到了
4 * 8 * 12效率几乎是原来的四倍
要点
- 单线程没法异步提高效率，必须配合多线程、多核 cpu 才能发挥异步的优势
- 异步并没有缩短响应时间，反而有所增加
- 合理进行任务拆分，也是利用异步的关键
3.4、Future & Promise
在异步处理时，经常用到这两个接口，Netty中的Future和JDK中的Future同名，不过Netty Future继承自JDK Future，然后Netty Promise对Netty Future进一步进行了扩展
- JDK Future 只能同步等待任务结束（或成功、或失败）才能得到结果
- Netty Future 可以同步等待任务结束得到结果，也可以异步方式得到结果，但都是要等任务结束才能真正拿到
- Netty Promise 不仅有 Netty Future 的功能，而且脱离了任务独立存在，只作为两个线程间传递结果的容器
| 功能/名称 | jdk Future | netty Future | Promise |
|---|---|---|---|
| cancel | 取消任务 | - | - |
| isCanceled | 任务是否取消 | - | - |
| isDone | 任务是否完成，不能区分成功失败 | - | - |
| get | 获取任务结果，阻塞等待 | - | - |
| getNow | - | 获取任务结果，非阻塞，还未产生结果时返回 null | - |
| await | - | 等待任务结束，如果任务失败，不会抛异常，而是通过 isSuccess 判断 | - |
| sync | - | 等待任务结束，如果任务失败，抛出异常 | - |
| isSuccess | - | 判断任务是否成功 | - |
| cause | - | 获取失败信息，非阻塞，如果没有失败，返回null | - |
| addLinstener | - | 添加回调，异步接收结果 | - |
| setSuccess | - | - | 设置成功结果 |
| setFailure | - | - | 设置失败结果 |
3.4.1、JDK Future的使用
public static void main(String[] args) throws Exception {
int nThreads = Runtime.getRuntime().availableProcessors();
//1、显示创建线程池
ExecutorService pool = new ThreadPoolExecutor(nThreads, 200,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<>(1024), Executors.defaultThreadFactory(), new ThreadPoolExecutor.AbortPolicy());
// 2. 提交任务
Future<Integer> future = pool.submit(() -> {
log.debug("执行计算");
Thread.sleep(1000);
return 50;
});
// 3. 主线程通过 future 来获取结果
log.debug("等待结果");
log.debug("结果是 {}", future.get());
}
3.4.2、Netty Future的使用
public static void main(String[] args) throws ExecutionException, InterruptedException {
NioEventLoopGroup group = new NioEventLoopGroup();
EventLoop eventLoop = group.next();
Future<Integer> myFuture = eventLoop.submit(() -> {
log.debug("执行计算");
Thread.sleep(1000);
return 70;
});
log.debug("等待结果");
log.debug("结果是 {}", myFuture.get());
//或者异步接收结果
myFuture.addListener(future -> log.debug("接收结果:{}", future.getNow()));
}
3.4.3、Promise同步处理
public static void main(String[] args) throws Exception {
DefaultEventLoop loop = new DefaultEventLoop();
DefaultPromise<Integer> promise = new DefaultPromise<>(loop);
log.debug("start...");
loop.execute(() -> {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
promise.setSuccess(10);
log.debug("set success, {}", 10);
});
// 还没有结果，为null
log.debug("{}", promise.getNow());
log.debug("{}", promise.get());
}
3.4.3、Promise异步处理
public static void main(String[] args) throws Exception {
DefaultEventLoop loop = new DefaultEventLoop();
DefaultPromise<Integer> promise = new DefaultPromise<>(loop);
// 设置回调，异步接收结果
promise.addListener(future -> {
// 这里的 future 就是上面的 promise
log.debug("{}", future.getNow());
});
log.debug("start...");
loop.execute(() -> {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
promise.setSuccess(10);
log.debug("set success, {}", 10);
});
}
3.4.4、Promise同步处理任务失败(get & sync)
两者都会出现异常，只是 get 会再用 ExecutionException 包一层异常
public static void main(String[] args) throws Exception {
DefaultEventLoop eventExecutors = new DefaultEventLoop();
DefaultPromise<Integer> promise = new DefaultPromise<>(eventExecutors);
eventExecutors.execute(() -> {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
RuntimeException e = new RuntimeException("error...");
log.debug("set failure, {}", e.toString());
promise.setFailure(e);
});
log.debug("start...");
promise.get();
}
public static void main(String[] args) throws Exception {
DefaultEventLoop eventExecutors = new DefaultEventLoop();
DefaultPromise<Integer> promise = new DefaultPromise<>(eventExecutors);
eventExecutors.execute(() -> {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
RuntimeException e = new RuntimeException("error...");
log.debug("set failure, {}", e.toString());
promise.setFailure(e);
});
log.debug("start...");
promise.sync();
promise.getNow();
}
3.4.5、Promise同步处理任务失败(await)
与**sync()和get()**区别在于，不会抛异常
public static void main(String[] args) throws Exception {
DefaultEventLoop eventExecutors = new DefaultEventLoop();
DefaultPromise<Integer> promise = new DefaultPromise<>(eventExecutors);
eventExecutors.execute(() -> {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
RuntimeException e = new RuntimeException("error...");
log.debug("set failure, {}", e.toString());
promise.setFailure(e);
});
log.debug("start...");
promise.await();
log.debug("result {}", (promise.isSuccess() ? promise.getNow() : promise.cause()).toString());
}
3.4.6、异步处理任务失败
public static void main(String[] args) throws Exception {
DefaultEventLoop eventExecutors = new DefaultEventLoop();
DefaultPromise<Integer> promise = new DefaultPromise<>(eventExecutors);
promise.addListener(future -> {
log.debug("result {}", (promise.isSuccess() ? promise.getNow() : promise.cause()).toString());
});
eventExecutors.execute(() -> {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
RuntimeException e = new RuntimeException("error...");
log.debug("set failure, {}", e.toString());
promise.setFailure(e);
});
log.debug("start...");
}
3.4.7、await 死锁检查
即wait操作不能在EventLoop的线程中执行
public static void main(String[] args) throws Exception {
DefaultEventLoop eventExecutors = new DefaultEventLoop();
DefaultPromise<Integer> promise = new DefaultPromise<>(eventExecutors);
eventExecutors.submit(() -> {
System.out.println("1");
try {
promise.await();
// 注意不能仅捕获 InterruptedException 异常
// 否则 死锁检查抛出的 BlockingOperationException 会继续向上传播
// 而提交的任务会被包装为 PromiseTask，它的 run 方法中会 catch 所有异常然后设置为 Promise 的失败结果而不会抛出
} catch (Exception e) {
e.printStackTrace();
}
System.out.println("2");
});
eventExecutors.submit(() -> {
System.out.println("3");
try {
promise.await();
} catch (Exception e) {
e.printStackTrace();
}
System.out.println("4");
});
}
3.5、Handler & Pipeline
ChannelHandler 用来处理 Channel 上的各种事件，分为入站、出站两种。所有 ChannelHandler 被连成一串，就是 Pipeline
- 入站处理器通常是 ChannelInboundHandlerAdapter 的子类，主要用来读取客户端数据，写回结果
- 出站处理器通常是 ChannelOutboundHandlerAdapter 的子类，主要对写回结果进行加工
3.5.1、Inbound
客户端
/**
* @author PengHuanZhi
* @date 2021年11月29日 19:09
*/
public class PipelineHandlerClientTest {
public static void main(String[] args) {
new Bootstrap()
.group(new NioEventLoopGroup())
.channel(NioSocketChannel.class)
.handler(new ChannelInitializer<Channel>() {
@Override
protected void initChannel(Channel ch) {
ch.pipeline().addLast(new StringEncoder());
}
})
.connect("127.0.0.1", 8080)
.addListener((ChannelFutureListener) future -> {
future.channel().writeAndFlush("hello,world");
});
}
}
服务端
/**
* @author PengHuanZhi
* @date 2021年11月29日 17:45
*/
@Slf4j
public class PipelineHandlerServerTest {
public static void main(String[] args) throws Exception {
new ServerBootstrap()
.group(new NioEventLoopGroup())
.channel(NioServerSocketChannel.class)
.childHandler(new ChannelInitializer<NioSocketChannel>() {
@Override
protected void initChannel(NioSocketChannel ch) throws Exception {
ChannelPipeline pipeline = ch.pipeline();
pipeline.addLast("h1", new ChannelInboundHandlerAdapter() {
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
log.debug("1");
ByteBuf buf = (ByteBuf) msg;
String name = buf.toString(Charset.defaultCharset());
super.channelRead(ctx, name);
}
});
pipeline.addLast("h2", new ChannelInboundHandlerAdapter() {
@Override
public void channelRead(ChannelHandlerContext ctx, Object name) throws Exception {
log.debug("2");
Student student = new Student(name.toString());
super.channelRead(ctx, student);
}
});
pipeline.addLast("h3", new ChannelInboundHandlerAdapter() {
@Override
public void channelRead(ChannelHandlerContext ctx, Object student) throws Exception {
log.debug("3");
log.debug("msg,{}", student);
}
}).bind(8080);
}
@Data
@NoArgsConstructor
@AllArgsConstructor
static class Student {
private String name;
}
}
结果：
3.5.2、Outbound
/**
* @author PengHuanZhi
* @date 2021年11月29日 17:45
*/
@Slf4j
public class PipelineHandlerServerTest {
public static void main(String[] args) throws Exception {
new ServerBootstrap()
.group(new NioEventLoopGroup())
.channel(NioServerSocketChannel.class)
.childHandler(new ChannelInitializer<NioSocketChannel>() {
@Override
protected void initChannel(NioSocketChannel ch) throws Exception {
ChannelPipeline pipeline = ch.pipeline();
pipeline.addLast("h0", new ChannelInboundHandlerAdapter() {
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
ctx.channel().write("123");
}
});
pipeline.addLast("h1", new ChannelOutboundHandlerAdapter() {
@Override
public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception {
log.debug("1");
super.write(ctx, msg, promise);
}
});
pipeline.addLast("h2", new ChannelOutboundHandlerAdapter() {
@Override
public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception {
log.debug("2");
super.write(ctx, msg, promise);
}
});
pipeline.addLast("h3", new ChannelOutboundHandlerAdapter() {
@Override
public void write(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) throws Exception {
log.debug("3");
super.write(ctx, msg, promise);
}
});
}
}).bind(8080);
}
}
结果：
3.5.3、执行顺序分析
可以看到，ChannelInboundHandlerAdapter 是按照 addLast 的顺序执行的，而 ChannelOutboundHandlerAdapter 是按照 addLast 的逆序执行的。ChannelPipeline 的实现是一个 ChannelHandlerContext（包装了 ChannelHandler） 组成的双向链表
- 入站处理器中，super.channelRead(ctx, msg) 是会从头部开始触发调用下一个入站处理器，非末尾Handler必须执行，否则后面的处理器将不会执行
- 在最后一个入站处理器中，ctx.channel().write(msg) 会从尾部开始触发后续出站处理器的执行
- 类似的，出站处理器中，ctx.write(msg, promise) 的调用也会触发上一个出站处理器
ctx.channel().write(msg) vs ctx.write(msg)
-
都是触发出站处理器的执行
-
ctx.channel().write(msg) 从尾部开始查找出站处理器，使用此方法需要注意，使用不当会陷入死循环
- ctx.write(msg) 是从当前节点找上一个出站处理器，使用此方法需要注意，其前方有没有其他出站处理器
服务端 pipeline 触发的原始流程，图中数字代表了处理步骤的先后次序
3.5.4、EmbeddedChannel调试工具类
package com.phz.pipelinehandler;
import io.netty.buffer.ByteBufAllocator;
import io.netty.channel.ChannelHandlerContext;
import io.netty.channel.ChannelInboundHandlerAdapter;
import io.netty.channel.embedded.EmbeddedChannel;
import lombok.extern.slf4j.Slf4j;
import java.nio.charset.StandardCharsets;
/**
* @author PengHuanZhi
* @date 2021年11月29日 19:34
*/
@Slf4j
public class TestEmbeddedChannel {
public static void main(String[] args) {
ChannelInboundHandlerAdapter h1 = new ChannelInboundHandlerAdapter() {
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
log.debug("1");
super.channelRead(ctx, msg);
}
};
ChannelInboundHandlerAdapter h2 = new ChannelInboundHandlerAdapter() {
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
log.debug("2");
super.channelRead(ctx, msg);
}
};
ChannelInboundHandlerAdapter h3 = new ChannelInboundHandlerAdapter() {
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
log.debug("3");
super.channelRead(ctx, msg);
}
};
ChannelInboundHandlerAdapter h4 = new ChannelInboundHandlerAdapter() {
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
log.debug("4");
super.channelRead(ctx, msg);
}
};
EmbeddedChannel embeddedChannel = new EmbeddedChannel(h1, h2, h3, h4);
//模拟入站操作
embeddedChannel.writeInbound(ByteBufAllocator.DEFAULT.buffer().writeBytes("hello".getBytes(StandardCharsets.UTF_8)));
//模拟出站操作
embeddedChannel.writeOutbound(ByteBufAllocator.DEFAULT.buffer().writeBytes("world".getBytes(StandardCharsets.UTF_8)));
}
}
3.6、ByteBuf
3.6.1、调试方法
便于后面调试，添加一个日志方法
private static void log(ByteBuf buffer) {
int length = buffer.readableBytes();
int rows = length / 16 + (length % 15 == 0 ? 0 : 1) + 4;
StringBuilder buf = new StringBuilder(rows * 80 * 2)
.append("read index:").append(buffer.readerIndex())
.append(" write index:").append(buffer.writerIndex())
.append(" capacity:").append(buffer.capacity())
.append(NEWLINE);
appendPrettyHexDump(buf, buffer);
System.out.println(buf.toString());
}
3.6.2、创建
创建一个默认的 ByteBuf，初始容量是 10
ByteBuf buffer = ByteBufAllocator.DEFAULT.buffer(10);
log(buffer);
输出
read index:0 write index:0 capacity:10
3.6.3、池化 vs 非池化
对于一些创建比较耗时的资源，可以采用池的思想去优化它，也就是池化，如数据库连接池，线程池等，Netty中的ByteBuf便支持池化的功能，用完后归还到池里即可，其中的优点有：
- 没有池化，则每次都得创建新的 ByteBuf 实例，这个操作对直接内存代价昂贵，就算是堆内存，也会增加 GC 压力
- 有了池化，则可以重用池中 ByteBuf 实例，并且采用了与 jemalloc 类似的内存分配算法提升分配效率
- 高并发时，池化功能更节约内存，减少内存溢出的可能
池化功能是否开启（非Android默认开启），可以通过下面的系统环境变量来设置
-Dio.netty.allocator.type={unpooled|pooled}
配合IDEA使用，需要在启动参数添加一个VM Options
测试一下
public static void main(String[] args) {
ByteBuf buf = ByteBufAllocator.DEFAULT.buffer();
System.out.println(buf.getClass());
System.out.println(buf.maxCapacity());
log(buf);
StringBuilder sb = new StringBuilder();
for (int i = 0; i < 32; i++) {
sb.append("a");
}
buf.writeBytes(sb.toString().getBytes());
log(buf);
}
- 4.1 以后，非 Android 平台默认启用池化实现，Android 平台启用非池化实现
- 4.1 之前，池化功能还不成熟，默认是非池化实现
3.6.4、直接内存 vs 堆内存
可以使用**heapBuffer()**来创建池化基于堆的 ByteBuf
ByteBuf buffer = ByteBufAllocator.DEFAULT.heapBuffer(10);
也可以使用**directBuffer()**来创建池化基于直接内存的 ByteBuf
ByteBuf buffer = ByteBufAllocator.DEFAULT.directBuffer(10);
- 直接内存创建和销毁的代价昂贵，但读写性能高（少一次内存复制），适合配合池化功能一起用
- 直接内存对 GC 压力小，因为这部分内存不受 JVM 垃圾回收的管理，但也要注意及时主动释放
3.6.5、组成
ByteBuf 由四部分组成
最开始读写指针都在 0位置
3.6.6、写入
方法列表，省略了一些不重要的方法
| 方法签名 | 含义 | 备注 |
|---|---|---|
| writeBoolean(boolean value) | 写入 boolean 值 | 用一字节 01|00 代表 true|false |
| writeByte(int value) | 写入 byte 值 | |
| writeShort(int value) | 写入 short 值 | |
| writeInt(int value) | 写入 int 值 | Big Endian，即 0x250，写入后 00 00 02 50 |
| writeIntLE(int value) | 写入 int 值 | Little Endian，即 0x250，写入后 50 02 00 00 |
| writeLong(long value) | 写入 long 值 | |
| writeChar(int value) | 写入 char 值 | |
| writeFloat(float value) | 写入 float 值 | |
| writeDouble(double value) | 写入 double 值 | |
| writeBytes(ByteBuf src) | 写入 netty 的 ByteBuf | |
| writeBytes(byte[] src) | 写入 byte[] | |
| writeBytes(ByteBuffer src) | 写入 nio 的 ByteBuffer | |
| int writeCharSequence(CharSequence sequence, Charset charset) | 写入字符串 |
注意
- 这些方法都未指明返回值的，其返回值都是 ByteBuf，意味着可以链式调用
- 网络传输，默认习惯是 Big Endian
- 写入4字节：
buf.writeBytes(new byte[]{1, 2, 3, 4});
log(buf);
- 再写入一个 int 整数，也是 4 个字节
buf.writeBytes(new byte[]{1, 2, 3, 4});
buf.writeInt(5);
log(buf);
还有一种set开头的一系列方法，也能写入数据，不过写了以后不会改变读写指针的位置
3.6.7、扩容
对一个容量为10的buf中写入三个 int 整数时，容量不够了，这时会引发扩容
ByteBuf buf = ByteBufAllocator.DEFAULT.buffer(5);
log(buf);
buf.writeInt(1).writeInt(2);
log(buf);
buf.writeInt(3).writeInt(4).writeInt(5);
log(buf);
扩容规则
- 扩容规则是
- 如何写入后数据大小未超过 512，则选择下一个 16 的整数倍，例如写入后大小为 12 ，则扩容后 capacity 是 16
- 如果写入后数据大小超过 512，则选择下一个 2^n，例如写入后大小为 513，则扩容后 capacity 是 210=1024（29=512 已经不够了）
- 扩容不能超过 max capacity 会报错(一般默认是Integer的最大值)
3.6.8、读取
读 4 次，每次一个字节
ByteBuf buf = ByteBufAllocator.DEFAULT.buffer(5);
buf.writeInt(1).writeInt(2);
log(buf);
System.out.println(buf.readByte());
System.out.println(buf.readByte());
System.out.println(buf.readByte());
System.out.println(buf.readByte());
log(buf);
读过的内容，就属于废弃部分了，再读只能读那些尚未读取的部分
和原生Java NIO中的ByteBuffer类似，如果需要重复读取一个值，有两种方式，第一种就是前面提到的用get的方式去读，另一种就是做一个mark标记
buffer.markReaderIndex();
System.out.println(buffer.readInt());
log(buffer);
结果
5
read index:8 write index:12 capacity:16
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 a b c d e f |
+--------+-------------------------------------------------+----------------+
|00000000| 00 00 00 06 |.... |
+--------+-------------------------------------------------+----------------+
这时要重复读取的话，重置到标记位置 reset
buffer.resetReaderIndex();
log(buffer);
这时
read index:4 write index:12 capacity:16
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 a b c d e f |
+--------+-------------------------------------------------+----------------+
|00000000| 00 00 00 05 00 00 00 06 |........ |
+--------+-------------------------------------------------+----------------+
3.6.9、retain & release
由于 Netty 中有堆外内存的 ByteBuf 实现，堆外内存最好是手动来释放，而不是等 GC 垃圾回收。
- UnpooledHeapByteBuf 使用的是 JVM 内存，只需等 GC 回收内存即可
- UnpooledDirectByteBuf 使用的就是直接内存了，需要特殊的方法来回收内存
- PooledByteBuf 和它的子类使用了池化机制，需要更复杂的规则来回收内存
回收内存的源码实现，关注AbstractReferenceCounted类的下面方法的不同实现
protected abstract void deallocate()
Netty 这里采用了引用计数法来控制回收内存，每个 ByteBuf 都实现了 ReferenceCounted 接口
public abstract class ByteBuf implements ReferenceCounted, Comparable<ByteBuf>
- 每个 ByteBuf 对象的初始计数为 1
- 调用 release 方法计数减 1，如果计数为 0，ByteBuf 内存被回收
- 调用 retain 方法计数加 1，表示调用者没用完之前，其它 handler 即使调用了 release 也不会造成回收
- 当计数为 0 时，底层内存会被回收，这时即使 ByteBuf 对象还在，其各个方法均无法正常使用
谁来负责回收release呢？可不可以在每次使用完ByteBuf后，直接在finally的时候调用**buf.release()**方法呢？
ByteBuf buf = ...
try {
...
} finally {
buf.release();
}
因为 pipeline 的存在，一般需要将 ByteBuf 传递给下一个 ChannelHandler，如果在 finally 中 release 了，就失去了传递性（当然，如果在这个 ChannelHandler 内这个 ByteBuf 已完成了它的使命，那么便无须再传递）
基本规则：谁是最后使用者，谁负责 release，详细分析如下：
- 起点，对于 NIO 实现来讲，在
io.netty.channel.nio.AbstractNioByteChannel.NioByteUnsafe#read方法中首次创建 ByteBuf 放入 pipeline（line 166 pipeline.fireChannelRead(byteBuf)）
-
入站ByteBuf处理规则
-
对原始 ByteBuf 不做处理，调用 ctx.fireChannelRead(msg) 向后传递，这时无须 release
-
将原始 ByteBuf 转换为其它类型的 Java 对象，这时 ByteBuf 就没用了，必须 release
-
如果不调用 ctx.fireChannelRead(msg) 向后传递，那么也必须 release
-
注意各种异常，如果 ByteBuf 没有成功传递到下一个 ChannelHandler，必须 release
-
假设消息一直向后传，那么 TailContext 会负责释放未处理消息（原始的 ByteBuf）
-
-
出站 ByteBuf 处理原则
- 出站消息最终都会转为 ByteBuf 输出，一直向前传，由 HeadContext flush 后 release
-
异常处理原则
- 有时候不清楚 ByteBuf 被引用了多少次，但又必须彻底释放，可以循环调用 release 直到返回 true
TailContext 释放未处理消息逻辑
io.netty.channel.DefaultChannelPipeline#onUnhandledInboundMessage(java.lang.Object)
public static boolean release(Object msg) {
if (msg instanceof ReferenceCounted) {
return ((ReferenceCounted) msg).release();
}
return false;
}
3.6.10、slice
零拷贝的体现之一，对原始 ByteBuf 进行切片成多个 ByteBuf，切片后的 ByteBuf 并没有发生内存复制，还是使用原始 ByteBuf 的内存，切片后的 ByteBuf 维护独立的 read，write 指针
例，原始 ByteBuf 进行一些初始操作
ByteBuf origin = ByteBufAllocator.DEFAULT.buffer(10);
origin.writeBytes(new byte[]{1, 2, 3, 4});
origin.readByte();
System.out.println(ByteBufUtil.prettyHexDump(origin));
输出
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 a b c d e f |
+--------+-------------------------------------------------+----------------+
|00000000| 02 03 04 |... |
+--------+-------------------------------------------------+----------------+
这时调用 slice 进行切片，无参 slice 是从原始 ByteBuf 的 read index 到 write index 之间的内容进行切片，切片后的 max capacity 被固定为这个区间的大小，因此不能追加 write
ByteBuf slice = origin.slice();
System.out.println(ByteBufUtil.prettyHexDump(slice));
// slice.writeByte(5); 如果执行，会报 IndexOutOfBoundsException 异常
输出
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 a b c d e f |
+--------+-------------------------------------------------+----------------+
|00000000| 02 03 04 |... |
+--------+-------------------------------------------------+----------------+
如果原始 ByteBuf 再次读操作（又读了一个字节）
origin.readByte();
System.out.println(ByteBufUtil.prettyHexDump(origin));
输出
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 a b c d e f |
+--------+-------------------------------------------------+----------------+
|00000000| 03 04 |.. |
+--------+-------------------------------------------------+----------------+
这时的 slice 不受影响，因为它有独立的读写指针
System.out.println(ByteBufUtil.prettyHexDump(slice));
输出
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 a b c d e f |
+--------+-------------------------------------------------+----------------+
|00000000| 02 03 04 |... |
+--------+-------------------------------------------------+----------------+
如果 slice 的内容发生了更改
slice.setByte(2, 5);
System.out.println(ByteBufUtil.prettyHexDump(slice));
输出
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 a b c d e f |
+--------+-------------------------------------------------+----------------+
|00000000| 02 03 05 |... |
+--------+-------------------------------------------------+----------------+
这时，原始 ByteBuf 也会受影响，因为底层都是同一块内存
System.out.println(ByteBufUtil.prettyHexDump(origin));
输出
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 a b c d e f |
+--------+-------------------------------------------------+----------------+
|00000000| 03 05 |.. |
+--------+-------------------------------------------------+----------------+
3.6.11、duplicate
零拷贝的体现之一，就好比截取了原始 ByteBuf 所有内容，并且没有 max capacity 的限制，也是与原始 ByteBuf 使用同一块底层内存，只是读写指针是独立的
3.6.12、copy
会将底层内存数据进行深拷贝，因此无论读写，都与原始 ByteBuf 无关
3.6.13、CompositeByteBuf
零拷贝的体现之一，可以将多个 ByteBuf 合并为一个逻辑上的 ByteBuf，避免拷贝
有两个 ByteBuf 如下
ByteBuf buf1 = ByteBufAllocator.DEFAULT.buffer(5);
buf1.writeBytes(new byte[]{1, 2, 3, 4, 5});
ByteBuf buf2 = ByteBufAllocator.DEFAULT.buffer(5);
buf2.writeBytes(new byte[]{6, 7, 8, 9, 10});
System.out.println(ByteBufUtil.prettyHexDump(buf1));
System.out.println(ByteBufUtil.prettyHexDump(buf2));
输出
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 a b c d e f |
+--------+-------------------------------------------------+----------------+
|00000000| 01 02 03 04 05 |..... |
+--------+-------------------------------------------------+----------------+
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 a b c d e f |
+--------+-------------------------------------------------+----------------+
|00000000| 06 07 08 09 0a |..... |
+--------+-------------------------------------------------+----------------+
现在需要一个新的 ByteBuf，内容来自于刚才的 buf1 和 buf2，如何实现？
- 方法1：
ByteBuf buf3 = ByteBufAllocator.DEFAULT
.buffer(buf1.readableBytes()+buf2.readableBytes());
buf3.writeBytes(buf1);
buf3.writeBytes(buf2);
System.out.println(ByteBufUtil.prettyHexDump(buf3));
结果
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 a b c d e f |
+--------+-------------------------------------------------+----------------+
|00000000| 01 02 03 04 05 06 07 08 09 0a |.......... |
+--------+-------------------------------------------------+----------------+
这种方法好不好？回答是不太好，因为进行了数据的内存复制操作
- 方法2：
CompositeByteBuf buf3 = ByteBufAllocator.DEFAULT.compositeBuffer();
// true 表示增加新的 ByteBuf 自动递增 write index, 否则 write index 会始终为 0
buf3.addComponents(true, buf1, buf2);
结果是一样的
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 a b c d e f |
+--------+-------------------------------------------------+----------------+
|00000000| 01 02 03 04 05 06 07 08 09 0a |.......... |
+--------+-------------------------------------------------+----------------+
CompositeByteBuf 是一个组合的 ByteBuf，它内部维护了一个 Component 数组，每个 Component 管理一个 ByteBuf，记录了这个 ByteBuf 相对于整体偏移量等信息，代表着整体中某一段的数据。
- 优点，对外是一个虚拟视图，组合这些 ByteBuf 不会产生内存复制
- 缺点，复杂了很多，多次操作会带来性能的损耗
3.6.14、Unpooled
Unpooled 是一个工具类，类如其名，提供了非池化的 ByteBuf 创建、组合、复制等操作
- 这里仅介绍其跟
零拷贝相关的 wrappedBuffer 方法，可以用来包装 ByteBuf
ByteBuf buf1 = ByteBufAllocator.DEFAULT.buffer(5);
buf1.writeBytes(new byte[]{1, 2, 3, 4, 5});
ByteBuf buf2 = ByteBufAllocator.DEFAULT.buffer(5);
buf2.writeBytes(new byte[]{6, 7, 8, 9, 10});
// 当包装 ByteBuf 个数超过一个时, 底层使用了 CompositeByteBuf
ByteBuf buf3 = Unpooled.wrappedBuffer(buf1, buf2);
System.out.println(ByteBufUtil.prettyHexDump(buf3));
输出
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 a b c d e f |
+--------+-------------------------------------------------+----------------+
|00000000| 01 02 03 04 05 06 07 08 09 0a |.......... |
+--------+-------------------------------------------------+----------------+
也可以用来包装普通字节数组，底层也不会有拷贝操作
ByteBuf buf4 = Unpooled.wrappedBuffer(new byte[]{1, 2, 3}, new byte[]{4, 5, 6});
System.out.println(buf4.getClass());
System.out.println(ByteBufUtil.prettyHexDump(buf4));
输出
class io.netty.buffer.CompositeByteBuf
+-------------------------------------------------+
| 0 1 2 3 4 5 6 7 8 9 a b c d e f |
+--------+-------------------------------------------------+----------------+
|00000000| 01 02 03 04 05 06 |...... |
+--------+-------------------------------------------------+----------------+
3.6.15、💡 ByteBuf 优势
- 池化 - 可以重用池中 ByteBuf 实例，更节约内存，减少内存溢出的可能
- 读写指针分离，不需要像 ByteBuffer 一样切换读写模式
- 可以自动扩容
- 支持链式调用，使用更流畅
- 很多地方体现零拷贝，例如 slice、duplicate、CompositeByteBuf
4、双向通信
4.1、实战练习
编写可以双向通信的客户端和服务端，要求客户端发送到服务器后，服务器立马打印返回该消息，客户端再将这个消息打印出来
服务端
/**
* @author PengHuanZhi
* @date 2021年11月30日 16:53
*/
public class TestServer {
public static void main(String[] args) {
new ServerBootstrap()
.group(new NioEventLoopGroup())
.channel(NioServerSocketChannel.class)
.childHandler(new ChannelInitializer<NioSocketChannel>() {
@Override
protected void initChannel(NioSocketChannel ch) throws Exception {
ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
ByteBuf buf = (ByteBuf) msg;
String buffer = buf.toString(Charset.defaultCharset());
//将当前ByteBuf转换为其他的对象后，原始ByteBuf就需要释放掉
buf.release();
System.out.println(buffer);
// 建议使用 ctx.alloc() 创建 ByteBuf
ByteBuf response = ctx.alloc().buffer();
response.writeBytes(buffer.getBytes(Charset.defaultCharset()));
ctx.channel().writeAndFlush(response);
}
});
}
})
.bind(8000);
}
}
客户端
/**
* @author PengHuanZhi
* @date 2021年11月30日 16:54
*/
public class TestClient {
public static void main(String[] args) throws Exception {
NioEventLoopGroup group = new NioEventLoopGroup();
Channel channel = new Bootstrap()
.group(group)
.channel(NioSocketChannel.class)
.handler(new ChannelInitializer<NioSocketChannel>() {
@Override
protected void initChannel(NioSocketChannel ch) throws Exception {
ch.pipeline().addLast(new StringEncoder());
ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
ByteBuf buf = (ByteBuf) msg;
System.out.println(buf.toString(Charset.defaultCharset()));
}
});
}
})
.connect("localhost", 8000)
.sync()
.channel();
channel.closeFuture().addListener(future -> {
group.shutdownGracefully();
});
new Thread(() -> {
Scanner scanner = new Scanner(System.in);
while (true) {
String s = scanner.nextLine();
if ("q".equals(s)) {
channel.close();
break;
}
channel.writeAndFlush(s);
}
}).start();
}
}
4.2、💡 读和写的误解
误区：认为只有在 netty，nio 这样的多路复用 IO 模型时，读写才不会相互阻塞，才可以实现高效的双向通信，但实际上，Java Socket 是全双工的：在任意时刻，线路上存在
A 到 B和B 到 A的双向信号传输。即使是阻塞 IO，读和写是可以同时进行的，只要分别采用读线程和写线程即可，读不会阻塞写、写也不会阻塞读
- 例如：服务端
public class TestServer {
public static void main(String[] args) throws IOException {
ServerSocket ss = new ServerSocket(8888);
Socket s = ss.accept();
new Thread(() -> {
try {
BufferedReader reader = new BufferedReader(new InputStreamReader(s.getInputStream()));
while (true) {
System.out.println(reader.readLine());
}
} catch (IOException e) {
e.printStackTrace();
}
}).start();
new Thread(() -> {
try {
BufferedWriter writer = new BufferedWriter(new OutputStreamWriter(s.getOutputStream()));
// 例如在这个位置加入 thread 级别断点，可以发现即使不写入数据，也不妨碍前面线程读取客户端数据
for (int i = 0; i < 100; i++) {
writer.write(String.valueOf(i));
writer.newLine();
writer.flush();
}
} catch (IOException e) {
e.printStackTrace();
}
}).start();
}
}
- 客户端
public class TestClient {
public static void main(String[] args) throws IOException {
Socket s = new Socket("localhost", 8888);
new Thread(() -> {
try {
BufferedReader reader = new BufferedReader(new InputStreamReader(s.getInputStream()));
while (true) {
System.out.println(reader.readLine());
}
} catch (IOException e) {
e.printStackTrace();
}
}).start();
new Thread(() -> {
try {
BufferedWriter writer = new BufferedWriter(new OutputStreamWriter(s.getOutputStream()));
for (int i = 0; i < 100; i++) {
writer.write(String.valueOf(i));
writer.newLine();
writer.flush();
}
} catch (IOException e) {
e.printStackTrace();
}
}).start();
}
}
5、粘包与半包
5.1、粘包现象
服务端代码
/**
* @author PengHuanZhi
* @date 2021年12月01日 15:44
*/
@Slf4j
public class DemoServer {
public static void main(String[] args) {
NioEventLoopGroup boss = new NioEventLoopGroup(1);
NioEventLoopGroup worker = new NioEventLoopGroup();
try {
ChannelFuture channelFuture = new ServerBootstrap()
.channel(NioServerSocketChannel.class)
.group(boss, worker)
.childHandler(new ChannelInitializer<SocketChannel>() {
@Override
protected void initChannel(SocketChannel ch) throws Exception {
ch.pipeline().addLast(new LoggingHandler(LogLevel.DEBUG));
ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
@Override
public void channelActive(ChannelHandlerContext ctx) throws Exception {
log.debug("connected {}", ctx.channel());
super.channelActive(ctx);
}
@Override
public void channelInactive(ChannelHandlerContext ctx) throws Exception {
log.debug("disconnect {}", ctx.channel());
super.channelInactive(ctx);
}
});
}
}).bind(8080);
log.debug("{} binding...", channelFuture.channel());
channelFuture.sync();
log.debug("{} bound...", channelFuture.channel());
channelFuture.channel().closeFuture().sync();
} catch (InterruptedException e) {
log.error("server error", e);
} finally {
boss.shutdownGracefully();
worker.shutdownGracefully();
log.debug("stopped");
}
}
}
客户端代码希望发送 10 个消息，每个消息是 16 字节
/**
* @author PengHuanZhi
* @date 2021年12月01日 15:47
*/
@Slf4j
public class DemoClient {
public static void main(String[] args) {
NioEventLoopGroup worker = new NioEventLoopGroup();
try {
Bootstrap bootstrap = new Bootstrap();
bootstrap.channel(NioSocketChannel.class);
bootstrap.group(worker);
bootstrap.handler(new ChannelInitializer<SocketChannel>() {
@Override
protected void initChannel(SocketChannel ch) throws Exception {
log.debug("connected...");
ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
@Override
public void channelActive(ChannelHandlerContext ctx) throws Exception {
log.debug("sending...");
for (int i = 0; i < 10; i++) {
ByteBuf buffer = ctx.alloc().buffer();
buffer.writeBytes(new byte[]{0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15});
ctx.writeAndFlush(buffer);
}
}
});
}
});
ChannelFuture channelFuture = bootstrap.connect("127.0.0.1", 8080).sync();
channelFuture.channel().closeFuture().sync();
} catch (InterruptedException e) {
log.error("client error", e);
} finally {
worker.shutdownGracefully();
}
}
}
服务器端的某次输出，可以看到一次就接收了 160 个字节，而非分 10 次接收
5.2、半包现象
客户端代码希望发送 1 个消息，这个消息是 160 字节，代码改为
ByteBuf buffer = ctx.alloc().buffer();
for (int i = 0; i < 10; i++) {
buffer.writeBytes(new byte[]{0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15});
}
ctx.writeAndFlush(buffer);
为现象明显，服务端修改一下接收缓冲区，其它代码不变
serverBootstrap.option(ChannelOption.SO_RCVBUF, 10);
服务器端的某次输出，可以看到接收的消息被分为两节，第一次 20 字节，第二次 140 字节
注意
serverBootstrap.option(ChannelOption.SO_RCVBUF, 10) 影响的底层接收缓冲区（即滑动窗口）大小，仅决定了 netty 读取的最小单位，netty 实际每次读取的一般是它的整数倍
5.3、现象分析
粘包
- 现象，发送 abc def，接收 abcdef
- 原因
- 应用层：接收方 ByteBuf 设置太大（Netty 默认 1024）
- 滑动窗口：假设发送方 256 bytes 表示一个完整报文，但由于接收方处理不及时且窗口大小足够大，这 256 bytes 字节就会缓冲在接收方的滑动窗口中，当滑动窗口中缓冲了多个报文就会粘包
- Nagle 算法：会造成粘包
半包
- 现象，发送 abcdef，接收 abc def
- 原因
- 应用层：接收方 ByteBuf 小于实际发送数据量
- 滑动窗口：假设接收方的窗口只剩了 128 bytes，发送方的报文大小是 256 bytes，这时放不下了，只能先发送前 128 bytes，等待 ack 后才能发送剩余部分，这就造成了半包
- MSS 限制：当发送的数据超过 MSS 限制后，会将数据切分发送，就会造成半包
本质是因为 TCP 是流式协议，消息无边界
滑动窗口
TCP 以一个段（segment）为单位，每发送一个段就需要进行一次确认应答（ack）处理，但如果这么做，缺点是包的往返时间越长性能就越差
为了解决此问题，引入了窗口概念，窗口大小即决定了无需等待应答而可以继续发送的数据最大值
窗口实际就起到一个缓冲区的作用，同时也能起到流量控制的作用
- 窗口内的数据才允许被发送，当应答未到达前，窗口必须停止滑动
- 比如 1001~2000 这个段的数据 ack 回来了，窗口就可以向前滑动
- 接收方也会维护一个窗口，只有落在窗口内的数据才能允许接收
MSS 限制
链路层对一次能够发送的最大数据有限制，这个限制称之为 MTU（
maximum transmission unit），不同的链路设备的 MTU 值也有所不同，例如
- 以太网的 MTU 是 1500
- FDDI（光纤分布式数据接口）的 MTU 是 4352
- 本地回环地址（127.0.0.1）的 MTU 是 65535 - 本地测试不走网卡
MSS 是最大段长度（
maximum segment size），它是 MTU 刨去 tcp 头和 ip 头后剩余能够作为数据传输的字节数
- ipv4 tcp 头占用 20 bytes，ip 头占用 20 bytes，因此以太网 MSS 的值为 1500 - 40 = 1460
TCP 在传递大量数据时，会按照 MSS 大小将数据进行分割发送
MSS 的值在三次握手时通知对方自己 MSS 的值，然后在两者之间选择一个小值作为 MSS
Nagle 算法
- 即使发送一个字节，也需要加入 tcp 头和 ip 头，也就是总字节数会使用 41 bytes，非常不经济。因此为了提高网络利用率，tcp 希望尽可能发送足够大的数据，这就是 Nagle 算法产生的缘由
- 该算法是指发送端即使还有应该发送的数据，但如果这部分数据很少的话，则进行延迟发送
- 如果 SO_SNDBUF 的数据达到 MSS，则需要发送
- 如果 SO_SNDBUF 中含有 FIN（表示需要连接关闭）这时将剩余数据发送，再关闭
- 如果 TCP_NODELAY = true，则需要发送
- 已发送的数据都收到 ack 时，则需要发送
- 上述条件不满足，但发生超时（一般为 200ms）则需要发送
- 除上述情况，延迟发送
5.4、解决方案
- 短链接，发一个包建立一次连接，这样连接建立到连接断开之间就是消息的边界，缺点效率太低
- 每一条消息采用固定长度，缺点浪费空间
- 每一条消息采用分隔符，例如 \n，缺点需要转义
- 每一条消息分为 head 和 body，head 中包含 body 的长度
5.4.1、短链接
出现粘包半包的原因就是TCP的消息没有边界，所以就使用短链接认为的创造消息的边界
也就是在每次发送完消息后，手动的关闭channel
/**
* @author PengHuanZhi
* @date 2021年12月01日 16:00
*/
@Slf4j
public class ShortConnClient {
public static void main(String[] args) {
NioEventLoopGroup worker = new NioEventLoopGroup();
try {
Bootstrap bootstrap = new Bootstrap();
bootstrap.channel(NioSocketChannel.class);
bootstrap.group(worker);
bootstrap.handler(new ChannelInitializer<SocketChannel>() {
@Override
protected void initChannel(SocketChannel ch) throws Exception {
log.debug("connected...");
ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
@Override
public void channelActive(ChannelHandlerContext ctx) throws Exception {
log.debug("sending...");
ByteBuf buffer = ctx.alloc().buffer();
buffer.writeBytes(new byte[]{0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15});
ctx.writeAndFlush(buffer);
// 发完即关
ctx.close();
}
});
}
});
ChannelFuture channelFuture = bootstrap.connect("127.0.0.1", 8080).sync();
channelFuture.channel().closeFuture().sync();
} catch (InterruptedException e) {
log.error("client error", e);
} finally {
worker.shutdownGracefully();
}
}
}
半包用这种办法还是不好解决，因为接收方的缓冲区大小是有限的
5.4.2、固定长度
- 需要借助Netty提供的定长解码处理器FixedLengthFrameDecoder
客户端：创建一个80个字节长度的ByteBuf，一次性发送给服务端
/**
* @author PengHuanZhi
* @date 2021年12月01日 16:04
*/
@Slf4j
public class FixedLengthClient {
public static void main(String[] args) {
NioEventLoopGroup worker = new NioEventLoopGroup();
try {
Bootstrap bootstrap = new Bootstrap();
bootstrap.channel(NioSocketChannel.class);
bootstrap.group(worker);
bootstrap.handler(new ChannelInitializer<SocketChannel>() {
@Override
protected void initChannel(SocketChannel ch) throws Exception {
log.debug("connected...");
ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
@Override
public void channelActive(ChannelHandlerContext ctx) throws Exception {
log.debug("sending...");
ByteBuf buffer = ctx.alloc().buffer();
// 发送内容随机的数据包
Random r = new Random();
char c = 'a';
for (int i = 0; i < 10; i++) {
byte[] bytes = new byte[8];
for (int j = 0; j < r.nextInt(8); j++) {
bytes[j] = (byte) c;
}
c++;
buffer.writeBytes(bytes);
}
ctx.writeAndFlush(buffer);
}
});
}
});
ChannelFuture channelFuture = bootstrap.connect("127.0.0.1", 8080).sync();
channelFuture.channel().closeFuture().sync();
} catch (InterruptedException e) {
log.error("client error", e);
} finally {
worker.shutdownGracefully();
}
}
}
服务端：使用定长解码处理器FixedLengthFrameDecoder定长解码ByteBuf：
/**
* @author PengHuanZhi
* @date 2021年12月01日 16:04
*/
@Slf4j
public class FixedLengthServer {
public static void main(String[] args) {
NioEventLoopGroup boss = new NioEventLoopGroup(1);
NioEventLoopGroup worker = new NioEventLoopGroup();
try {
ChannelFuture channelFuture = new ServerBootstrap()
.channel(NioServerSocketChannel.class)
.group(boss, worker)
.option(ChannelOption.SO_RCVBUF, 10)
.childHandler(new ChannelInitializer<SocketChannel>() {
@Override
protected void initChannel(SocketChannel ch) throws Exception {
//需要首先定长解码
ch.pipeline().addLast(new FixedLengthFrameDecoder(8));
ch.pipeline().addLast(new LoggingHandler(LogLevel.DEBUG));
}
}).bind(8080);
log.debug("{} binding...", channelFuture.channel());
channelFuture.sync();
log.debug("{} bound...", channelFuture.channel());
channelFuture.channel().closeFuture().sync();
} catch (InterruptedException e) {
log.error("server error", e);
} finally {
boss.shutdownGracefully();
worker.shutdownGracefully();
log.debug("stopped");
}
}
}
5.4.3、固定分隔符
-
Netty提供了两个固定分割符解码处理器
- 一个是换行符解码器LineBasedFrameDecoder，使用时需要传入一个最大解析长度，如果超过最大解析长度后，还没有找到换行符，就抛出TooLongFrameException
- 另一个是自定义分隔符解码器DelimiterBasedFrameDecoder
服务端加入，默认以 \n 或 \r\n 作为分隔符，如果超出指定长度仍未出现分隔符，则抛出异常
ch.pipeline().addLast(new LineBasedFrameDecoder(1024));
客户端在每条消息之后，加入 \n 分隔符
/**
* @author PengHuanZhi
* @date 2021年12月01日 17:30
*/
@Slf4j
public class SeparatorClient {
public static void main(String[] args) {
NioEventLoopGroup worker = new NioEventLoopGroup();
try {
Bootstrap bootstrap = new Bootstrap();
bootstrap.channel(NioSocketChannel.class);
bootstrap.group(worker);
bootstrap.handler(new ChannelInitializer<SocketChannel>() {
@Override
protected void initChannel(SocketChannel ch) throws Exception {
log.debug("connected...");
ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
@Override
public void channelActive(ChannelHandlerContext ctx) throws Exception {
log.debug("sending...");
ByteBuf buffer = ctx.alloc().buffer();
// 发送内容随机的数据包
Random r = new Random();
char c = 'a';
for (int i = 0; i < 10; i++) {
for (int j = 1; j <= r.nextInt(16) + 1; j++) {
buffer.writeByte((byte) c);
}
buffer.writeByte(10);
c++;
}
ctx.writeAndFlush(buffer);
}
});
}
});
ChannelFuture channelFuture = bootstrap.connect("127.0.0.1", 8080).sync();
channelFuture.channel().closeFuture().sync();
} catch (InterruptedException e) {
log.error("client error", e);
} finally {
worker.shutdownGracefully();
}
}
}
缺点，处理字符数据比较合适，但如果内容本身包含了分隔符（字节数据常常会有此情况），那么就会解析错误
5.4.4、预设长度
在发送消息前，先约定用定长字节表示接下来数据的长度，Netty提供了预设长度解码处理器LengthFieldBasedFrameDecoder，其中四个字段需要注意以下：
- lengthFieldOffset：长度字段偏移量
- lengthFieldLength：长度字段长度
- lengthAdjustment：长度字段为基准，还有几个字节是内容
- initialBytesToStrip：从头剥离几个字节
源码案例1：长度字段偏移为0，长度字段长度为2，也就是从头开始两个字节为长度，值为12，后续12个字节为数据内容
lengthFieldOffset = 0
lengthFieldLength = 2
lengthAdjustment = 0
initialBytesToStrip = 0 (= do not strip header)
BEFORE DECODE (14 bytes) AFTER DECODE (14 bytes)
+--------+----------------+ +--------+----------------+
| Length | Actual Content |----->| Length | Actual Content |
| 0x000C | "HELLO, WORLD" | | 0x000C | "HELLO, WORLD" |
+--------+----------------+ +--------+----------------+
源码案例2：也还是从头开始两个字节为长度，不同的是，服务端接收到了后，会自动剥离前面两个字节，解码后只剩下12个字节
lengthFieldOffset = 0
lengthFieldLength = 2
lengthAdjustment = 0
initialBytesToStrip = 2 (= the length of the Length field)
BEFORE DECODE (14 bytes) AFTER DECODE (12 bytes)
+--------+----------------+ +----------------+
| Length | Actual Content |----->| Actual Content |
| 0x000C | "HELLO, WORLD" | | "HELLO, WORLD" |
+--------+----------------+ +----------------+
源码案例3：在大多数的应用场景中，长度字段仅用来标识消息体的长度，这类协议通常由消息长度字段+消息体组成，如前面的几个例子。但是，对于某些协议，长度字段还包含了消息头的长度。在这种应用场景中，往往需要使用lengthAdjustment进行修正。由于整个消息（包含消息头）的长度往往大于消息体的长度，所以，lengthAdjustment为负数
lengthFieldOffset = 0
lengthFieldLength = 2
lengthAdjustment = -2 (= the length of the Length field)
initialBytesToStrip = 0
BEFORE DECODE (14 bytes) AFTER DECODE (14 bytes)
+--------+----------------+ +--------+----------------+
| Length | Actual Content |----->| Length | Actual Content |
| 0x000E | "HELLO, WORLD" | | 0x000E | "HELLO, WORLD" |
+--------+----------------+ +--------+----------------+
源码案例4：在有些情况下，我们的消息不止需要发送一个消息体长度和消息体，可能还需要附加一些内容，如下，这个Header实际上是叫魔数，后面协议会提到。所以这里长度字段偏移量为2，长度部分的长度为3
lengthFieldOffset = 2 (= the length of Header 1)
lengthFieldLength = 3
lengthAdjustment = 0
initialBytesToStrip = 0
BEFORE DECODE (17 bytes) AFTER DECODE (17 bytes)
+----------+----------+----------------+ +----------+----------+----------------+
| Header 1 | Length | Actual Content |----->| Header 1 | Length | Actual Content |
| 0xCAFE | 0x00000C | "HELLO, WORLD" | | 0xCAFE | 0x00000C | "HELLO, WORLD" |
+----------+----------+----------------+ +----------+----------+----------------+
源码案例5：在有些情况下，消息体长度内容和消息体中间可能会有一些其他信息，那么此时lengthAdjustment便表示长度体内容和真实消息体中间的偏移量
lengthFieldOffset = 0
lengthFieldLength = 3
lengthAdjustment = 2 (= the length of Header 1)
initialBytesToStrip = 0
BEFORE DECODE (17 bytes) AFTER DECODE (17 bytes)
+----------+----------+----------------+ +----------+----------+----------------+
| Length | Header 1 | Actual Content |----->| Length | Header 1 | Actual Content |
| 0x00000C | 0xCAFE | "HELLO, WORLD" | | 0x00000C | 0xCAFE | "HELLO, WORLD" |
+----------+----------+----------------+ +----------+----------+----------------+
源码案例6：消息体前方有一个字节的附加内容，真实长度内容从第二个字节开始，然后长度内容和真实内容之间偏移量为二，最后我们也许会想将前三个字节舍弃
lengthFieldOffset = 1 (= the length of HDR1)
lengthFieldLength = 2
lengthAdjustment = 1 (= the length of HDR2)
initialBytesToStrip = 3 (= the length of HDR1 + LEN)
BEFORE DECODE (16 bytes) AFTER DECODE (13 bytes)
+------+--------+------+----------------+ +------+----------------+
| HDR1 | Length | HDR2 | Actual Content |----->| HDR2 | Actual Content |
| 0xCA | 0x000C | 0xFE | "HELLO, WORLD" | | 0xFE | "HELLO, WORLD" |
+------+--------+------+----------------+ +------+----------------+
源码案例7：与前一个示例的唯一区别是，length字段表示整个消息的长度（16），而不是消息体的长度，就像第三个示例一样。我们必须将HDR1的长度和整个消息的长度计入长度调整。请注意，我们不需要考虑HDR2的长度，因为长度字段已经包括整个标头长度。
lengthFieldOffset = 1
lengthFieldLength = 2
lengthAdjustment = -3 (= the length of HDR1 + LEN, negative)
initialBytesToStrip = 3
BEFORE DECODE (16 bytes) AFTER DECODE (13 bytes)
+------+--------+------+----------------+ +------+----------------+
| HDR1 | Length | HDR2 | Actual Content |----->| HDR2 | Actual Content |
| 0xCA | 0x0010 | 0xFE | "HELLO, WORLD" | | 0xFE | "HELLO, WORLD" |
+------+--------+------+----------------+ +------+----------------+
- 测试：
/**
* @author PengHuanZhi
* @date 2021年12月01日 17:37
*/
@Slf4j
public class LengthFieldTest {
public static void main(String[] args) throws Exception {
EmbeddedChannel channel = new EmbeddedChannel(
//最大解析长度，长度偏移量，长度内容长度，内容修正长度，剥离非消息体内容长度
new LengthFieldBasedFrameDecoder(1024, 0, 4, 0, 4),
new LoggingHandler(LogLevel.DEBUG));
ByteBuf buf = ByteBufAllocator.DEFAULT.buffer();
send(buf, "Hello, World");
send(buf, "Hi!");
send(buf, "Haha");
send(buf, "Hello, World");
channel.writeInbound(buf);
}
private static void send(ByteBuf buf, String content) {
byte[] bytes = content.getBytes(Charset.defaultCharset());
int length = bytes.length;
//消息长度
buf.writeInt(length);
//消息体
buf.writeBytes(bytes);
}
}
6、协议的设计与解析
6.1、为什么需要协议？
TCP/IP 中消息传输基于流的方式，没有边界。
协议的目的就是划定消息的边界，制定通信双方要共同遵守的通信规则
例如：在网络上传输
下雨天留客天留我不留
-
是中文一句著名的无标点符号句子，在没有标点符号情况下，这句话有数种拆解方式，而意思却是完全不同，所以常被用作讲述标点符号的重要性
- 一种解读
下雨天留客，天留，我不留- 另一种解读
下雨天，留客天，留我不？留
如何设计协议呢？其实就是给网络传输的信息加上“标点符号”。但通过分隔符来断句不是很好，因为分隔符本身如果用于传输，那么必须加以区分。因此，下面一种协议较为常用
定长字节表示内容长度 + 实际内容
- 例如，假设一个中文字符长度为 3，按照上述协议的规则，发送信息方式如下，就不会被接收方弄错意思了
0f下雨天留客06天留09我不留
小故事
很久很久以前，一位私塾先生到一家任教。双方签订了一纸协议：“无鸡鸭亦可无鱼肉亦可白菜豆腐不可少不得束修金”。此后，私塾先生虽然认真教课，但主人家则总是给私塾先生以白菜豆腐为菜，丝毫未见鸡鸭鱼肉的款待。私塾先生先是很不解，可是后来也就想通了：主人把鸡鸭鱼肉的钱都会换为束修金的，也罢。至此双方相安无事。
年关将至，一个学年段亦告结束。私塾先生临行时，也不见主人家为他交付束修金，遂与主家理论。然主家亦振振有词：“有协议为证——无鸡鸭亦可，无鱼肉亦可，白菜豆腐不可少，不得束修金。这白纸黑字明摆着的，你有什么要说的呢？”
私塾先生据理力争：“协议是这样的——无鸡，鸭亦可；无鱼，肉亦可；白菜豆腐不可，少不得束修金。”
双方唇枪舌战，你来我往，真个是不亦乐乎！
这里的束修金，也作“束脩”，应当是泛指教师应当得到的报酬
6.2、Redis协议举例
一条很熟悉的命令
set name zhangsan，在Redis中，会将一个命令视为一个数组
- 它首先会要求你先发送当前数组的总长度，也就是元素有几个，即用***3**表示
- 接下来要求发送每个命令的长度和内容，set即：$3，然后再发送内容set
- 然后是name：先**$4**，然后再发送内容name
- 最后是zhangsan：先发送**$8**，最后是内容zhangsan
/**
* @author PengHuanZhi
* @date 2021年12月01日 20:42
*/
public class RedisProtocol {
public static void main(String[] args) throws Exception {
NioEventLoopGroup group = new NioEventLoopGroup();
/*
* ASCII码中，13表示回车，10表示换行
*/
final byte[] line = {13, 10};
ChannelFuture future = new Bootstrap()
.group(group)
.channel(NioSocketChannel.class)
.handler(new ChannelInitializer<NioSocketChannel>() {
@Override
protected void initChannel(NioSocketChannel ch) throws Exception {
ch.pipeline().addLast(new LoggingHandler(LogLevel.DEBUG));
ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
@Override
public void channelActive(ChannelHandlerContext ctx) throws Exception {
set(ctx);
get(ctx);
}
private void get(ChannelHandlerContext ctx) {
ByteBuf buf = ctx.alloc().buffer();
buf.writeBytes("*2".getBytes());
buf.writeBytes(line);
buf.writeBytes("$3".getBytes());
buf.writeBytes(line);
buf.writeBytes("get".getBytes());
buf.writeBytes(line);
buf.writeBytes("$3".getBytes());
buf.writeBytes(line);
buf.writeBytes("aaa".getBytes());
buf.writeBytes(line);
ctx.writeAndFlush(buf);
}
private void set(ChannelHandlerContext ctx) {
ByteBuf buf = ctx.alloc().buffer();
buf.writeBytes("*3".getBytes());
buf.writeBytes(line);
buf.writeBytes("$3".getBytes());
buf.writeBytes(line);
buf.writeBytes("set".getBytes());
buf.writeBytes(line);
buf.writeBytes("$3".getBytes());
buf.writeBytes(line);
buf.writeBytes("aaa".getBytes());
buf.writeBytes(line);
buf.writeBytes("$3".getBytes());
buf.writeBytes(line);
buf.writeBytes("bbb".getBytes());
buf.writeBytes(line);
ctx.writeAndFlush(buf);
}
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
ByteBuf buf = (ByteBuf) msg;
System.out.println(buf.toString(Charset.defaultCharset()));
}
});
}
})
.connect("127.0.0.1", 6379)
.sync();
future.channel().closeFuture().addListener(closeFuture -> {
group.shutdownGracefully();
});
}
}
6.3、Http协议举例
由于Http协议很复杂，我们可以使用Netty给我们提供好的处理器HttpServerCodec去处理
由于HttpServerCodec同时继承了编码解码处理器，所以我们处理Http请求的时候，只需要它一个就可以，
那HttpServerCodec解码后传递的数据到底是什么类型呢？我们使用浏览器访问
http://localhost:8080/index.html，将传递的数据打印一下
/**
* @author PengHuanZhi
* @date 2021年12月01日 20:53
*/
@Slf4j
public class HttpProtocol {
public static void main(String[] args) {
NioEventLoopGroup boss = new NioEventLoopGroup();
NioEventLoopGroup worker = new NioEventLoopGroup();
try {
ServerBootstrap serverBootstrap = new ServerBootstrap();
serverBootstrap.channel(NioServerSocketChannel.class);
serverBootstrap.group(boss, worker);
serverBootstrap.childHandler(new ChannelInitializer<SocketChannel>() {
@Override
protected void initChannel(SocketChannel ch) throws Exception {
ch.pipeline().addLast(new LoggingHandler(LogLevel.DEBUG));
ch.pipeline().addLast(new HttpServerCodec());
ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
log.debug("{}", msg.getClass());
}
});
}
});
ChannelFuture channelFuture = serverBootstrap.bind(8080).sync();
channelFuture.channel().closeFuture().sync();
} catch (InterruptedException e) {
log.error("server error", e);
} finally {
boss.shutdownGracefully();
worker.shutdownGracefully();
}
}
}
观察日志信息：
可以看到，我们的一个请求被解析成了一个请求行、请求头和请求体两部分，所以我们应该对其分别处理
if (msg instanceof HttpRequest) { // 请求行，请求头
} else if (msg instanceof HttpContent) { //请求体
}
当然我们如果只关心某一个消息，就可以使用SimpleChannelInboundHandler直接指定关心某一具体的消息类型：
/**
* @author PengHuanZhi
* @date 2021年12月01日 20:53
*/
@Slf4j
public class HttpProtocol {
public static void main(String[] args) {
NioEventLoopGroup boss = new NioEventLoopGroup();
NioEventLoopGroup worker = new NioEventLoopGroup();
try {
ServerBootstrap serverBootstrap = new ServerBootstrap();
serverBootstrap.channel(NioServerSocketChannel.class);
serverBootstrap.group(boss, worker);
serverBootstrap.childHandler(new ChannelInitializer<SocketChannel>() {
@Override
protected void initChannel(SocketChannel ch) throws Exception {
ch.pipeline().addLast(new LoggingHandler(LogLevel.DEBUG));
ch.pipeline().addLast(new HttpServerCodec());
ch.pipeline().addLast(new SimpleChannelInboundHandler<HttpRequest>() {
@Override
protected void channelRead0(ChannelHandlerContext ctx, HttpRequest msg) throws Exception {
// 获取请求
log.debug(msg.uri());
// 返回响应
DefaultFullHttpResponse response =
new DefaultFullHttpResponse(msg.protocolVersion(), HttpResponseStatus.OK);
byte[] bytes = "<h1>Hello, world!</h1>".getBytes();
response.headers().setInt(CONTENT_LENGTH, bytes.length);
response.content().writeBytes(bytes);
// 写回响应
ctx.writeAndFlush(response);
}
});
}
});
ChannelFuture channelFuture = serverBootstrap.bind(8080).sync();
channelFuture.channel().closeFuture().sync();
} catch (InterruptedException e) {
log.error("server error", e);
} finally {
boss.shutdownGracefully();
worker.shutdownGracefully();
}
}
}
再次访问
http://localhost:8080/index.html
6.4、自定义协议需要考虑的要素
- 魔数：用来在第一时间判定是否是无效数据包
- 版本号：可以支持协议的升级，比如会新增一些消息，需要加以区分
- 序列化算法：消息正文到底采用哪种序列化反序列化方式，可以由此扩展，例如：json、protobuf（谷歌出品）、hessian、jdk（不能跨平台，效率不高，有安全漏洞），对象流
- 指令类型：是登录、注册、单聊、群聊… 跟业务相关
- 请求序号：为了双工通信，提供异步能力
- 正文长度
- 消息正文
6.4.1、自定义编解码器的实现
了解了Netty对Http协议的实现后，自然而然的就能想到，自定义协议也是需要根据我们自己的协议去实现相应的编解码器，所以依据自定义协议所需要的一些要素，我们约定：
- 魔数占用4字节
- 版本号占用1字节
- 序列化算法占用1字节
- 指令类型占用1字节
- 请求序号占用4字节
- 长度占用4字节
- 最后是消息正文
算一算，非正文的数据长度为15字节，但是一般的网络传输中固定的字节数，最好都是2的整数倍，所以为了让消息对齐，我们可以认为添加一个填充字节
- 填充字节占用1字节，位置可以在任何位置，这里夹在请求序号和长度之间
由于将来我们需要将我们自定义的消息与ByteBuf之间互相转换，所以我们可以继承Netty提供的ByteToMessageCodec，继承后就需要分别实现编码和解码方法
/**
* @author PengHuanZhi
* @date 2021年12月02日 18:59
*/
@Slf4j
public class MessageCodec extends ByteToMessageCodec<Message> {
@Override
protected void encode(ChannelHandlerContext ctx, Message msg, ByteBuf out) throws Exception {
}
@Override
protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
}
}
其中Message为我们自定义的消息类型，定义如下：
/**
* @author PengHuanZhi
* @date 2021/12/2 9:53
*/
@Data
public abstract class Message implements Serializable {
/**
* 根据消息类型字节，获得对应的消息 class
*
* @param messageType 消息类型字节
* @return 消息 class
*/
public static Class<? extends Message> getMessageClass(int messageType) {
return MESSAGE_CLASSES.get(messageType);
}
/**
* 请求序号
*/
private int sequenceId;
/**
* 消息类型
*/
private int messageType;
/**
* 获取消息的类型
*/
public abstract int getMessageType();
/**
* 登录请求消息类型
*/
public static final int LOGIN_REQUEST_MESSAGE = 0;
/**
* 登录响应消息类型
*/
public static final int LOGIN_RESPONSE_MESSAGE = 1;
/**
* 聊天请求消息类型
*/
public static final int CHAT_REQUEST_MESSAGE = 2;
/**
* 聊天响应响应消息类型
*/
public static final int CHAT_RESPONSE_MESSAGE = 3;
/**
* 创建群组请求消息类型
*/
public static final int GROUP_CREATE_REQUEST_MESSAGE = 4;
/**
* 创建群组响应消息类型
*/
public static final int GROUP_CREATE_RESPONSE_MESSAGE = 5;
/**
* 加入群组请求消息类型
*/
public static final int GROUP_JOIN_REQUEST_MESSAGE = 6;
/**
* 加入群组响应消息类型
*/
public static final int GROUP_JOIN_RESPONSE_MESSAGE = 7;
/**
* 退出群组请求消息类型
*/
public static final int GROUP_QUIT_REQUEST_MESSAGE = 8;
/**
* 退出群组响应消息类型
*/
public static final int GROUP_QUIT_RESPONSE_MESSAGE = 9;
/**
* 群聊请求消息类型
*/
public static final int GROUP_CHAT_REQUEST_MESSAGE = 10;
/**
* 群聊响应消息类型
*/
public static final int GROUP_CHAT_RESPONSE_MESSAGE = 11;
/**
* 获取群组成员请求消息类型
*/
public static final int GROUP_MEMBERS_REQUEST_MESSAGE = 12;
/**
* 获取群组成员响应消息类型
*/
public static final int GROUP_MEMBERS_RESPONSE_MESSAGE = 13;
/**
* Ping消息类型
*/
public static final int PING_MESSAGE = 14;
/**
* Pong消息类型
*/
public static final int PONG_MESSAGE = 15;
/**
* 消息类型对应Java类的集合
*/
private static final Map<Integer, Class<? extends Message>> MESSAGE_CLASSES = new HashMap<>();
/*
* 初始化所有的消息类到集合中
*/
static {
MESSAGE_CLASSES.put(LOGIN_REQUEST_MESSAGE, LoginRequestMessage.class);
MESSAGE_CLASSES.put(LOGIN_RESPONSE_MESSAGE, LoginResponseMessage.class);
MESSAGE_CLASSES.put(CHAT_REQUEST_MESSAGE, ChatRequestMessage.class);
MESSAGE_CLASSES.put(CHAT_RESPONSE_MESSAGE, ChatResponseMessage.class);
MESSAGE_CLASSES.put(GROUP_CREATE_REQUEST_MESSAGE, GroupCreateRequestMessage.class);
MESSAGE_CLASSES.put(GROUP_CREATE_RESPONSE_MESSAGE, GroupCreateResponseMessage.class);
MESSAGE_CLASSES.put(GROUP_JOIN_REQUEST_MESSAGE, GroupJoinRequestMessage.class);
MESSAGE_CLASSES.put(GROUP_JOIN_RESPONSE_MESSAGE, GroupJoinResponseMessage.class);
MESSAGE_CLASSES.put(GROUP_QUIT_REQUEST_MESSAGE, GroupQuitRequestMessage.class);
MESSAGE_CLASSES.put(GROUP_QUIT_RESPONSE_MESSAGE, GroupQuitResponseMessage.class);
MESSAGE_CLASSES.put(GROUP_CHAT_REQUEST_MESSAGE, GroupChatRequestMessage.class);
MESSAGE_CLASSES.put(GROUP_CHAT_RESPONSE_MESSAGE, GroupChatResponseMessage.class);
MESSAGE_CLASSES.put(GROUP_MEMBERS_REQUEST_MESSAGE, GroupMembersRequestMessage.class);
MESSAGE_CLASSES.put(GROUP_MEMBERS_RESPONSE_MESSAGE, GroupMembersResponseMessage.class);
}
}
本文后面会做一个聊天业务的Demo，所以这边预先定义好了若干消息类型，它们都是Message对象的子类，这里不展开说了，重点先关注协议的编解码，具体的消息在后面用到了再说
- 编码：
@Override
public void encode(ChannelHandlerContext ctx, Message msg, ByteBuf out) throws Exception {
// 1. 4 字节的魔数
out.writeBytes(new byte[]{1, 2, 3, 4});
// 2. 1 字节的版本号
out.writeByte(1);
// 3. 1 字节的序列化算法 jdk 0 , json 1
out.writeByte(0);
// 4. 1 字节的指令类型
out.writeByte(msg.getMessageType());
// 5. 4 个字节的请求序号
out.writeInt(msg.getSequenceId());
// 无意义，对齐填充
out.writeByte(0xff);
// 6. 获取内容的字节数组
ByteArrayOutputStream bos = new ByteArrayOutputStream();
ObjectOutputStream oos = new ObjectOutputStream(bos);
oos.writeObject(msg);
byte[] bytes = bos.toByteArray();
// 7. 长度
out.writeInt(bytes.length);
// 8. 写入内容
out.writeBytes(bytes);
}
- 解码：
@Override
public void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
// 1. 4 字节的魔数
int magicNum = in.readInt();
// 2. 1 字节的版本号
byte version = in.readByte();
// 3. 1 字节的序列化算法 jdk 0 , json 1
byte serializerType = in.readByte();
// 4. 1 字节的指令类型
byte messageType = in.readByte();
// 5. 4 个字节的请求序号
int sequenceId = in.readInt();
// 无意义，对齐填充
in.readByte();
// 7. 长度
int length = in.readInt();
// 8. 读取内容
byte[] bytes = new byte[length];
in.readBytes(bytes, 0, length);
if (serializerType == 0) {
ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(bytes));
Message message = (Message) ois.readObject();
log.debug("{}, {}, {}, {}, {}, {}", magicNum, version, serializerType, messageType, sequenceId, length);
log.debug("{}", message);
//Netty规定解码出的消息需要放到List<Object>集合中，传递给下一个Handler
out.add(message);
}
}
- 测试：
public static void main(String[] args) throws Exception {
EmbeddedChannel channel = new EmbeddedChannel(
new LoggingHandler(),
new MessageCodec()
);
// 编码
LoginRequestMessage message = new LoginRequestMessage("zhangsan", "123", "张三");
channel.writeOutbound(message);
// 解码
ByteBuf buf = ByteBufAllocator.DEFAULT.buffer();
new MessageCodec().encode(null, message, buf);
channel.writeInbound(buf);
}
6.4.2、粘包半包现象
我们将原始Buf切片为一个100长度的Buf，然后解码，观察控制台
/**
* @author PengHuanZhi
* @date 2021年12月02日 19:30
*/
public class TestMessageCodec {
public static void main(String[] args) throws Exception {
EmbeddedChannel channel = new EmbeddedChannel(
new LoggingHandler(),
new MessageCodec()
);
// encode
LoginRequestMessage message = new LoginRequestMessage("zhangsan", "123", "张三");
// decode
ByteBuf buf = ByteBufAllocator.DEFAULT.buffer();
new MessageCodec().encode(null, message, buf);
ByteBuf s1 = buf.slice(0, 100);
channel.writeInbound(s1);
}
}
如何解决呢，这是就需要用到前面提到的帧解码器LengthFieldBasedFrameDecoder了
EmbeddedChannel channel = new EmbeddedChannel(
new LengthFieldBasedFrameDecoder(1024, 12, 4, 0, 0),
new LoggingHandler(),
new MessageCodec()
);
可以看见，LoggingHandler直接就没有执行了，因为帧解码器发现当前消息还不完整，就不会向下传递了，只能将数据补充完整，才能继续向下传递
将消息补充完整，再次测试：
注意，channel在writeInbound一个s1后，会调用s1的release方法，由于我们使用的是基于零拷贝的slice方法，s1和原始buf共用一块内存，所以如果s1做了release后，s2操作的将是一个无效的buf，所以在channel执行writeInbound方法后需要调用一次s1的retain方法，防止buf被release
/**
* @author PengHuanZhi
* @date 2021年12月02日 19:30
*/
public class TestMessageCodec {
public static void main(String[] args) throws Exception {
EmbeddedChannel channel = new EmbeddedChannel(
new LengthFieldBasedFrameDecoder(1024, 12, 4, 0, 0),
new LoggingHandler(),
new MessageCodec()
);
// encode
LoginRequestMessage message = new LoginRequestMessage("zhangsan", "123", "张三");
// decode
ByteBuf buf = ByteBufAllocator.DEFAULT.buffer();
new MessageCodec().encode(null, message, buf);
ByteBuf s1 = buf.slice(0, 100);
ByteBuf s2 = buf.slice(100, buf.readableBytes() - 100);
// 引用计数 2
s1.retain();
// release 1
channel.writeInbound(s1);
log.debug("wait...");
Thread.sleep(1000);
channel.writeInbound(s2);
}
}
6.4.3、@Sharable的作用
回顾之前做的所有案例，我们为每一个Channel都创建了属于他们自己的若干Handler，那么我们可不可以只定义一次Handler，然后所有的Channel都去使用呢？
答案是不完全可以，对于一些线程安全的处理器，我们是可以这样做的，但是对于一些线程不安全的处理器，它就不能够被所有Channel共享。
那么何为线程安全的处理器呢？即Handler不能保存数据状态，如日志Handler，它只起到记录日志的目的，每一次消息来了，直接打印后就传递下去了，它是可以共享的，但是对于像帧编解码器而言，一次消息到达后，如果这个消息还不完整，那么当前消息还会被暂存起来，如果此时另一个实例的消息到达，那么它会被追加到前面暂存的消息中，这样显然是不合理的。
Netty为我们提供了一个**@Sharable注解，它可以用于标识当前Handler是否可以被共享，就像上面这个问题所描述的那样，我们对比一下LoggingHandler和LengthFieldBasedFrameDecoder**：
那么再思考一个问题，我们这里自定义的消息编解码器MessageCodec是否可以被共享呢？
答案是可以的，因为在我们的业务中，它收到的消息已经被粘包半包解码器打包好了传递过来的，且代码中并没有对数据进行保存，所以它是一个线程安全的处理器，所以我们给其加上一个Sharable注解
@ChannelHandler.Sharable
public class MessageCodec extends ByteToMessageCodec<Message> {
然后测试一下
/**
* @author PengHuanZhi
* @date 2021年12月02日 20:25
*/
@Slf4j
public class ChatServer {
public static void main(String[] args) {
NioEventLoopGroup boss = new NioEventLoopGroup();
NioEventLoopGroup worker = new NioEventLoopGroup();
LoggingHandler loggingHandler = new LoggingHandler(LogLevel.DEBUG);
MessageCodec messageCodec = new MessageCodec();
try {
ChannelFuture channelFuture = new ServerBootstrap()
.group(boss, worker)
.channel(NioServerSocketChannel.class)
.childHandler(new ChannelInitializer<SocketChannel>() {
@Override
protected void initChannel(SocketChannel ch) throws Exception {
ch.pipeline().addLast(new LengthFieldBasedFrameDecoder(1024, 12, 4, 0, 0));
ch.pipeline().addLast(loggingHandler);
ch.pipeline().addLast(messageCodec);
}
}).bind(8080).sync();
channelFuture.channel().closeFuture().sync();
} catch (Exception e) {
log.error("server error", e);
} finally {
boss.shutdownGracefully();
worker.shutdownGracefully();
}
}
}
启动后观察控制台
奇怪了哈，为什么报错信息提示我们MessageCodec不支持共享呢？
原因在MessageCodec的父类ByteToMessageCodec中：
原来它限制了其子类不能被标识为一个共享Handler，那么我们的MessageCodec本身就可以作为共享的，如何才能不让他报这个错呢？我们可以改变其继承关系，重新继承于一个新的对象MessageToMessageCodec，它必须和 LengthFieldBasedFrameDecoder 一起使用，确保接到的 ByteBuf 消息是完整的
/**
* @author PengHuanZhi
* @date 2021年12月02日 20:35
*/
@Slf4j
public class MessageCodecSharable extends MessageToMessageCodec<ByteBuf, Message> {
@Override
protected void encode(ChannelHandlerContext ctx, Message msg, List<Object> outList) throws Exception {
ByteBuf out = ctx.alloc().buffer();
//...
outList.add(out);
}
@Override
protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
//...
}
}
7、聊天室案例
7.1、业务介绍
7.1.1、用户管理
处理用户登录的接口
/**
* 用户管理接口
*
* @author PengHuanZhi
* @date 2021年12月02日 20:52
*/
public interface UserService {
/**
* 登录
*
* @param username 用户名
* @param password 密码
* @return 登录成功返回 true, 否则返回 false
*/
boolean login(String username, String password);
}
给定一个实现，简单起见，就不和数据库交互了
/**
* @author PengHuanZhi
* @date 2021年12月02日 20:54
*/
public class UserServiceImpl implements UserService {
private final Map<String, String> allUserMap = new ConcurrentHashMap<>();
{
allUserMap.put("zhangsan", "123");
allUserMap.put("lisi", "123");
allUserMap.put("wangwu", "123");
allUserMap.put("zhaoliu", "123");
allUserMap.put("qianqi", "123");
}
@Override
public boolean login(String username, String password) {
String pass = allUserMap.get(username);
if (pass == null) {
return false;
}
return pass.equals(password);
}
}
给定一个单例工厂
/**
* @author PengHuanZhi
* @date 2021年12月03日 9:57
*/
public class UserServiceFactory {
private static final UserServiceImpl USER_SERVICE = new UserServiceImpl();
public static UserServiceImpl getUserService() {
return USER_SERVICE;
}
}
7.1.2、会话管理
用户登陆上来后，需要聊天，给定一个处理会话管理的接口
/**
* 会话管理接口
*
* @author PengHuanZhi
* @date 2021年12月02日 20:55
*/
public interface Session {
/**
* 绑定会话
*
* @param channel 哪个 channel 要绑定会话
* @param username 会话绑定用户
*/
void bind(Channel channel, String username);
/**
* 解绑会话
*
* @param channel 哪个 channel 要解绑会话
*/
void unbind(Channel channel);
/**
* 获取属性
*
* @param channel 哪个 channel
* @param name 属性名
* @return 属性值
*/
Object getAttribute(Channel channel, String name);
/**
* 设置属性
*
* @param channel 哪个 channel
* @param name 属性名
* @param value 属性值
*/
void setAttribute(Channel channel, String name, Object value);
/**
* 根据用户名获取 channel
*
* @param username 用户名
* @return channel
*/
Channel getChannel(String username);
}
Session的实现
/**
* @author PengHuanZhi
* @date 2021年12月02日 20:57
*/
public class SessionImpl implements Session {
/**
* 用户对应Channel缓存集合
*/
private final Map<String, Channel> usernameChannelMap = new ConcurrentHashMap<>();
/**
* Channel对应用户缓存集合
*/
private final Map<Channel, String> channelUsernameMap = new ConcurrentHashMap<>();
/**
* Channel中保存的参数缓存集合
*/
private final Map<Channel, Map<String, Object>> channelAttributesMap = new ConcurrentHashMap<>();
@Override
public void bind(Channel channel, String username) {
usernameChannelMap.put(username, channel);
channelUsernameMap.put(channel, username);
channelAttributesMap.put(channel, new ConcurrentHashMap<>());
}
@Override
public void unbind(Channel channel) {
String username = channelUsernameMap.remove(channel);
usernameChannelMap.remove(username);
channelAttributesMap.remove(channel);
}
@Override
public Object getAttribute(Channel channel, String name) {
return channelAttributesMap.get(channel).get(name);
}
@Override
public void setAttribute(Channel channel, String name, Object value) {
channelAttributesMap.get(channel).put(name, value);
}
@Override
public Channel getChannel(String username) {
return usernameChannelMap.get(username);
}
@Override
public String toString() {
return usernameChannelMap.toString();
}
}
SessionImpl单例工厂
/**
* @author PengHuanZhi
* @date 2021年12月02日 21:04
*/
public abstract class SessionFactory {
private static final Session SESSION = new SessionImpl();
public static Session getSession() {
return SESSION;
}
}
7.1.3、会话组管理（聊天室）
聊天室对象
/**
* 聊天组，即聊天室
*
* @author PengHuanZhi
* @date 2021年12月02日 21:01
*/
@Data
public class Group {
/**
* 聊天室名称
*/
private String name;
/**
* 聊天室成员
*/
private Set<String> members;
public static final Group EMPTY_GROUP = new Group("empty", Collections.emptySet());
public Group(String name, Set<String> members) {
this.name = name;
this.members = members;
}
}
聊天室会话接口
/**
* 聊天组会话管理接口
*
* @author PengHuanZhi
* @date 2021年12月02日 21:01
*/
public interface GroupSession {
/**
* 创建一个聊天组, 如果不存在才能创建成功, 否则返回 null
*
* @param name 组名
* @param members 成员
* @return 成功时返回组对象, 失败返回 null
*/
Group createGroup(String name, Set<String> members);
/**
* 加入聊天组
*
* @param name 组名
* @param member 成员名
* @return 如果组不存在返回 null, 否则返回组对象
*/
Group joinMember(String name, String member);
/**
* 移除组成员
*
* @param name 组名
* @param member 成员名
* @return 如果组不存在返回 null, 否则返回组对象
*/
Group removeMember(String name, String member);
/**
* 移除聊天组
*
* @param name 组名
* @return 如果组不存在返回 null, 否则返回组对象
*/
Group removeGroup(String name);
/**
* 获取组成员
*
* @param name 组名
* @return 成员集合, 如果群不存在或没有成员会返回 empty set
*/
Set<String> getMembers(String name);
/**
* 获取组成员的 channel 集合, 只有在线的 channel 才会返回
*
* @param name 组名
* @return 成员 channel 集合
*/
List<Channel> getMembersChannel(String name);
}
对应实现
/**
* @author PengHuanZhi
* @date 2021年12月02日 21:03
*/
public class GroupSessionImpl implements GroupSession {
/**
* 根据聊天室名称缓存聊天室
*/
private final Map<String, Group> groupMap = new ConcurrentHashMap<>();
@Override
public Group createGroup(String name, Set<String> members) {
Group group = new Group(name, members);
return groupMap.putIfAbsent(name, group);
}
@Override
public Group joinMember(String name, String member) {
return groupMap.computeIfPresent(name, (key, value) -> {
value.getMembers().add(member);
return value;
});
}
@Override
public Group removeMember(String name, String member) {
return groupMap.computeIfPresent(name, (key, value) -> {
value.getMembers().remove(member);
return value;
});
}
@Override
public Group removeGroup(String name) {
return groupMap.remove(name);
}
@Override
public Set<String> getMembers(String name) {
return groupMap.getOrDefault(name, Group.EMPTY_GROUP).getMembers();
}
@Override
public List<Channel> getMembersChannel(String name) {
return getMembers(name).stream()
.map(member -> SessionFactory.getSession().getChannel(member))
.filter(Objects::nonNull)
.collect(Collectors.toList());
}
}
聊天GroupSessionImpl单例工厂
/**
* @author PengHuanZhi
* @date 2021年12月02日 21:08
*/
public abstract class GroupSessionFactory {
private static GroupSession SESSION = new GroupSessionImpl();
public static GroupSession getGroupSession() {
return SESSION;
}
}
7.1.4、帧解码器的封装
由于我们定义好的协议是不会再修改的，所以我们将创建帧解码器的过程简化一下，这样下次创建这个处理器的时候就不用再传入那么多的参数了
public class ProtocolFrameDecoder extends LengthFieldBasedFrameDecoder {
public ProtocolFrameDecoder() {
this(1024, 12, 4, 0, 0);
}
public ProtocolFrameDecoder(int maxFrameLength, int lengthFieldOffset, int lengthFieldLength, int lengthAdjustment, int initialBytesToStrip) {
super(maxFrameLength, lengthFieldOffset, lengthFieldLength, lengthAdjustment, initialBytesToStrip);
}
}
7.1.5、各个消息封装
/**
* @author PengHuanZhi
* @date 2021/12/2 9:53
*/
@Data
@ToString(callSuper = true)
@EqualsAndHashCode(callSuper = true)
public abstract class AbstractResponseMessage extends Message {
private boolean success;
private String reason;
public AbstractResponseMessage() {
}
public AbstractResponseMessage(boolean success, String reason) {
this.success = success;
this.reason = reason;
}
}
/**
* @author PengHuanZhi
* @date 2021/12/2 9:53
*/
@Data
@ToString(callSuper = true)
@EqualsAndHashCode(callSuper = true)
public class ChatRequestMessage extends Message {
private String content;
private String to;
private String from;
public ChatRequestMessage() {
}
public ChatRequestMessage(String from, String to, String content) {
this.from = from;
this.to = to;
this.content = content;
}
@Override
public int getMessageType() {
return CHAT_REQUEST_MESSAGE;
}
}
/**
* @author PengHuanZhi
* @date 2021/12/2 9:53
*/
@Data
@ToString(callSuper = true)
@EqualsAndHashCode(callSuper = true)
public class ChatResponseMessage extends AbstractResponseMessage {
private String from;
private String content;
public ChatResponseMessage(boolean success, String reason) {
super(success, reason);
}
public ChatResponseMessage(String from, String content) {
this.from = from;
this.content = content;
}
@Override
public int getMessageType() {
return CHAT_RESPONSE_MESSAGE;
}
}
/**
* @author PengHuanZhi
* @date 2021/12/2 9:53
*/
@Data
@ToString(callSuper = true)
@EqualsAndHashCode(callSuper = true)
public class GroupChatRequestMessage extends Message {
private String content;
private String groupName;
private String from;
public GroupChatRequestMessage(String from, String groupName, String content) {
this.content = content;
this.groupName = groupName;
this.from = from;
}
@Override
public int getMessageType() {
return GROUP_CHAT_REQUEST_MESSAGE;
}
}
/**
* @author PengHuanZhi
* @date 2021/12/2 9:53
*/
@Data
@ToString(callSuper = true)
@EqualsAndHashCode(callSuper = true)
public class GroupChatResponseMessage extends AbstractResponseMessage {
private String from;
private String content;
public GroupChatResponseMessage(boolean success, String reason) {
super(success, reason);
}
public GroupChatResponseMessage(String from, String content) {
this.from = from;
this.content = content;
}
@Override
public int getMessageType() {
return GROUP_CHAT_RESPONSE_MESSAGE;
}
}
/**
* @author PengHuanZhi
* @date 2021/12/2 9:53
*/
@Data
@ToString(callSuper = true)
@EqualsAndHashCode(callSuper = true)
public class GroupCreateRequestMessage extends Message {
private String groupName;
private Set<String> members;
public GroupCreateRequestMessage(String groupName, Set<String> members) {
this.groupName = groupName;
this.members = members;
}
@Override
public int getMessageType() {
return GROUP_CREATE_REQUEST_MESSAGE;
}
}
/**
* @author PengHuanZhi
* @date 2021/12/2 9:53
*/
@Data
@ToString(callSuper = true)
@EqualsAndHashCode(callSuper = true)
public class GroupCreateResponseMessage extends AbstractResponseMessage {
public GroupCreateResponseMessage(boolean success, String reason) {
super(success, reason);
}
@Override
public int getMessageType() {
return GROUP_CREATE_RESPONSE_MESSAGE;
}
}
/**
* @author PengHuanZhi
* @date 2021/12/2 9:53
*/
@Data
@ToString(callSuper = true)
@EqualsAndHashCode(callSuper = true)
public class GroupJoinRequestMessage extends Message {
private String groupName;
private String username;
public GroupJoinRequestMessage(String username, String groupName) {
this.groupName = groupName;
this.username = username;
}
@Override
public int getMessageType() {
return GROUP_JOIN_REQUEST_MESSAGE;
}
}
/**
* @author PengHuanZhi
* @date 2021/12/2 9:53
*/
@Data
@ToString(callSuper = true)
@EqualsAndHashCode(callSuper = true)
public class GroupJoinResponseMessage extends AbstractResponseMessage {
public GroupJoinResponseMessage(boolean success, String reason) {
super(success, reason);
}
@Override
public int getMessageType() {
return GROUP_JOIN_RESPONSE_MESSAGE;
}
}
/**
* @author PengHuanZhi
* @date 2021/12/2 9:53
*/
@Data
@ToString(callSuper = true)
@EqualsAndHashCode(callSuper = true)
public class GroupMembersRequestMessage extends Message {
private String groupName;
public GroupMembersRequestMessage(String groupName) {
this.groupName = groupName;
}
@Override
public int getMessageType() {
return GROUP_MEMBERS_REQUEST_MESSAGE;
}
}
/**
* @author PengHuanZhi
* @date 2021/12/2 9:53
*/
@Data
@ToString(callSuper = true)
@EqualsAndHashCode(callSuper = true)
public class GroupMembersResponseMessage extends Message {
private Set<String> members;
public GroupMembersResponseMessage(Set<String> members) {
this.members = members;
}
@Override
public int getMessageType() {
return GROUP_MEMBERS_RESPONSE_MESSAGE;
}
}
/**
* @author PengHuanZhi
* @date 2021/12/2 9:53
*/
@Data
@ToString(callSuper = true)
@EqualsAndHashCode(callSuper = true)
public class GroupQuitRequestMessage extends Message {
private String groupName;
private String username;
public GroupQuitRequestMessage(String username, String groupName) {
this.groupName = groupName;
this.username = username;
}
@Override
public int getMessageType() {
return GROUP_QUIT_REQUEST_MESSAGE;
}
}
/**
* @author PengHuanZhi
* @date 2021/12/2 9:53
*/
@Data
@ToString(callSuper = true)
@EqualsAndHashCode(callSuper = true)
public class GroupQuitResponseMessage extends AbstractResponseMessage {
public GroupQuitResponseMessage(boolean success, String reason) {
super(success, reason);
}
@Override
public int getMessageType() {
return GROUP_QUIT_RESPONSE_MESSAGE;
}
}
/**
* @author PengHuanZhi
* @date 2021/12/2 9:53
*/
@Data
@ToString(callSuper = true)
@EqualsAndHashCode(callSuper = true)
public class LoginRequestMessage extends Message {
private String username;
private String password;
public LoginRequestMessage() {
}
public LoginRequestMessage(String username, String password) {
this.username = username;
this.password = password;
}
@Override
public int getMessageType() {
return LOGIN_REQUEST_MESSAGE;
}
}
/**
* @author PengHuanZhi
* @date 2021/12/2 9:53
*/
@Data
@ToString(callSuper = true)
@EqualsAndHashCode(callSuper = true)
public class LoginResponseMessage extends AbstractResponseMessage {
public LoginResponseMessage(boolean success, String reason) {
super(success, reason);
}
@Override
public int getMessageType() {
return LOGIN_RESPONSE_MESSAGE;
}
}
7.2、包结构介绍
7.3、登录功能实现
客户端，需要注意的是，我们用户会话的线程是我们自己创建的，而处理和服务端连接相关的线程是Netty提供的Nio线程，两个线程之间的通信有很多种，这里适用CountDownLatch计数器
/**
* @author PengHuanZhi
* @date 2021年12月02日 21:11
*/
@Slf4j
public class ChatClient {
public static void main(String[] args) throws Exception {
NioEventLoopGroup group = new NioEventLoopGroup();
LoggingHandler loggingHandler = new LoggingHandler(LogLevel.DEBUG);
MessageCodecSharable MessageCodecSharable = new MessageCodecSharable();
//用来协调两个线程之间的协作
CountDownLatch loginWait = new CountDownLatch(1);
//记录当前是否处于登录状态
AtomicBoolean isLogin = new AtomicBoolean(false);
try {
Bootstrap bootstrap = new Bootstrap();
bootstrap.channel(NioSocketChannel.class);
bootstrap.group(group);
bootstrap.handler(new ChannelInitializer<SocketChannel>() {
@Override
protected void initChannel(SocketChannel ch) {
ch.pipeline().addLast(new ProtocolFrameDecoder());
ch.pipeline().addLast(loggingHandler);
ch.pipeline().addLast(MessageCodecSharable);
ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
/**
* 1、客户端首先处理的是用户登录的请求
*/
@Override
public void channelActive(ChannelHandlerContext ctx) {
//显示创建线程池
ExecutorService pool = new ThreadPoolExecutor(Runtime.getRuntime().availableProcessors(), 200,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue<>(1024), Executors.defaultThreadFactory(), new ThreadPoolExecutor.AbortPolicy());
pool.submit(() -> {
Scanner scanner = new Scanner(System.in);
System.out.println("请输入用户名：");
String userName = scanner.nextLine();
System.out.println("请输入密码：");
String password = scanner.nextLine();
//构造消息对象
LoginRequestMessage message = new LoginRequestMessage(userName, password);
ctx.channel().writeAndFlush(message);
System.out.println("正在登录...请稍后");
try {
loginWait.await();
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("收到服务器响应");
if (isLogin.get()) {
System.out.println("登录成功");
while (true) {
System.out.println("==================================");
System.out.println("send [username] [content]");
System.out.println("gSend [group name] [content]");
System.out.println("gCreate [group name] [m1,m2,m3...]");
System.out.println("gMembers [group name]");
System.out.println("gJoin [group name]");
System.out.println("gQuit [group name]");
System.out.println("quit");
System.out.println("==================================");
}
} else {
System.out.println("登录失败");
ctx.channel().close();
}
});
}
/**
* 2、然后才是处理服务器返回的消息
*/
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) {
//当前处理Read事件的线程为Nio中的线程，和上面用户登录的线程不一致，需要做一下两个线程之间的通信
if (msg instanceof LoginResponseMessage) {
LoginResponseMessage response = (LoginResponseMessage) msg;
if (response.isSuccess()) {
isLogin.set(true);
}
//无论登录成功或者失败都应该唤醒登录线程
loginWait.countDown();
}
}
});
}
});
Channel channel = bootstrap.connect("127.0.0.1", 8080).sync().channel();
channel.closeFuture().sync();
} catch (Exception e) {
log.error("client error", e);
} finally {
group.shutdownGracefully();
}
}
}
由于我们服务端需要处理的消息类型比较多，所以我们为每一种消息类型都创建一个对应的处理器，全部写进当前类中显得代码比较臃肿，所以我们将其抽取出来，首先是登录消息处理器：
/**
* @author PengHuanZhi
* @date 2021年12月03日 12:28
*/
@ChannelHandler.Sharable
public class LoginRequestHandler extends SimpleChannelInboundHandler<LoginRequestMessage> {
@Override
protected void channelRead0(ChannelHandlerContext ctx, LoginRequestMessage msg) {
String userName = msg.getUsername();
String password = msg.getPassword();
UserServiceImpl userService = UserServiceFactory.getUserService();
boolean login = userService.login(userName, password);
LoginResponseMessage message;
if (login) {
message = new LoginResponseMessage(true, "登录成功");
//绑定登录用户
SessionFactory.getSession().bind(ctx.channel(), userName);
} else {
message = new LoginResponseMessage(false, "用户名或密码错误");
}
ctx.channel().writeAndFlush(message);
}
}
}
然后使用登录请求处理器：
/**
* @author PengHuanZhi
* @date 2021年12月02日 21:12
*/
@Slf4j
public class ChatServer {
public static void main(String[] args) {
NioEventLoopGroup boss = new NioEventLoopGroup();
NioEventLoopGroup worker = new NioEventLoopGroup();
LoggingHandler loggingHandler = new LoggingHandler(LogLevel.DEBUG);
MessageCodecSharable MessageCodecSharable = new MessageCodecSharable();
final LoginRequestHandler loginRequestHandler = new LoginRequestHandler();
try {
Channel channel = new ServerBootstrap()
.channel(NioServerSocketChannel.class)
.group(boss, worker)
.childHandler(new ChannelInitializer<SocketChannel>() {
@Override
protected void initChannel(SocketChannel ch) throws Exception {
ch.pipeline().addLast(new ProtocolFrameDecoder());
ch.pipeline().addLast(loggingHandler);
ch.pipeline().addLast(MessageCodecSharable);
ch.pipeline().addLast(loginRequestHandler);
}
}).bind(8080).sync().channel();
channel.closeFuture().sync();
} catch (InterruptedException e) {
log.error("server error", e);
} finally {
boss.shutdownGracefully();
worker.shutdownGracefully();
}
}
}
观察服务端控制台
再观察客户端控制台
7.4、单聊功能实现
改造客户端，再**While(true)**循环中添加用户发送消息功能：
while (true) {
System.out.println("==================================");
System.out.println("send [userName] [content]");
System.out.println("gSend [group name] [content]");
System.out.println("gCreate [group name] [m1,m2,m3...]");
System.out.println("gMembers [group name]");
System.out.println("gJoin [group name]");
System.out.println("gQuit [group name]");
System.out.println("quit");
System.out.println("==================================");
String command = scanner.nextLine();
String[] s = command.split(" ");
switch (s[0]) {
case "send":
ctx.writeAndFlush(new ChatRequestMessage(userName, s[1], s[2]));
break;
case "gSend":
break;
case "gCreate":
break;
case "gMembers":
break;
case "gJoin":
break;
case "gQuit":
break;
case "quit":
return;
default:
break;
}
}
新增单聊消息处理器：
/**
* @author PengHuanZhi
* @date 2021年12月03日 12:32
*/
@ChannelHandler.Sharable
public class ChatRequestMessageHandler extends SimpleChannelInboundHandler<ChatRequestMessage> {
@Override
protected void channelRead0(ChannelHandlerContext ctx, ChatRequestMessage msg) {
String to = msg.getTo();
Channel channel = SessionFactory.getSession().getChannel(to);
// 在线
if (channel != null) {
channel.writeAndFlush(new ChatResponseMessage(msg.getFrom(), msg.getContent()));
} else {// 不在线
ctx.writeAndFlush(new ChatResponseMessage(false, "对方用户不存在或者不在线"));
}
}
}
然后在服务端使用它
final ChatRequestMessageHandler chatRequestMessageHandler = new ChatRequestMessageHandler();
//...
ch.pipeline().addLast(chatRequestMessageHandler);
客户端处理响应请求：
else if (msg instanceof ChatResponseMessage) {
ChatResponseMessage message = (ChatResponseMessage) msg;
Date date = new Date(System.currentTimeMillis());
System.out.println("==================================");
System.out.println(formatter.format(date));
System.out.println(message.getFrom() + ":" + message.getContent());
System.out.println("==================================");
}
启动两个客户端，分别用zhangsan和lisi登录发送消息，观察控制台：
请输入用户名：
zhangsan
请输入密码：
123
正在登录...请稍后
收到服务器响应
登录成功
==================================
send [userName] [content]
gSend [group name] [content]
gCreate [group name] [m1,m2,m3...]
gMembers [group name]
gJoin [group name]
gQuit [group name]
quit
==================================
send lisi 你好呀李四
==================================
send [userName] [content]
gSend [group name] [content]
gCreate [group name] [m1,m2,m3...]
gMembers [group name]
gJoin [group name]
gQuit [group name]
quit
==================================
2021-12-03 at 12:46:24 CST
lisi:你好呀张三
==================================
请输入用户名：
lisi
请输入密码：
123
正在登录...请稍后
收到服务器响应
登录成功
==================================
send [userName] [content]
gSend [group name] [content]
gCreate [group name] [m1,m2,m3...]
gMembers [group name]
gJoin [group name]
gQuit [group name]
quit
==================================
2021-12-03 at 12:46:09 CST
zhangsan:你好呀李四
==================================
send zhangsan 你好呀张三
==================================
send [userName] [content]
gSend [group name] [content]
gCreate [group name] [m1,m2,m3...]
gMembers [group name]
gJoin [group name]
gQuit [group name]
quit
==================================
7.5、群聊功能实现
7.5.1、创建群聊
同理新建创建群会话处理器
/**
* @author PengHuanZhi
* @date 2021年12月03日 14:25
*/
@ChannelHandler.Sharable
public class GroupCreateRequestMessageHandler extends SimpleChannelInboundHandler<GroupCreateRequestMessage> {
@Override
protected void channelRead0(ChannelHandlerContext ctx, GroupCreateRequestMessage msg) throws Exception {
String groupName = msg.getGroupName();
Set<String> members = msg.getMembers();
// 群管理器
GroupSession groupSession = GroupSessionFactory.getGroupSession();
Group group = groupSession.createGroup(groupName, members);
if (group == null) {
// 发生成功消息
ctx.writeAndFlush(new GroupCreateResponseMessage(true, groupName + "创建成功"));
// 发送拉群消息
List<Channel> channels = groupSession.getMembersChannel(groupName);
for (Channel channel : channels) {
channel.writeAndFlush(new GroupCreateResponseMessage(true, "您已被拉入" + groupName));
}
} else {
ctx.writeAndFlush(new GroupCreateResponseMessage(false, groupName + "已经存在"));
}
}
}
服务端添加此处理器
final GroupCreateRequestMessageHandler groupCreateRequestMessageHandler = new GroupCreateRequestMessageHandler();
//...
ch.pipeline().addLast(groupCreateRequestMessageHandler);
客户端处理这个请求
case "gCreate":
Set<String> set = new HashSet<>(Arrays.asList(s[2].split(",")));
// 加入自己
set.add(userName);
ctx.writeAndFlush(new GroupCreateRequestMessage(s[1], set));
break;
//...
else if (msg instanceof GroupCreateResponseMessage) {
GroupCreateResponseMessage message = (GroupCreateResponseMessage) msg;
Date date = new Date(System.currentTimeMillis());
System.out.println("==================================");
System.out.println(formatter.format(date));
System.out.println(message.getReason());
System.out.println("==================================");
}
启动三个客户端，分别登录zhangsan、lisi和wangwu，使用zhangsan创建群聊：
请输入用户名：
zhangsan
请输入密码：
123
正在登录...请稍后
收到服务器响应
登录成功
==================================
send [userName] [content]
gSend [group name] [content]
gCreate [group name] [m1,m2,m3...]
gMembers [group name]
gJoin [group name]
gQuit [group name]
quit
==================================
gCreate 盘丝洞 lisi,wangwu
==================================
send [userName] [content]
gSend [group name] [content]
gCreate [group name] [m1,m2,m3...]
gMembers [group name]
gJoin [group name]
gQuit [group name]
quit
==================================
2021-12-03 at 14:44:33 CST
盘丝洞创建成功
==================================
2021-12-03 at 14:44:33 CST
您已被拉入盘丝洞
==================================
请输入用户名：
lisi
请输入密码：
123
正在登录...请稍后
收到服务器响应
登录成功
==================================
send [userName] [content]
gSend [group name] [content]
gCreate [group name] [m1,m2,m3...]
gMembers [group name]
gJoin [group name]
gQuit [group name]
quit
==================================
2021-12-03 at 14:44:33 CST
您已被拉入盘丝洞
==================================
请输入用户名：
wangwu
请输入密码：
123
正在登录...请稍后
收到服务器响应
登录成功
==================================
send [userName] [content]
gSend [group name] [content]
gCreate [group name] [m1,m2,m3...]
gMembers [group name]
gJoin [group name]
gQuit [group name]
quit
==================================
2021-12-03 at 14:44:33 CST
您已被拉入盘丝洞
==================================
7.5.2、发送群聊消息
创建群聊消息处理器
/**
* @author PengHuanZhi
* @date 2021年12月03日 14:50
*/
@ChannelHandler.Sharable
public class GroupChatRequestMessageHandler extends SimpleChannelInboundHandler<GroupChatRequestMessage> {
@Override
protected void channelRead0(ChannelHandlerContext ctx, GroupChatRequestMessage msg) throws Exception {
List<Channel> channels = GroupSessionFactory.getGroupSession()
.getMembersChannel(msg.getGroupName());
for (Channel channel : channels) {
channel.writeAndFlush(new GroupChatResponseMessage(msg.getFrom(), msg.getContent()));
}
}
}
服务端使用
final GroupChatRequestMessageHandler groupChatRequestMessageHandler = new GroupChatRequestMessageHandler();
//...
ch.pipeline().addLast(groupChatRequestMessageHandler);
客户端处理消息
case "gSend":
ctx.writeAndFlush(new GroupChatRequestMessage(userName, s[1], s[2]));
break;
//...
else if (msg instanceof GroupChatResponseMessage) {
GroupChatResponseMessage message = (GroupChatResponseMessage) msg;
Date date = new Date(System.currentTimeMillis());
System.out.println("==================================");
System.out.println(formatter.format(date));
System.out.println(message.getFrom() + ":" + message.getContent());
System.out.println("==================================");
}
在创建群聊的基础上，再接入一个zhaoliu，它不在群组中，使用zhangsan发送一条消息：
gSend 盘丝洞 大家好
==================================
send [userName] [content]
gSend [group name] [content]
gCreate [group name] [m1,m2,m3...]
gMembers [group name]
gJoin [group name]
gQuit [group name]
quit
==================================
2021-12-03 at 14:55:22 CST
zhangsan:大家好
==================================
==================================
2021-12-03 at 14:55:22 CST
zhangsan:大家好
==================================
==================================
2021-12-03 at 14:55:22 CST
zhangsan:大家好
==================================
赵六直接没有消息
7.5.3、加入群聊
创建加入群聊的消息处理器
/**
* @author PengHuanZhi
* @date 2021年12月03日 15:17
*/
@ChannelHandler.Sharable
public class GroupJoinRequestMessageHandler extends SimpleChannelInboundHandler<GroupJoinRequestMessage> {
@Override
protected void channelRead0(ChannelHandlerContext ctx, GroupJoinRequestMessage msg) throws Exception {
Group group = GroupSessionFactory.getGroupSession().joinMember(msg.getGroupName(), msg.getUsername());
if (group != null) {
ctx.writeAndFlush(new GroupJoinResponseMessage(true, msg.getGroupName() + "群加入成功"));
} else {
ctx.writeAndFlush(new GroupJoinResponseMessage(true, msg.getGroupName() + "群不存在"));
}
}
}
服务端使用
final GroupJoinRequestMessageHandler groupJoinRequestMessageHandler = new GroupJoinRequestMessageHandler();
//...
ch.pipeline().addLast(groupJoinRequestMessageHandler);
客户端处理
case "gJoin":
ctx.writeAndFlush(new GroupJoinRequestMessage(userName, s[1]));
break;
//...
else if (msg instanceof GroupJoinResponseMessage) {
GroupJoinResponseMessage message = (GroupJoinResponseMessage) msg;
Date date = new Date(System.currentTimeMillis());
System.out.println("==================================");
System.out.println(formatter.format(date));
System.out.println(message.getReason());
System.out.println("==================================");
}
测试
7.5.4、退出群聊
创建退出群聊的消息处理器
/**
* @author PengHuanZhi
* @date 2021年12月03日 15:11
*/
@ChannelHandler.Sharable
public class GroupQuitRequestMessageHandler extends SimpleChannelInboundHandler<GroupQuitRequestMessage> {
@Override
protected void channelRead0(ChannelHandlerContext ctx, GroupQuitRequestMessage msg) throws Exception {
Group group = GroupSessionFactory.getGroupSession().removeMember(msg.getGroupName(), msg.getUsername());
if (group != null) {
ctx.writeAndFlush(new GroupJoinResponseMessage(true, "已退出群" + msg.getGroupName()));
} else {
ctx.writeAndFlush(new GroupJoinResponseMessage(true, msg.getGroupName() + "群不存在"));
}
}
}
服务器使用
final GroupQuitRequestMessageHandler groupQuitRequestMessageHandler = new GroupQuitRequestMessageHandler();
//...
ch.pipeline().addLast(groupQuitRequestMessageHandler);
客户端处理：
case "gQuit":
ctx.writeAndFlush(new GroupQuitRequestMessage(userName, s[1]));
break;
//...
//复用加入群聊消息处理
测试
7.5.5、查看群成员
添加查看群成员消息处理器
/**
* @author PengHuanZhi
* @date 2021年12月03日 15:21
*/
@ChannelHandler.Sharable
public class GroupMembersRequestMessageHandler extends SimpleChannelInboundHandler<GroupMembersRequestMessage> {
@Override
protected void channelRead0(ChannelHandlerContext ctx, GroupMembersRequestMessage msg) throws Exception {
Set<String> members = GroupSessionFactory.getGroupSession()
.getMembers(msg.getGroupName());
ctx.writeAndFlush(new GroupMembersResponseMessage(members));
}
}
服务端使用：
final GroupMembersRequestMessageHandler groupMembersRequestMessageHandler = new GroupMembersRequestMessageHandler();
//...
ch.pipeline().addLast(groupMembersRequestMessageHandler);
客户端处理消息
case "gMembers":
ctx.writeAndFlush(new GroupMembersRequestMessage(s[1]));
break;
//..
else if (msg instanceof GroupMembersResponseMessage) {
GroupMembersResponseMessage message = (GroupMembersResponseMessage) msg;
Date date = new Date(System.currentTimeMillis());
System.out.println("==================================");
System.out.println(formatter.format(date));
System.out.println("成员如下：");
message.getMembers().forEach(System.out::println);
System.out.println("==================================");
}
测试
7.6、退出功能实现
创建退出连接处理器
/**
* @author PengHuanZhi
* @date 2021年12月03日 15:03
*/
@Slf4j
@ChannelHandler.Sharable
public class QuitHandler extends ChannelInboundHandlerAdapter {
/**
* @description 当连接断开时触发 inactive 事件
*/
@Override
public void channelInactive(ChannelHandlerContext ctx) throws Exception {
SessionFactory.getSession().unbind(ctx.channel());
log.debug("{} 已经断开", ctx.channel());
}
/**
* @description 当出现异常时触发
*/
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
SessionFactory.getSession().unbind(ctx.channel());
log.debug("{} 已经异常断开 异常是{}", ctx.channel(), cause.getMessage());
}
}
服务端使用
final QuitHandler quitHandler = new QuitHandler();
//...
ch.pipeline().addLast(quitHandler);
启动客户端测试：
7.7、空闲检测
使用Netty提供的空闲检测功能，可以监测连接假死的问题，下面先介绍一下连接假死：
原因
- 网络设备出现故障，例如网卡，机房等，底层的 TCP 连接已经断开了，但应用程序没有感知到，仍然占用着资源。
- 公网网络不稳定，出现丢包。如果连续出现丢包，这时现象就是客户端数据发不出去，服务端也一直收不到数据，就这么一直耗着
- 应用程序线程阻塞，无法进行数据读写
问题
- 假死的连接占用的资源不能自动释放
- 向假死的连接发送数据，得到的反馈是发送超时
服务器端解决
- 怎么判断客户端连接是否假死呢？如果能收到客户端数据，说明没有假死。因此策略就可以定为，每隔一段时间就检查这段时间内是否接收到客户端数据，没有就可以判定为连接假死
可以使用Netty提供的空闲检测处理器IdleStateHandler
// 用来判断是不是 读空闲时间过长，或 写空闲时间过长
// 5s 内如果没有收到 channel 的数据，会触发一个 IdleState#READER_IDLE 事件
ch.pipeline().addLast(new IdleStateHandler(5, 0, 0));
其中三个参数分别是：
- readerIdleTimeSeconds：读的空闲时间上限
- writerIdleTimeSeconds：写的空闲时间上限
- allIdleTimeSeconds：读写都空闲的时间上限
当触发上述事件后，Netty自动就会发送一条消息到处理器流中，我们就需要自定义去处理这个消息，因为此消息既可以出站也可以入站，所以我们需要一个特殊的可以同事作为出站和入站的处理器，那就是ChannelDuplexHandler
// ChannelDuplexHandler 可以同时作为入站和出站处理器
ch.pipeline().addLast(new ChannelDuplexHandler() {
// 用来触发特殊事件
@Override
public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception{
IdleStateEvent event = (IdleStateEvent) evt;
// 触发了读空闲事件
if (event.state() == IdleState.READER_IDLE) {
log.debug("已经 5s 没有读到数据了");
}
}
});
客户端入站处理器新添两个事件处理：
/**
* @description 在连接断开时触发
*/
@Override
public void channelInactive(ChannelHandlerContext ctx) throws Exception {
log.debug("连接已经断开，按任意键退出..");
}
/**
* @description 在出现异常时触发
*/
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
log.debug("连接已经断开，按任意键退出..{}", cause.getMessage());
}
测试
7.8、心跳
对于空闲检测，某些情况下并不合理，可能用户本身操作就不连续，倒杯水呀，上个厕所啥的，这样主动权全掌握早了服务端，不太人性化，那么我们还可以采取心跳的方式来实时告诉服务端，我这个客户端一切正常
所以结合空闲检测，我们在客户端添加如下代码
// 用来判断是不是 读空闲时间过长，或写空闲时间过长
// 3s 内如果没有向服务器写数据，会触发一个 IdleState#WRITER_IDLE 事件
ch.pipeline().addLast(new IdleStateHandler(0, 3, 0));
// ChannelDuplexHandler 可以同时作为入站和出站处理器
ch.pipeline().addLast(new ChannelDuplexHandler() {
// 用来触发特殊事件
@Override
public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception {
IdleStateEvent event = (IdleStateEvent) evt;
// 触发了写空闲事件
if (event.state() == IdleState.WRITER_IDLE) {
log.debug("3s 没有写数据了，发送一个心跳包");
ctx.writeAndFlush(new PingMessage());
}
}
});
其中客户端需要持续往服务端发送的心跳包为：
/**
* @author PengHuanZhi
* @date 2021/12/2 9:53
*/
public class PingMessage extends Message {
@Override
public int getMessageType() {
return PING_MESSAGE;
}
}
测试
8、优化
8.1、扩展序列化算法
8.1.1、上层设计
序列化，反序列化主要用在消息正文的转换上
- 序列化时，需要将 Java 对象变为要传输的数据（可以是 byte[]，或 json 等，最终都需要变成 byte[]）
- 反序列化时，需要将传入的正文数据还原成 Java 对象，便于处理
目前的代码仅支持 Java 自带的序列化，反序列化机制，核心代码如下
// 反序列化
byte[] body = new byte[bodyLength];
byteByf.readBytes(body);
ObjectInputStream in = new ObjectInputStream(new ByteArrayInputStream(body));
Message message = (Message) in.readObject();
message.setSequenceId(sequenceId);
// 序列化
ByteArrayOutputStream out = new ByteArrayOutputStream();
new ObjectOutputStream(out).writeObject(message);
byte[] bytes = out.toByteArray();
现在为了支持更多的序列化算法，我们可以向上抽象一个Serializer 接口，并在其中定义好一个序列化算法实现类的枚举
/**
* @author PengHuanZhi
* @date 2021年12月03日 16:49
*/
public interface Serializer {
/**
* 反序列化方法
*
* @param clazz 因为JDK序列化出来的字节数组包含了原始对象信息，而其他的序列化算法便不都包含了，所以需要指定反序列化出来的对象是谁
* @param bytes 字节数组
* @return T 返回指定对象
*/
<T> T deserialize(Class<T> clazz, byte[] bytes);
/**
* 序列化方法
*
* @param object 待序列化对象
* @return byte[] 返回序列化后的字节数组
*/
<T> byte[] serialize(T object);
enum SerializerAlgorithm implements Serializer {
}
}
想让我们程序动态的选择序列化算法，我们可以将其配置到一个配置文件中，那么就需要提供读取配置文件的代码，新建一个配置类：
/**
* @author PengHuanZhi
* @date 2021年12月03日 16:59
*/
public abstract class Config {
static Properties properties;
static {
try (InputStream in = Config.class.getResourceAsStream("/application.properties")) {
properties = new Properties();
properties.load(in);
} catch (IOException e) {
throw new ExceptionInInitializerError(e);
}
}
public static Serializer.SerializerAlgorithm getSerializerAlgorithm() {
String value = properties.getProperty("serializer.algorithm");
if (value == null) {
//未设置默认选择JDK
return Serializer.SerializerAlgorithm.JDK;
} else {
return Serializer.SerializerAlgorithm.valueOf(value);
}
}
}
自定义的编解码器此时便可以灵活的去选择序列化算法：
/**
* @author PengHuanZhi
* @date 2021年12月02日 20:35
*/
@Slf4j
@ChannelHandler.Sharable
public class MessageCodecSharable extends MessageToMessageCodec<ByteBuf, Message> {
@Override
protected void encode(ChannelHandlerContext ctx, Message msg, List<Object> outList) throws Exception {
ByteBuf out = ctx.alloc().buffer();
// 1. 4 字节的魔数
out.writeBytes(new byte[]{1, 2, 3, 4});
// 2. 1 字节的版本,
out.writeByte(1);
// 3. 1 字节的序列化方式 枚举类ordinal()方法可以获取下标，也是从0开始的
out.writeByte(Config.getSerializerAlgorithm().ordinal());
// 4. 1 字节的指令类型
out.writeByte(msg.getMessageType());
// 5. 4 个字节
out.writeInt(msg.getSequenceId());
// 无意义，对齐填充
out.writeByte(0);
// 6. 根据指定的序列化方式去序列化
byte[] message = Config.getSerializerAlgorithm().serialize(msg);
// 7. 长度
out.writeInt(message.length);
// 8. 写入内容
out.writeBytes(message);
outList.add(out);
}
@Override
protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
// 1. 4 字节的魔数
int magicNum = in.readInt();
// 2. 1 字节的版本号
byte version = in.readByte();
// 3. 1 字节的序列化算法 jdk 0 , json 1
byte serializerAlgorithm = in.readByte(); // 0 或 1
// 4. 1 字节的指令类型
byte messageType = in.readByte();
// 5. 4 个字节的请求序号
int sequenceId = in.readInt();
// 无意义，对齐填充
in.readByte();
// 7. 长度
int length = in.readInt();
// 8. 读取内容
byte[] bytes = new byte[length];
in.readBytes(bytes, 0, length);
// 找到反序列化算法
Serializer.SerializerAlgorithm algorithm = Serializer.SerializerAlgorithm.values()[serializerAlgorithm];
// 确定具体消息类型
Class<? extends Message> messageClass = Message.getMessageClass(messageType);
Message message = (Message) algorithm.deserialize(messageClass, bytes);
log.debug("{}, {}, {}, {}, {}, {}", magicNum, version, serializerAlgorithm, messageType, sequenceId, length);
log.debug("{}", message);
out.add(message);
}
}
测试类
/**
* @author PengHuanZhi
* @date 2021年12月03日 17:14
*/
public class Test {
public static void main(String[] args) {
MessageCodecSharable messageCodecSharable = new MessageCodecSharable();
LoggingHandler loggingHandler = new LoggingHandler();
EmbeddedChannel channel = new EmbeddedChannel(loggingHandler, messageCodecSharable, loggingHandler);
LoginRequestMessage loginRequestMessage = new LoginRequestMessage("zhangsan", "123");
//出站
channel.writeOutbound(loginRequestMessage);
//入站
ByteBuf buf = messageToByteBuf(loginRequestMessage);
channel.writeInbound(buf);
}
public static ByteBuf messageToByteBuf(Message msg) {
int algorithm = Config.getSerializerAlgorithm().ordinal();
ByteBuf out = ByteBufAllocator.DEFAULT.buffer();
out.writeBytes(new byte[]{1, 2, 3, 4});
out.writeByte(1);
out.writeByte(algorithm);
out.writeByte(msg.getMessageType());
out.writeInt(msg.getSequenceId());
out.writeByte(0xff);
byte[] bytes = Serializer.SerializerAlgorithm.values()[algorithm].serialize(msg);
out.writeInt(bytes.length);
out.writeBytes(bytes);
return out;
}
}
8.1.2、JDK序列化实现
在枚举类中新增一个JDK
// JDK 实现
JDK {
@Override
public <T> Object deserialize(Class<T> clazz, byte[] bytes) {
try {
ObjectInputStream in =
new ObjectInputStream(new ByteArrayInputStream(bytes));
return in.readObject();
} catch (IOException | ClassNotFoundException e) {
throw new RuntimeException("SerializerAlgorithm.JDK 反序列化错误", e);
}
}
@Override
public <T> byte[] serialize(T object) {
try {
ByteArrayOutputStream out = new ByteArrayOutputStream();
new ObjectOutputStream(out).writeObject(object);
return out.toByteArray();
} catch (IOException e) {
throw new RuntimeException("SerializerAlgorithm.JDK 序列化错误", e);
}
}
}
测试：
- 出站
- 入站
8.1.3、JSON序列化实现
市面上Json序列化的实现繁多，这里选用谷歌出品的Gson，其他的Json序列化方式大同小异
// Json 实现(引入了 Gson 依赖)
Json {
@Override
public <T> T deserialize(Class<T> clazz, byte[] bytes) {
return new Gson().fromJson(new String(bytes, StandardCharsets.UTF_8), clazz);
}
@Override
public <T> byte[] serialize(T object) {
return new Gson().toJson(object).getBytes(StandardCharsets.UTF_8);
}
};
测试
- 出站
- 入站
8.2、参数调优
8.2.1、CONNECT_TIMEOUT_MILLIS
用于客户端的SocketChannel中，用在客户端建立连接时，如果在指定毫秒内无法连接，会抛出 timeout 异常
- 测试代码如下：
/**
* @author PengHuanZhi
* @date 2021年12月04日 10:47
*/
@Slf4j
public class ConnectionTimeOutMillisTest {
public static void main(String[] args) {
NioEventLoopGroup group = new NioEventLoopGroup();
try {
ChannelFuture future = new Bootstrap()
.group(group)
.option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 300)
.channel(NioSocketChannel.class)
.handler(new LoggingHandler())
.connect("127.0.0.1", 8080)
.sync();
future.channel()
.closeFuture()
.sync();
} catch (Exception e) {
e.printStackTrace();
log.debug("timeout");
} finally {
group.shutdownGracefully();
}
}
}
- 仅仅开启客户端，不开启服务端，超时时间设置为0.3秒，观察控制台
- 当我们再次把超时时间设置的长一些，比如5s，再次观察
发现报错信息改变了，这是因为，当我们服务端本身就是没有开启的，就是不可用的，我们自己设置的超时时间还没到达的时候，Netty底层就直接抛出了连接异常，重新回到连接超时异常，可以看到报错信息是在AbstractNioChannel的261行抛出的，我们点进去看
if (connectTimeoutMillis > 0) {
connectTimeoutFuture = eventLoop().schedule(new Runnable() {
@Override
public void run() {
ChannelPromise connectPromise = AbstractNioChannel.this.connectPromise;
if (connectPromise != null && !connectPromise.isDone()
&& connectPromise.tryFailure(new ConnectTimeoutException(
"connection timed out: " + remoteAddress))) {
close(voidPromise());
}
}
}, connectTimeoutMillis, TimeUnit.MILLISECONDS);
}
这里可以发现，当我们配置了一个connectTimeoutMillis参数的时候，且是大于0的，那么我们就会使用Nio线程去创建一个定时任务，从现在开始，等待connectTimeoutMillis长的时间，执行run方法，run方法便会直接抛出连接超时异常，当连接建立后，当前定时任务又会被取消掉
8.2.2、SO_BACKLOG
- 属于服务端ServerSocketChannal 的参数配置
首先先来聊聊TCP三次握手的过程
- 在较早的Linux版本2.2之前，程序中配置了backlog参数后，那么我们的全连接和半连接队列的大小就都由它决定
- 在Linux版本2.2之后，系统便提供了两个配置文件来分别配置半连接队列和全连接队列的大小
- sync queue - 半连接队列大小通过
/proc/sys/net/ipv4/tcp_max_syn_backlog指定，在 syncookies 启用的情况下，逻辑上没有最大值限制，这个设置便被忽略 - accept queue - 全连接队列 - 全连接队列其大小通过
/proc/sys/net/core/somaxconn指定，在使用 listen 函数时，如果程序也指定了backlog参数，内核会根据程序的 backlog 参数与系统参数，取二者的较小值，如果 accpet queue 队列满了，server 将发送一个拒绝连接的错误信息到 client
- sync queue - 半连接队列大小通过
测试一下（因为本机是Windows操作系统，所以不会去读取配置文件，程序设置多少就是多少）：
/**
* @author PengHuanZhi
* @date 2021年12月04日 16:18
*/
public class BackLogServerTest {
public static void main(String[] args) {
new ServerBootstrap()
.group(new NioEventLoopGroup())
//针对SocketChannel配置，如果要对普通的SocketChannel配置，应该用ChildOption
//一条连接就满了
.option(ChannelOption.SO_BACKLOG, 1)
.channel(NioServerSocketChannel.class)
.childHandler(new ChannelInitializer<NioSocketChannel>() {
@Override
protected void initChannel(NioSocketChannel ch) {
ch.pipeline().addLast(new LoggingHandler());
}
}).bind(8080);
}
}
由于Netty的处理能力很强，一般连接来了就能处理，所以为了验证，连接来了不能处理的情况，我们把断点应该设置到一个准备调用accept方法的地方，让他停下来，那么这部分代码在
NioEventLoop#processSelectedKey(SelectionKey, AbstractNioChannel)方法中：
其中的unsafe.read()便会去处理accept，现在断点打到它的上面，让程序不执行accept，下次来了请求就只能放进全连接队列中，使用debug模式启动服务端，开启两个客户端，发现第二个客户端直接就被拒绝了
现在我们探究一下Netty是怎么给我们设置这个Backlog参数的，因为Netty底层调用的就是Java的NIO，而Backlog参数就是NIO中的bind方法的第二个参数，我们可以从这个出发，看看Netty在哪里调用了NIO中的bind方法：
我们在Netty源码中查看哪里调用了这个bind方法
可以看到这个参数是从config中拿到的
查证后，这个co****nfig是一个接口，所以我们需要的config应该是它的一个实现类
private final ServerSocketChannelConfig config;
查看了这个接口的实现后，我们很容易就能意识到我们应该需要找Default的ServerSocketChannelConfig实现
果然我们在里面发现了一个backlog赋值的地方
进入NetUtil就可以看到SOMAXCONN参数设置的源头了，如果是Windows，默认为200，如果是Linux或者MacOS，就默认128.最后再去读取
/proc/sys/net/core/somaxconn文件，去查看有没有配置这个参数
8.2.3、ulimit -n
属于操作系统的临时参数，需要时，添加在VM Option中，用于限制一个进程能够打开的最大文件数量（n标识），如果超过了会报tooManyOpentFile的错误，一般在高并发场景下，这个都不能做太大限制才行
8.2.4、TCP_NODELAY
属于 SocketChannal 参数，在上面提到过的Nagle 算法，如果确实需要发送一些很小的数据包，可能会导致客户端一直收不到数据，这个参数默认是false，标识开启Nagle算法，如果我们需要我们的消息及时发送出去，那么这个参数需要设置为True
8.2.5、SO_SNDBUF & SO_RCVBUF
- SO_SNDBUF 属于 SocketChannal 参数
- SO_RCVBUF 既可用于 SocketChannal 参数，也可以用于 ServerSocketChannal 参数（建议设置到 ServerSocketChannal 上）
他们用来配置TCP滑动窗口的缓冲区大小的，一般这个最好不要配置，因为操作系统都会智能的分辨客户端服务端的通信能力动态调整这个缓冲区大小
8.2.6、ALLOCATOR
- 属于 SocketChannal 参数
- 用来分配 ByteBuf，使用 ctx.alloc()
启动一个服务端和客户端，客户端发送一条消息
ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
ByteBuf buf = ctx.alloc().buffer();
log.debug("alloc buf {}", buf);
}
});
可以看到服务端创建的ByteBuf是一个池化的并且是使用的直接内存
那么我们如何人为控制创建的ByteBuf呢？开始追踪一下源码，起点就从ChannelConfig开始，这个类中提供了设置分配ByteBuf的Allocator的方法
但是我们需要找的是操作系统默认给我们设置的什么Allocator，当前ChannelConfig是一个接口，默认配置就去找找它的默认实现
其中就找到了Allocator的默认设置
点进去
再点进去
在当前ByteBufUtil中找到哪里给它赋值的
但是这一步只能判断是否使用池化，那么使用堆内存和直接内存在哪里配置的呢，其实就在这里，当判断是否池化后，调用的也是另一个对象的Default对象，随便点进一个UnpooledByteBufAllocator去看看
可以看到这个方法标识，是否首选直接内存，再点进去
然后可以找到这个变量在哪里赋值，也就是说，我们同样可以再Vm Option中指定是否使用直接内存：
8.2.7、RCVBUF_ALLOCATOR
- 属于 SocketChannal 参数
- 控制 netty 接收缓冲区大小
- 负责入站数据的分配，决定入站缓冲区的大小（并可动态调整），统一采用 direct 直接内存，具体池化还是非池化由 allocator 决定
刚才的服务端代码，我们是创建的ByteBuf打印的，现在我们再加一行直接打印msg，看看Netty自动给我们封装的ByteBuf是什么类型
ByteBuf buf = ctx.alloc().buffer();
log.debug("alloc buf {}", buf);
log.debug("{}", msg);
可以看到，对于msg而言，Netty默认创建的也是一个池化的直接内存的ByteBuf，如果尝试在Vm Option中去配置是否池化和是否直接内存：
-Dio.netty.allocator.type=unpooled -Dio.netty.noPreferDirect=true
发现生效的只有是否池化，是否直接内存配置了并没有生效 ，原因是Netty认为网络IO中的ByteBuf，使用直接内存效率更高，强制使用不允许修改，那么我们现在去探究一下，从哪里给我们设置好的只能使用直接内存的ByteBuf呢，将断点打到打印语句，观察堆栈信息：
那么我们向，Netty帮我们创建的ByteBuf应该是在哪里创建的呢？我们应该是收到一个Channel的数据，就开始创建的，所以不会在pipeline中，所以一下子就关注到了这一行
进去就能找到，我们这个ByteBuf是在这里创建的
那么这个allocHandle是什么呢，往上面看几行
先一个个分析，首先ByteBufAllocator，调用了config.getAllocator()，点进去
发现，就是上面看Allocator源码的时候拿到的 决定是否池化的Allocator，进一步说明ByteBufAllocator只负责是否池化，那么是否直接内存应该是在RecvByteBufAllocator的内部类Handle决定的，那么它是怎么来的呢，它调用了**recvBufAllocHandle()**方法，进去看看
继续
观察一下是哪个地方设置的这个rcvBufAllocator，就在下面
继续找谁调用的set
再继续找
找到了，原来是一个AdaptiveRecvByteBufAllocator，它也只是控制Buffer大小的
回到开始，我们调用了allocHandle.allocate方法，点进去看，因为这是一个接口方法，这里我们直接找一个叫MaxMessagesRecvByteBufAllocator的实现类
可以看到直接调用了开始的池化非池化的Allocator去创建iobuffer，其中的guess方法可以用来指定Buffer的大小，它可以动态的根据传过来的数据设置，而ioBuffer方法便可以创建一个固定的使用直接内存的ByteBuf了
9、RPC框架
9.1、准备工作
在原有聊天室的代码基础上做如下改动：
- Message添加新的Rpc消息类型
// 省略旧的代码
public static final int RPC_MESSAGE_TYPE_REQUEST = 101;
public static final int RPC_MESSAGE_TYPE_RESPONSE = 102;
static {
// ...
messageClasses.put(RPC_MESSAGE_TYPE_REQUEST, RpcRequestMessage.class);
messageClasses.put(RPC_MESSAGE_TYPE_RESPONSE, RpcResponseMessage.class);
}
- 新增两个消息类型
/**
* @author PengHuanZhi
* @date 2021/12/2 9:53
*/
@Getter
@ToString(callSuper = true)
public class RpcRequestMessage extends Message {
/**
* 调用的接口全限定名，服务端根据它找到实现
*/
private final String interfaceName;
/**
* 调用接口中的方法名
*/
private final String methodName;
/**
* 方法返回类型
*/
private final Class<?> returnType;
/**
* 方法参数类型数组
*/
private final Class<?>[] parameterTypes;
/**
* 方法参数值数组
*/
private final Object[] parameterValue;
public RpcRequestMessage(int sequenceId, String interfaceName, String methodName, Class<?> returnType, Class<?>[] parameterTypes, Object[] parameterValue) {
super.setSequenceId(sequenceId);
this.interfaceName = interfaceName;
this.methodName = methodName;
this.returnType = returnType;
this.parameterTypes = parameterTypes;
this.parameterValue = parameterValue;
}
@Override
public int getMessageType() {
return RPC_MESSAGE_TYPE_REQUEST;
}
}
/**
* @author PengHuanZhi
* @date 2021/12/2 9:53
*/
@EqualsAndHashCode(callSuper = true)
@Data
@ToString(callSuper = true)
public class RpcResponseMessage extends Message {
/**
* 返回值
*/
private Object returnValue;
/**
* 异常值
*/
private Exception exceptionValue;
@Override
public int getMessageType() {
return RPC_MESSAGE_TYPE_RESPONSE;
}
}
- 新增一个远程调用的方法接口
/**
* @author PengHuanZhi
* @date 2021年12月05日 11:13
*/
public interface HelloService {
/**
* 简单的远程调用方法
*
* @param name 参数
* @return java.lang.String 返回方法结果为String
*/
String sayHello(String name);
}
- 并提供实现
/**
* @author PengHuanZhi
* @date 2021年12月05日 11:15
*/
public class HelloServiceImpl implements HelloService {
@Override
public String sayHello(String name) {
return "你好呀," + name;
}
}
因为我们需要目标接口对应的实现类中，找到对应的实现方法，还需要传入对应的方法参数，最后再调用该方法，获取返回结果给客户端那么我们第一步就是利用反射找到目标接口的一个实例，这里创建一个获取实例的工厂类对象
/**
* @author PengHuanZhi
* @date 2021年12月05日 13:55
*/
public class ServicesFactory {
private static final Map<Class<?>, Object> MAP = new HashMap<>();
static {
try {
InputStream in = Config.class.getResourceAsStream("/application.properties");
Properties properties = new Properties();
properties.load(in);
Set<String> names = properties.stringPropertyNames();
for (String name : names) {
if (name.endsWith("Service")) {
Class<?> interfaceClass = Class.forName(name);
Class<?> instanceClass = Class.forName(properties.getProperty(name));
MAP.put(interfaceClass, instanceClass.newInstance());
}
}
} catch (IOException | ClassNotFoundException | InstantiationException | IllegalAccessException e) {
throw new ExceptionInInitializerError(e);
}
}
public static <T> Object getService(Class<T> interfaceClass) {
return MAP.get(interfaceClass);
}
}
- 其中Config沿用自定义序列化算法中所使用的Config
/**
* @author PengHuanZhi
* @date 2021年12月05日 13:59
*/
public abstract class Config {
static Properties properties;
static {
try (InputStream in = Config.class.getResourceAsStream("/application.properties")) {
properties = new Properties();
properties.load(in);
} catch (IOException e) {
throw new ExceptionInInitializerError(e);
}
}
public static Serializer.SerializerAlgorithm getSerializerAlgorithm() {
String value = properties.getProperty("serializer.algorithm");
if (value == null) {
return Serializer.SerializerAlgorithm.JDK;
} else {
return Serializer.SerializerAlgorithm.valueOf(value);
}
}
}
9.2、编写服务端代码
大部分代码其实和之前都是一样的，现在只是需要额外处理一下Rpc相关的消息，即添加Rpc消息对应的Handler即可
/**
* @author PengHuanZhi
* @date 2021年12月05日 10:53
*/
@Slf4j
public class RpcServer {
public static void main(String[] args) {
try {
EventLoopGroup boss = new NioEventLoopGroup(1);
EventLoopGroup worker = new NioEventLoopGroup();
LoggingHandler loggingHandler = new LoggingHandler(LogLevel.DEBUG);
MessageCodecSharable messageCodecSharable = new MessageCodecSharable();
// rpc 请求消息处理器
RpcRequestMessageHandler rpcRequestMessageHandler = new RpcRequestMessageHandler();
ChannelFuture channelFuture = new ServerBootstrap()
.group(boss, worker)
.channel(NioServerSocketChannel.class)
.childHandler(new ChannelInitializer<NioSocketChannel>() {
@Override
protected void initChannel(NioSocketChannel ch) throws Exception {
ch.pipeline().addLast(new ProtocolFrameDecoder());
ch.pipeline().addLast(loggingHandler);
ch.pipeline().addLast(messageCodecSharable);
ch.pipeline().addLast(rpcRequestMessageHandler);
}
}).bind(8888).sync();
ChannelFuture closeFuture = channelFuture.channel().closeFuture();
closeFuture.addListener((ChannelFutureListener) future -> {
boss.shutdownGracefully();
worker.shutdownGracefully();
});
} catch (InterruptedException e) {
log.error("server error", e);
}
}
}
9.3、编写Rpc消息请求处理器
/**
* @author PengHuanZhi
* @date 2021年12月05日 11:06
*/
@ChannelHandler.Sharable
public class RpcRequestMessageHandler extends SimpleChannelInboundHandler<RpcRequestMessage> {
@Override
protected void channelRead0(ChannelHandlerContext ctx, RpcRequestMessage msg) throws Exception {
RpcResponseMessage rpcResponseMessage = new RpcResponseMessage();
rpcResponseMessage.setSequenceId(msg.getSequenceId());
try {
HelloService service = (HelloService) ServicesFactory.getService(Class.forName(msg.getInterfaceName()));
Method method = service.getClass().getMethod(msg.getMethodName(), msg.getParameterTypes());
Object invoke = method.invoke(service, msg.getParameterValue());
rpcResponseMessage.setReturnValue(invoke);
} catch (Exception e) {
rpcResponseMessage.setReturnValue(e);
}
ctx.writeAndFlush(rpcResponseMessage);
}
}
9.4、编写客户端代码
/**
* @author PengHuanZhi
* @date 2021年12月05日 10:53
*/
@Slf4j
public class RpcClient {
public static void main(String[] args) throws Exception {
NioEventLoopGroup group = new NioEventLoopGroup();
LoggingHandler loggingHandler = new LoggingHandler(LogLevel.DEBUG);
MessageCodecSharable messageCodecSharable = new MessageCodecSharable();
RpcResponseMessageHandler rpcResponseMessageHandler = new RpcResponseMessageHandler();
try {
ChannelFuture channelFuture = new Bootstrap()
.group(group)
.channel(NioSocketChannel.class)
.handler(new ChannelInitializer<SocketChannel>() {
@Override
protected void initChannel(SocketChannel ch) throws Exception {
ch.pipeline().addLast(new ProtocolFrameDecoder());
ch.pipeline().addLast(loggingHandler);
ch.pipeline().addLast(messageCodecSharable);
ch.pipeline().addLast(rpcResponseMessageHandler);
ch.pipeline().addLast(new ChannelInboundHandlerAdapter() {
@Override
public void channelActive(ChannelHandlerContext ctx) throws Exception {
ctx.writeAndFlush(ctx.alloc().buffer().writeBytes("hello!".getBytes()));
RpcRequestMessage rpcRequestMessage = new RpcRequestMessage(
1,
"com.phz.rpc.server.service.HelloService",
"sayHello",
String.class,
new Class[]{String.class},
new Object[]{"张三"}
);
ChannelFuture future = ctx.writeAndFlush(rpcRequestMessage);
future.addListener(promise -> {
if (promise.isSuccess()) {
log.info("result ： {}", promise.getNow());
} else {
log.error("result ： ", promise.cause());
}
});
}
});
}
})
.connect("127.0.0.1", 6666)
.sync();
ChannelFuture closeFuture = channelFuture.channel().closeFuture();
closeFuture.addListener((ChannelFutureListener) f -> group.shutdownGracefully());
} catch (Exception e) {
log.error("client error ", e);
}
}
}
9.5、编写Rpc消息响应处理器
/**
* @author PengHuanZhi
* @date 2021年12月05日 11:07
*/
@Slf4j
@ChannelHandler.Sharable
public class RpcResponseMessageHandler extends SimpleChannelInboundHandler<RpcResponseMessage> {
@Override
protected void channelRead0(ChannelHandlerContext ctx, RpcResponseMessage msg) throws Exception {
log.info("msg : {}", msg);
}
}
9.6、特殊问题出现
测试一下
发现在使用Gson序列化的时候，没有正确将String的张三给序列化出来，导致报错啦，因为Gson在转换Java中的String类型到Class的时候需要用到正确的类型转换器，这个类型转换器需要自己实现，这里我们将其放在Serializer接口中作为一个内部类，对于Jackson或者时fastJson，则不需要考虑这个问题
/**
* 因为需要将Java中的Class和Json互转，所以这里的泛型就用Class
*/
class ClassCodec implements JsonSerializer<Class<?>>, JsonDeserializer<Class<?>> {
@Override
public Class<?> deserialize(JsonElement json, Type typeOfT, JsonDeserializationContext context) throws JsonParseException {
try {
String str = json.getAsString();
return Class.forName(str);
} catch (ClassNotFoundException e) {
throw new JsonParseException(e);
}
}
@Override
public JsonElement serialize(Class<?> src, Type typeOfSrc, JsonSerializationContext context) {
// 将传递进来的Class的全路径转换为Class，在传输的时候只需要知道类的全路径就可以啦
return new JsonPrimitive(src.getName());
}
}
}
并且在创建Gson的时候将这个注册进去，所以以前的Json枚举需要修改一下：
JSON {
@Override
public <T> T deserialize(Class<T> clazz, byte[] bytes) {
Gson gson = new GsonBuilder().registerTypeAdapter(Class.class, new Serializer.ClassCodec()).create();
return gson.fromJson(new String(bytes, StandardCharsets.UTF_8), clazz);
}
@Override
public <T> byte[] serialize(T object) {
Gson gson = new GsonBuilder().registerTypeAdapter(Class.class, new Serializer.ClassCodec()).create();
return gson.toJson(object).getBytes(StandardCharsets.UTF_8);
}
}
再次测试：
9.7、功能优化
我们创建一个Channel的管理类，让每一次的Rpc调用都省去和服务器进行连接的过程，直接调用一个创建好的Channel对象进行发送消息，需要把之前客户端的代码抽取出来，放到一个专门的管理类中
/**
* @author PengHuanZhi
* @date 2021年12月05日 16:34
*/
@Slf4j
public class RpcManager {
private static Channel channel;
private static final Object LOCK = new Object();
public static Channel getChannel() {
if (channel != null) {
return channel;
}
synchronized (LOCK) {
if (channel != null) {
return channel;
}
initChannel();
return channel;
}
}
private static void initChannel() {
NioEventLoopGroup group = new NioEventLoopGroup();
LoggingHandler loggingHandler = new LoggingHandler(LogLevel.DEBUG);
MessageCodecSharable messageCodecSharable = new MessageCodecSharable();
RpcResponseMessageHandler rpcResponseMessageHandler = new RpcResponseMessageHandler();
try {
ChannelFuture channelFuture = new Bootstrap()
.group(group)
.channel(NioSocketChannel.class)
.handler(new ChannelInitializer<SocketChannel>() {
@Override
protected void initChannel(SocketChannel ch) throws Exception {
ch.pipeline().addLast(new ProtocolFrameDecoder());
ch.pipeline().addLast(loggingHandler);
ch.pipeline().addLast(messageCodecSharable);
ch.pipeline().addLast(rpcResponseMessageHandler);
}
})
.connect("127.0.0.1", 6666)
.sync();
channel = channelFuture.channel();
channel.closeFuture().addListener((ChannelFutureListener) f -> group.shutdownGracefully());
} catch (Exception e) {
log.error("client error ", e);
}
}
}
我们重新看一下代码，我们客户端每次发送消息的时候都需要new一个RpcRequestMessage，里面传递的参数实在太多了，很不友好，本来sayHello只需要一行就能搞定，我们去调用的时候反而搞得很复杂，所以可以尝试将其使用代理的方式抽离出来，具体细节，可以看注释
/**
* @param serviceClass 需要调用的远程方法接口Class对象
* @return java.lang.Object 返回代理对象
* @description 获取远程方法调用的接口代理类
*/
private static Object getProxyService(Class<?> serviceClass) {
ClassLoader classLoader = serviceClass.getClassLoader();
Class<?>[] interfaces = new Class[]{serviceClass};
// 1、参数1、需要目标代理类的ClassLoader对象
// 2、参数2、是需要代理的接口Class数组
// 3、参数3、是一个函数式接口实现类，使用lambda表达式，其中proxy为生成的代理对象，第二个为方法对象，第三个是参数列表
return Proxy.newProxyInstance(classLoader, interfaces, (proxy, method, args) -> {
//因为我们还需要拿到服务器返回的结果信息，我们使用了前面学到的Promise对象，对于每一次发送Rpc请求，都会产生一个对应的独一无二的Promise对象，那么这个sequenceId也需要卫衣，所以实现了一个自增的工具类
int id = SequenceIdGenerator.nextId();
RpcRequestMessage rpcRequestMessage = new RpcRequestMessage(
id,
serviceClass.getName(),
method.getName(),
method.getReturnType(),
method.getParameterTypes(),
args);
getChannel().writeAndFlush(rpcRequestMessage);
//创建这次Rpc请求所需要的Promise对象用于接收结果，参数为当前Promise异步接收结果的线程，如果我们使用listener的方式去接收的结果，其实去调用这个Listener的线程也是eventLoop中的线程
Promise<Object> promise = new DefaultPromise<>(getChannel().eventLoop());
//将当前Promise传送到响应处理类中的一个Map
PROMISE_MAP.put(id, promise);
promise.await();
if (promise.isSuccess()) {
return promise.getNow();
} else {
throw new RuntimeException(promise.cause());
}
});
}
其中，SequenceIdGenerator如下
/**
* @author PengHuanZhi
* @date 2021年12月05日 17:01
*/
public abstract class SequenceIdGenerator {
private static final AtomicInteger ID = new AtomicInteger();
public static int nextId() {
return ID.incrementAndGet();
}
}
还需要在响应处理器中加入一个Map，并且在处理响应后，将返回值放入对应的Promise中
/**
* @author PengHuanZhi
* @date 2021年12月05日 11:07
*/
@Slf4j
@ChannelHandler.Sharable
public class RpcResponseMessageHandler extends SimpleChannelInboundHandler<RpcResponseMessage> {
public final static Map<Integer, Promise<Object>> PROMISE_MAP = new ConcurrentHashMap<>();
@Override
protected void channelRead0(ChannelHandlerContext ctx, RpcResponseMessage msg) throws Exception {
log.info("msg : {}", msg);
//因为用完后已经没用了，所以可以移除
Promise<Object> promise = PROMISE_MAP.remove(msg.getSequenceId());
if (promise == null) {
return;
}
Exception exceptionValue = msg.getExceptionValue();
if (exceptionValue == null) {
promise.setSuccess(msg.getReturnValue());
} else {
promise.setFailure(exceptionValue);
}
}
}
最后测试一下
public static void main(String[] args) {
HelloService helloService = (HelloService) getProxyService(HelloService.class);
System.out.println(helloService.sayHello("zhangsan"));
}
9.8、异常处理
我们在sayHello中添加一行异常代码
@Override
public String sayHello(String name) {
int i = 1 / 0;
return "你好呀," + name;
}
再次测试观察发现，服务端貌似把错误日志给发过来了，而且还很长，导致我们粘包半包处理器接受不了
原来是我们在发送服务器响应的时候，如果出现错误，就将错误的完整日志信息发送了，我们应该只讲关键信息发送到客户端即可：
@Override
protected void channelRead0(ChannelHandlerContext ctx, RpcRequestMessage msg) throws Exception {
RpcResponseMessage rpcResponseMessage = new RpcResponseMessage();
rpcResponseMessage.setSequenceId(msg.getSequenceId());
try {
HelloService service = (HelloService) ServicesFactory.getService(Class.forName(msg.getInterfaceName()));
Method method = service.getClass().getMethod(msg.getMethodName(), msg.getParameterTypes());
Object invoke = method.invoke(service, msg.getParameterValue());
rpcResponseMessage.setReturnValue(invoke);
} catch (Exception e) {
e.printStackTrace();
rpcResponseMessage.setExceptionValue(new Exception("远程方法调用错误 ： " + e.getCause().getMessage()));
}
ctx.writeAndFlush(rpcResponseMessage);
}
最后测试一下：
10、源码分析
10.1、启动流程
- 在服务端的bind方法打上断点，开始调试
进入bind方法后，跳过两个没有太大意义的代码，直接走到
io.netty.bootstrap.AbstractBootstrap#doBind方法上
- 其中initAndRegister可以视为调用了Nio原生的serverSocketChannel.open()方法初始化好一个Channel，然后再将这个Channel注册到一个Selector上面
- 然后调用doBind0方法，此方法可视为调用了serverSocketChannel.bind(new InetSocketAddress(8080,backlog))
private ChannelFuture doBind(final SocketAddress localAddress) {
// 1. 执行初始化和注册 regFuture 会由 initAndRegister 设置其是否完成，从而回调 3.2 处代码
final ChannelFuture regFuture = initAndRegister();
final Channel channel = regFuture.channel();
if (regFuture.cause() != null) {
return regFuture;
}
// 2. 因为是 initAndRegister 异步执行，需要分两种情况来看，调试时也需要通过 suspend 断点类型加以区分
// 2.1 如果已经完成
if (regFuture.isDone()) {
ChannelPromise promise = channel.newPromise();
// 3.1 立刻调用 doBind0，由Main线程执行
doBind0(regFuture, channel, localAddress, promise);
return promise;
}
// 2.2 还没有完成
else {
final PendingRegistrationPromise promise = new PendingRegistrationPromise(channel);
// 3.2 回调 doBind0 由Nio线程去完成
regFuture.addListener(new ChannelFutureListener() {
@Override
public void operationComplete(ChannelFuture future) throws Exception {
Throwable cause = future.cause();
if (cause != null) {
// 处理异常...
promise.setFailure(cause);
} else {
promise.registered();
// 3. 由注册线程去执行 doBind0
doBind0(regFuture, channel, localAddress, promise);
}
}
});
return promise;
}
}
10.1.1、创建Channel
现在我们进入initAndRegister方法
final ChannelFuture initAndRegister() {
Channel channel = null;
try {
channel = channelFactory.newChannel();
// 1.1 初始化 - 做的事就是添加一个初始化器 ChannelInitializer
init(channel);
} catch (Throwable t) {
// 处理异常...
return new DefaultChannelPromise(new FailedChannel(), GlobalEventExecutor.INSTANCE).setFailure(t);
}
// 1.2 注册 - 做的事就是将原生 channel 注册到 selector 上
ChannelFuture regFuture = config().group().register(channel);
if (regFuture.cause() != null) {
// 处理异常...
}
return regFuture;
}
- 其中调用了一个ChannelFactory的对象去newChannel，这一步肯定就是在创建serverSocketChannel对象，我们进去看看
- 发现调用了NioServerSocketChannel的一个无参构造方法，我们直接去找这个方法，在这个方法中打一个断点，然后让代码走到这里
- 再进入这个newSocket方法看看
- 发现调用了一个provider去open的一个ServerSockerChannel，我们对比一下原生NIO中是怎么创建ServerSockerChannel的
- 约等于一样哈哈哈哈，回到最开始的newChannel方法走下去
然后进入下一行init(channel)方法，这一步只是给我们的NioServerSocketChannel添加了一个初始化Channel的方法，所以这一步还不会执行，先放下打个断点，待会再看
// 这里 channel 实际上是 NioServerSocketChannel
void init(Channel channel) throws Exception {
(...)
// 为 NioServerSocketChannel 添加初始化器
p.addLast(new ChannelInitializer<Channel>() {
@Override
public void initChannel(final Channel ch) throws Exception {
final ChannelPipeline pipeline = ch.pipeline();
ChannelHandler handler = config.handler();
if (handler != null) {
pipeline.addLast(handler);
}
// 初始化器的职责是将 ServerBootstrapAcceptor 加入至 NioServerSocketChannel
ch.eventLoop().execute(new Runnable() {
@Override
public void run() {
pipeline.addLast(new ServerBootstrapAcceptor(
ch, currentChildGroup, currentChildHandler, currentChildOptions, currentChildAttrs));
}
});
}
});
}
10.1.2、注册Selector
然后回到一开始，继续走代码，走到register方法
- register的方法链比较长，直接跳过一些意义不大的代码，一直走到
io.netty.channel.AbstractChannel.AbstractUnsafe#register，观察：
public final void register(EventLoop eventLoop, final ChannelPromise promise) {
// 一些检查，略...
AbstractChannel.this.eventLoop = eventLoop;
if (eventLoop.inEventLoop()) {
register0(promise);
} else {
try {
// 首次执行 execute 方法时，会启动 nio 线程，之后注册等操作在 nio 线程上执行
// 因为只有一个 NioServerSocketChannel 因此，也只会有一个 boss nio 线程
// 这行代码完成的事实是 main -> nio boss 线程的切换
eventLoop.execute(new Runnable() {
@Override
public void run() {
register0(promise);
}
});
} catch (Throwable t) {
// 日志记录...
closeForcibly();
closeFuture.setClosed();
safeSetFailure(promise, t);
}
}
}
-
我们现在一直处于Main线程中执行，所以直接会走else分支，所以会将当前register方法执行权交给了eventLoop线程，在register0方法上打一个断点，让代码走到这里（注意断点需要时多线程模式，然后从Main线程切换过来）
-
Netty源码中，一般带有do的方法，都是真正干活的，所以这里进入doRegister方法。
- 可以看到，终于调用了原生的ServerSocketChannel去注册Selector了，其中，Selector为第一个参数，它已经是由EventLoop管理了，第二个参数为关注事件，现在默认没有关注事件，后面会加，最后一个是附加附件，是一个Netty的NioServerSocketChannel，这样的绑定关系使以后这个ServerSocketChannel的事件都可以交由其对应的NioServerSocketChannel去处理，可以证明的是，真正去注册的是由Nio线程去做的
- 从doRegister方法出来，再关注一个代码
pipeline.invokeHandlerAddedIfNeeded();
private void register0(ChannelPromise promise) {
try {
if (!promise.setUncancellable() || !ensureOpen(promise)) {
return;
}
boolean firstRegistration = neverRegistered;
// 1.2.1 原生的 nio channel 绑定到 selector 上，注意此时没有注册 selector 关注事件，附件为 NioServerSocketChannel
doRegister();
neverRegistered = false;
registered = true;
// 1.2.2 执行 NioServerSocketChannel 初始化器的 initChannel
pipeline.invokeHandlerAddedIfNeeded();
// 回调 3.2 io.netty.bootstrap.AbstractBootstrap#doBind0
safeSetSuccess(promise);
pipeline.fireChannelRegistered();
// 对应 server socket channel 还未绑定，isActive 为 false
if (isActive()) {
if (firstRegistration) {
pipeline.fireChannelActive();
} else if (config().isAutoRead()) {
beginRead();
}
}
} catch (Throwable t) {
// Close the channel directly to avoid FD leak.
closeForcibly();
closeFuture.setClosed();
safeSetFailure(promise, t);
}
}
- 我们直接走过这行代码，发现走回了刚才我们添加的一个initChannel的事件
-
可以看到，这个事件中，又向EventLoop中添加了一个Acceptor的处理器，这个处理器可以处理以后所发生的accept事件，然后建立连接
-
至此，我们相当于已经做好了initAndRegister方法，那么我们回到最一开始的doBind方法，什么时候会去调用doBind0方法呢，答案就在当前的register0方法的一行为
safeSetSuccess(promise);的代码
10.1.3、绑定
- 它会将当前线程的结果给promise对象，然后回调最开始的promise的operationComplete方法
- 如何证明这两个promise对象是同一个呢，切换到Main线程看一下当前的promise对象是谁
- 切换到Nio线程，再看一下
- 得证
回到最开始，我们进入doBind0方法
// 3.1 或 3.2 执行 doBind0
private static void doBind0(
final ChannelFuture regFuture, final Channel channel,
final SocketAddress localAddress, final ChannelPromise promise) {
channel.eventLoop().execute(new Runnable() {
@Override
public void run() {
if (regFuture.isSuccess()) {
channel.bind(localAddress, promise).addListener(ChannelFutureListener.CLOSE_ON_FAILURE);
} else {
promise.setFailure(regFuture.cause());
}
}
});
}
- 可以看到，又调用了eventLoop去执行了bind方法，保证bind在nio线程中执行，我们断点打到这个地方，注意线程切换，这个bind方法调用链也比较长，直接跳过一部分，进入
io.netty.channel.AbstractChannel.AbstractUnsafe#bind
public final void bind(final SocketAddress localAddress, final ChannelPromise promise) {
assertEventLoop();
if (!promise.setUncancellable() || !ensureOpen(promise)) {
return;
}
if (Boolean.TRUE.equals(config().getOption(ChannelOption.SO_BROADCAST)) &&
localAddress instanceof InetSocketAddress &&
!((InetSocketAddress) localAddress).getAddress().isAnyLocalAddress() &&
!PlatformDependent.isWindows() && !PlatformDependent.maybeSuperUser()) {
// 记录日志...
}
boolean wasActive = isActive();
try {
// 3.3 执行端口绑定
doBind(localAddress);
} catch (Throwable t) {
safeSetFailure(promise, t);
closeIfClosed();
return;
}
if (!wasActive && isActive()) {
invokeLater(new Runnable() {
@Override
public void run() {
// 3.4 触发 active 事件
pipeline.fireChannelActive();
}
});
}
safeSetSuccess(promise);
}
- 然后可以看到里面会有一个doBind方法，由此可见，这个方法应该是真正执行Bind操作的代码，进入看看，发现这里是真正调用原生Channel去bind
至此，bind方法也执行完毕了，回到上一层代码
if (!wasActive && isActive()) {
invokeLater(new Runnable() {
@Override
public void run() {
// 3.4 触发 active 事件
pipeline.fireChannelActive();
}
});
}
- 当前serverSocketChannel经过前面一系列的操作，已经可用了，然后就会让流水线上的所有Handler都执行以下Active事件，实际上也就只有HeadContex这个Handler做了一些有意义的工作，这里找到它的Active事件，并在内部打上断点
- 主要进入readIfIsAutoRead方法，这一步会给我们的selectionKey添加一个accept的关心事件，因为我们前面创建selectionKey的时候，还没有指定关心事件呢，这里的方法链也比较长，直接走到
io.netty.channel.nio.AbstractNioChannel#doBeginRead
10.2、NioEventLoop
这个类算是Netty中的一个重量级的类了，NioEventLoop的重要组成是Selector，线程和任务队列，它不仅仅会处理IO事件，还会处理普通任务和定时任务
10.2.1、创建Selector
打开NioEventLoop源码，直接找到它的构造方法
- 发现其中会调用openSelector方法创建相关的Selector，也就是说Selector会在NioEventLoop的构造方法中创建，进去看一下
- 对比原生的Selector是如何创建的
- 可以发现几乎是一样的吧，但是问题是，真正的JavaNio的Selector它用了unwrappedSelector去标识，而NioEventLoop中还有一个名称就为Selector的Selector
- 为什么会有两个呢？因为原生Selector中保存了SelectionKey，是用HashSet存放的，但是Netty任务，HashSet的效率并不高，所以它把它扒拉下来用了一个数组实现，在刚才创建Selector的代码往下拉几行：
- 最后将造好的数据放入到了一个SelectorTuple中
- 其中SelectorTuple
private static final class SelectorTuple {
final Selector unwrappedSelector;
final Selector selector;
SelectorTuple(Selector unwrappedSelector) {
this.unwrappedSelector = unwrappedSelector;
this.selector = unwrappedSelector;
}
SelectorTuple(Selector unwrappedSelector, Selector selector) {
this.unwrappedSelector = unwrappedSelector;
this.selector = selector;
}
}
- 所以NioEventLoop中的unwrappedSelector就是替换Set后的原生Selector，而Selector便是一个SelectedSelectionKeySetSelector，而这个对象有两个字段一个是原生Selector, 一个是netty新的容器SelectedSelectionKeySet
10.2.2、NioEventLoop中的线程何时被启动
使用一个简单测试代码，向其中提交一个HelloWorld任务
EventLoop eventLoop = new NioEventLoopGroup().next();
eventLoop.execute(() -> {
System.out.println("Hello World");
});
- 在execute方法打个断点，然后debug进入该方法
public void execute(Runnable task) {
if (task == null) {
throw new NullPointerException("task");
}
//判断当前线程是否为Nio线程，现在还是Main线程
boolean inEventLoop = inEventLoop();
// 添加任务，其中队列使用了 jctools 提供的 mpsc 无锁队列
addTask(task);
//所以肯定会走进去
if (!inEventLoop) {
// inEventLoop 如果为 false 表示由其它线程来调用 execute，即首次调用，这时需要向 eventLoop 提交首个任务，启动死循环，会执行到下面的 doStartThread
startThread();
if (isShutdown()) {
// 如果已经 shutdown，做拒绝逻辑，代码略...
}
}
if (!addTaskWakesUp && wakesUpForTask(task)) {
// 如果线程由于 IO select 阻塞了，添加的任务的线程需要负责唤醒 NioEventLoop 线程
wakeup(inEventLoop);
}
}
- 首先就会判断任务是否为空，如果部位空，马上就会校验是否是Main函数调用，如果是，则证明是首次调用，首次调用才会开启线程执行这个任务，断点进入startThread()
- 进入分支后，马上使用CAS原子操作更改当前线程状态未启动，保证了真正启动线程的代码只会执行一遍，进入doStartThread方法
- 这个方法就会调用当前EventLoop中的executor去执行任务，并将执行器的线程赋值给了当前EventLoop的thread，然后就会从Main线程切换到这个Nio线程
private void doStartThread() {
assert thread == null;
executor.execute(new Runnable() {
@Override
public void run() {
// 将线程池的当前线程保存在成员变量中，以便后续使用
thread = Thread.currentThread();
if (interrupted) {
thread.interrupt();
}
boolean success = false;
updateLastExecutionTime();
try {
// 调用外部类 SingleThreadEventExecutor 的 run 方法，进入死循环，run 方法见下
SingleThreadEventExecutor.this.run();
success = true;
} catch (Throwable t) {
logger.warn("Unexpected exception from an event executor: ", t);
} finally {
// 清理工作，代码略...
}
}
});
}
- 进入
SingleThreadEventExecutor.this.run();这个方法主要是执行死循环，不断看有没有新任务，有没有新的IO事件
protected void run() {
for (;;) {
try {
try {
//...
case SelectStrategy.SELECT:
// 因为 IO 线程和提交任务线程都有可能执行 wakeup，而 wakeup 属于比较昂贵的操作，因此使用了一个原子布尔对象 wakenUp，它取值为 true 时，表示该由当前线程唤醒
// 进行 select 阻塞，并设置唤醒状态为 false
boolean oldWakenUp = wakenUp.getAndSet(false);
// 如果在这个位置，非 EventLoop 线程抢先将 wakenUp 置为 true，并 wakeup
// 下面的 select 方法不会阻塞
// 等 runAllTasks 处理完成后，到再循环进来这个阶段新增的任务会不会及时执行呢?
// 因为 oldWakenUp 为 true，因此下面的 select 方法就会阻塞，直到超时
// 才能执行，让 select 方法无谓阻塞
select(oldWakenUp);
if (wakenUp.get()) {
selector.wakeup();
}
default:
}
} catch (IOException e) {
rebuildSelector0();
handleLoopException(e);
continue;
}
//...
}
}
接下来关注这行代码，当触发了Select事件后，会调用这行代码进行Select监听事件（IO或者普通事件）
- 进入方法
- 在传统selector调用select方法的时候用的是无参的方法，一直阻塞，Netty为了不只是处理IO事件，还需要处理普通事件，所以这里不能一直阻塞，它会阻塞一段时间自动放弃重新进入死循环，那么提交普通任务的时候会不会让这个阻塞结束呢，还是等他自己超时？我们看看**execute(Runnable run)**方法
10.2.3、wakeup的理解
从上面代码我们进入wakeup的方法实现，注意不能直接点进去，要找NioEventLoop的实现方法
- 对于其他线程提交的任务，才会执行唤醒，如果是自己Nio的线程提交的任务，则不会，具体唤醒自己会有相应的机制逻辑，不用操心
- 后面唤醒操作用了一个原子操作去控制，所以如果多个任务同时提交，保证了每次只唤醒一次，毕竟唤醒动作也是重量级操作
10.2.4、何时进入SelectStrategy.SELECT
回到
SingleThreadEventExecutor.this.run();方法
// calculateStrategy 的逻辑如下：
// 有任务，会执行一次 selectNow，清除上一次的 wakeup 结果，无论有没有 IO 事件，都会跳过 switch
// 没有任务，会匹配 SelectStrategy.SELECT，看是否应当阻塞
switch (selectStrategy.calculateStrategy(selectNowSupplier, hasTasks())) {
SelectStrategy具体会走哪一个分支，取决于上面这行代码，我们进去看看（注意走实现类）
会判断当前是否有任务，有任务则不会进入select去阻塞，如果没有才会进去，如果有任务的时候调用的**get()**方法是什么样子，我们也去看一下
所以不会阻塞，立刻拿事件
10.2.5、解决Nio空轮询Bug
在某些场景下（在Linux环境下），select方法会阻塞失败，会一直无限的重复循环执行，如果Nio线程众多，都出现了这个bug后，会导致CPU占用极高，Netty定义了一个临时变量selectCnt，在每次循环都会加1，如果空轮询到一定程度就会超过阈值，直接重新创建一个Selector，替换原来的Selector
private void select(boolean oldWakenUp) throws IOException {
Selector selector = this.selector;
try {
int selectCnt = 0;
long currentTimeNanos = System.nanoTime();
// 计算等待时间
// * 没有 scheduledTask，超时时间为 1s
// * 有 scheduledTask，超时时间为 `下一个定时任务执行时间 - 当前时间`
long selectDeadLineNanos = currentTimeNanos + delayNanos(currentTimeNanos);
for (;;) {
long timeoutMillis = (selectDeadLineNanos - currentTimeNanos + 500000L) / 1000000L;
// 如果超时，退出循环
if (timeoutMillis <= 0) {
if (selectCnt == 0) {
selector.selectNow();
selectCnt = 1;
}
break;
}
// 如果期间又有 task 退出循环，如果没这个判断，那么任务就会等到下次 select 超时时才能被执行
// wakenUp.compareAndSet(false, true) 是让非 NioEventLoop 不必再执行 wakeup
if (hasTasks() && wakenUp.compareAndSet(false, true)) {
selector.selectNow();
selectCnt = 1;
break;
}
// select 有限时阻塞
// 注意 nio 有 bug，当 bug 出现时，select 方法即使没有时间发生，也不会阻塞住，导致不断空轮询，cpu 占用 100%
int selectedKeys = selector.select(timeoutMillis);
// 计数加 1
selectCnt ++;
// 醒来后，如果有 IO 事件、或是由非 EventLoop 线程唤醒，或者有任务，退出循环
if (selectedKeys != 0 || oldWakenUp || wakenUp.get() || hasTasks() || hasScheduledTasks()) {
break;
}
if (Thread.interrupted()) {
// 线程被打断，退出循环
// 记录日志
selectCnt = 1;
break;
}
long time = System.nanoTime();
if (time - TimeUnit.MILLISECONDS.toNanos(timeoutMillis) >= currentTimeNanos) {
// 如果超时，计数重置为 1，下次循环就会 break
selectCnt = 1;
}
// 计数超过阈值，由 io.netty.selectorAutoRebuildThreshold 指定，默认 512
// 这是为了解决 nio 空轮询 bug
else if (SELECTOR_AUTO_REBUILD_THRESHOLD > 0 &&
selectCnt >= SELECTOR_AUTO_REBUILD_THRESHOLD) {
// 重建 selector
selector = selectRebuildSelector(selectCnt);
selectCnt = 1;
break;
}
currentTimeNanos = time;
}
if (selectCnt > MIN_PREMATURE_SELECTOR_RETURNS) {
// 记录日志
}
} catch (CancelledKeyException e) {
// 记录日志
}
}
10.2.6、ioRatio
在SelectStrategy的若干事件发生后，我们需要去根据SelectionKey去处理这些事件，由于NioEventLoop是一个单线程，所以其中执行普通任务和IO任务的时候，都是顺序执行的，代码如下（仍然还在NioEventLoop源码中）
// ioRatio 默认是 50
final int ioRatio = this.ioRatio;
if (ioRatio == 100) {
try {
processSelectedKeys();
} finally {
// ioRatio 为 100 时，总是运行完所有非 IO 任务
runAllTasks();
}
} else {
final long ioStartTime = System.nanoTime();
try {
processSelectedKeys();
} finally {
// 记录 io 事件处理耗时
final long ioTime = System.nanoTime() - ioStartTime;
// 运行非 IO 任务，一旦超时会退出 runAllTasks
runAllTasks(ioTime * (100 - ioRatio) / ioRatio);
}
}
} catch (Throwable t) {
handleLoopException(t);
}
10.2.7、如何判断事件类型的
上面代码出现了很多次的processSelectedKeys方法，我们进去看看
- 不为空才会总这个代码，进去看看
- 可以看到是用Netty改进后的数组的方式取得的key，还记得我们上面讲过，这里的
k.attachement()方法拿到的就是我们的Channel对象，这样我们才能获取到Channel上面的若干时间，我们进入processSelectedKey(k, (AbstractNioChannel) a);
- 处理各种事件的代码就在这里
10.3、Accept流程
回到上面看EventLoop代码中判断事件类型的代码，在最下面一个accept事件发生后的位置打上断点，然后开启一个服务端和客户端
- 进入该方法
public void read() {
//...
try {
try {
do {
// doReadMessages 中执行了 accept 并创建 NioSocketChannel 作为消息放入 readBuf
// readBuf 是一个 ArrayList 用来缓存消息
int localRead = doReadMessages(readBuf);
if (localRead == 0) {
break;
}
if (localRead < 0) {
closed = true;
break;
}
// localRead 为 1，就一条消息，即接收一个客户端连接
allocHandle.incMessagesRead(localRead);
} while (allocHandle.continueReading());
} catch (Throwable t) {
exception = t;
}
int size = readBuf.size();
for (int i = 0; i < size; i ++) {
readPending = false;
// 触发 read 事件，让 pipeline 上的 handler 处理，这时是处理
// io.netty.bootstrap.ServerBootstrap.ServerBootstrapAcceptor#channelRead
pipeline.fireChannelRead(readBuf.get(i));
}
readBuf.clear();
allocHandle.readComplete();
pipeline.fireChannelReadComplete();
if (exception != null) {
closed = closeOnReadError(exception);
pipeline.fireExceptionCaught(exception);
}
if (closed) {
inputShutdown = true;
if (isOpen()) {
close(voidPromise());
}
}
} finally {
if (!readPending && !config.isAutoRead()) {
removeReadOp();
}
}
}
- 走到doReadMessages方法
- 可以看到，这里便创建好了一个NioSocketChannel，其中还将原生的SocketChannel传入绑定进去了，创建好后便将其放入一个List集合中，便于后面的pipeline的handler处理，然后，doReadMessages方法便返回了
- 继续向下执行
- 马上就会将其放入流水线上面去执行处理这个连接，那么流水线上有head，创建好的acceptor，和tail三个处理器，很明显处理这个连接请求的应该是acceptor，我们直接找到这个acceptor，它在ServerBootstrap类中，是一个静态内部类，名为ServerBootstrapAcceptor
- 在其中我们直接找到读事件打个断点
public void channelRead(ChannelHandlerContext ctx, Object msg) {
// 这时的 msg 是 NioSocketChannel
final Channel child = (Channel) msg;
// NioSocketChannel 添加 childHandler 即初始化器
child.pipeline().addLast(childHandler);
// 设置选项
setChannelOptions(child, childOptions, logger);
for (Entry<AttributeKey<?>, Object> e: childAttrs) {
child.attr((AttributeKey<Object>) e.getKey()).set(e.getValue());
}
try {
// 注册 NioSocketChannel 到 nio worker 线程，接下来的处理也移交至 nio worker 线程
childGroup.register(child).addListener(new ChannelFutureListener() {
@Override
public void operationComplete(ChannelFuture future) throws Exception {
if (!future.isSuccess()) {
forceClose(child, future.cause());
}
}
});
} catch (Throwable t) {
forceClose(child, t);
}
}
- 其中
childGroup.register(child).addListener(new ChannelFutureListener() {便可以将当前Channel与Nio线程进行绑定，我们进去看看，方法链略多，其中注意下面这里，调用了next去执行注册，也就是说，现在派发出了一个新的worker线程去注册
- 直接走到
io.netty.channel.AbstractChannel.AbstractUnsafe#register
public final void register(EventLoop eventLoop, final ChannelPromise promise) {
// 一些检查，略...
AbstractChannel.this.eventLoop = eventLoop;
if (eventLoop.inEventLoop()) {
register0(promise);
} else {
try {
// 这行代码完成的事实是 nio boss -> nio worker 线程的切换
eventLoop.execute(new Runnable() {
@Override
public void run() {
register0(promise);
}
});
} catch (Throwable t) {
// 日志记录...
closeForcibly();
closeFuture.setClosed();
safeSetFailure(promise, t);
}
}
}
- eventLoop.inEventLoop()判断，当前的线程未ServerSocket的线程，还不是自己的worker线程，所以会走else分支，进入register0方法，在其中找到doRegister方法（doXXX都是实际干活的方法）
- 然后可以看到，终于将当前Channel和Nio线程绑定到一块了
- 回到register0方法，doRegister();绑定完毕，接着就会执行新的channel上面的的初始化操作
- 在服务端的initChannel方法打个断点
- 回到刚才的代码，继续往下走
-
可以看到，初始化事件做了之后，还会执行Active事件，目前我们的SelectionKey还没有关注任何事件，这一行代码便可以将read事件给添加进去，方法调用链比较长，最后会走到
io.netty.channel.nio.AbstractNioChannel#doBeginRead
-
可以看到，开始时0，没有任何事件，再加一个读1事件
10.4、Read事件
在客户端连接后，马上发送一条消息给服务端，断点和Accept流程一致
- 第一次直接跳过，因为时Accept事件，第二次走到这儿再观察
- 进入read代码
public final void read() {
final ChannelConfig config = config();
if (shouldBreakReadReady(config)) {
clearReadPending();
return;
}
final ChannelPipeline pipeline = pipeline();
// io.netty.allocator.type 决定 allocator 的实现
final ByteBufAllocator allocator = config.getAllocator();
// 用来分配 byteBuf，确定单次读取大小
final RecvByteBufAllocator.Handle allocHandle = recvBufAllocHandle();
allocHandle.reset(config);
ByteBuf byteBuf = null;
boolean close = false;
try {
do {
byteBuf = allocHandle.allocate(allocator);
// 读取
allocHandle.lastBytesRead(doReadBytes(byteBuf));
if (allocHandle.lastBytesRead() <= 0) {
byteBuf.release();
byteBuf = null;
close = allocHandle.lastBytesRead() < 0;
if (close) {
readPending = false;
}
break;
}
allocHandle.incMessagesRead(1);
readPending = false;
// 触发 read 事件，让 pipeline 上的 handler 处理，这时是处理 NioSocketChannel 上的 handler
pipeline.fireChannelRead(byteBuf);
byteBuf = null;
}
// 是否要继续循环
while (allocHandle.continueReading());
allocHandle.readComplete();
// 触发 read complete 事件
pipeline.fireChannelReadComplete();
if (close) {
closeOnRead(pipeline);
}
} catch (Throwable t) {
handleReadException(pipeline, byteBuf, t, close, allocHandle);
} finally {
if (!readPending && !config.isAutoRead()) {
removeReadOp();
}
}
}
- 还没执行的时候，观察这个Buf的大小和读写指针位置
- 将这行代码走完，再看
- 读到了内容了，继续走
- 现在就可以调用Channel流水线上的处理器进行处理了
11、备注
11.1、日志问题
配置了LoggingHandler，控制台始终没有日志信息打印，只显示客户端的绑定解绑绑定解绑。。。。
一直用的8080端口做Demo，强迫症晚期查了几个小时，我改个端口8888就好使了？？？这是什么神仙问题
扫一扫
270
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
