1. 线程模型基本介绍
- 不同的线程模式,对程序的性能有很大影响,为了搞清Netty 线程模式,我们来系统的讲解下 各个线程模式, 最后看看Netty 线程模型有什么优越性.
- 目前存在的线程模型有:
- 传统阻塞 I/O 服务模型
- Reactor 模式
- 根据 Reactor 的数量和处理资源池线程的数量不同,有3 种典型的实现
- 单 Reactor 单线程;
- 单 Reactor 多线程;
- 主从 Reactor 多线程
- Netty 线程模式(Netty 主要基于主从 Reactor 多线程模型做了一定的改进,其中主从Reactor 多线程模型有多个 Reactor)
2. 传统阻塞 I/O 服务模型
2.1 工作原理图
- 蓝色的框表示线程
- 黄色的框表示对象,
- 白色的框表示方法(API)
2.2 模型特点
- 采用阻塞IO模式获取输入的数据
- 每个连接都需要独立的线程完成数据的输入,业务处理, 数据返回
2.3 问题分析
- 当并发数很大,就会创建大量的线程,占用很大系统资源
- 连接创建后,如果当前线程暂时没有数据可读,该线程 会阻塞在read 操作,造成线程资源浪费
3. Reactor 模式
3.1 针对传统阻塞 I/O 服务模型的 2 个缺点,解决方案:
- 基于 I/O 复用模型:多个连接共用一个阻塞对象,应用程序只需要在一个阻塞对象等待,无需阻塞等待所有连接。当某个连接有新的数据可以处理时,操作系统通知应用程序,线程从阻塞状态返回,开始进行业务处理Reactor 对应的叫法: 1.
反应器模式
2.分发者模式(Dispatcher)
3.通知者模式(notifier)
- 基于线程池复用线程资源:不必再为每个连接创建线程,将连接完成后的业务处理任务分配给线程进行处理,一个线程可以处理多个连接的业务。
3.2 I/O 复用结合线程池,就是 Reactor 模式基本设计思想, 如图:
- Reactor 模式,通过一个或多个输 入同时传递给服务处理器的模式 (基于事件驱动)
- 服务器端程序处理传入的多个请求, 并将它们同步分派到相应的处理线 程, 因此Reactor模式也叫 Dispatcher模式
- Reactor 模式使用IO复用监听事件, 收到事件后,分发给某个线程(进程), 这点就是网络服务器高并发处 理关键
3.3 Reactor 模式中 核心组成:
Reactor
:Reactor 在一个单独的线程中运行,负责监听和分发事件,分发给适当的处理程序来对 IO 事件做出反应。 它就像公司的电话接线员,它接听来自客户的电话并将线路转移到适当的联系人;Handlers
:处理程序执行 I/O 事件要完成的实际事件,类似于客户想要与之交谈的公司中的实际官员。Reactor 通过调度适当的处理程序来响应I/O事件,处理程序执行非阻塞操作。
3.4 单 Reactor 单线程
3.4.1 工作原理及示意图
- Select 是前面 I/O 复用模型介绍的标准网络编程API,可以实现应用程序通过一个阻塞对象监听多路连接请求
- Reactor 对象通过 Select 监控客户端请求事件,收到事件后通过Dispatch进行分发
- 如果是建立连接请求事件,则由 Acceptor 通过Accept 处理连接请求,然后创建一个Handler 对象处理连接完成后的后续业务处理
- 如果不是建立连接事件,则 Reactor 会分发调用连接对应的Handler 来响应
- Handler 会完成 Read→业务处理→Send 的完整业务流程
在
Netty核心技术三
中第四章节的应用实例六--群聊系统
就是单 Reactor 单线程
- 结合实例:服务器端用一个线程通过多路复用搞定所有的IO 操作(包括连接,读、写等),编码简单,清晰明了,但是如果客户端连接数量较多,将无法支撑,前面的NIO案例就属于这种模型。
- 但是实例中没有写对应的handler,只需要将对应处理方法封装为一个个的handler就与图中一致了
3.4.2 方案优缺点分析
- 优点:模型简单,没有多线程、进程通信、竞争的问题,全部都在一个线程中完成
- 缺点:性能问题,只有一个线程,无法完全发挥多核CPU 的性能。Handler 在处理某个连接上的业务时,整个进程无法处理其他连接事件,很容易导致性能瓶颈
- 缺点:可靠性问题,线程意外终止,或者进入死循环,会导致整个系统通信模块不可用,不能接收和处理外部消息,造成节点故障
- 使用场景:客户端的数量有限,业务处理非常快速,比如Redis在业务处理的时间复杂度 O(1) 的情况
3.5 单Reactor多线程
3.5.1 工作原理及示意图
- Reactor 对象通过select 监控客户端请求 事件, 收到事件后,通过dispatch进行分发
- 如果建立连接请求, 则右Acceptor 通过 accept 处理连接请求, 然后创建一个Handler对象处理完成连接后的各种事件
- 如果不是连接请求,则由reactor分发调用连接对 应的handler 来处理
- handler 只负责响应事件,不做具体的业务处理, 通过read 读取数据后,会分发给后面的worker线 程池的某个线程处理业务
- worker 线程池会分配独立线程完成真正的业务, 并将结果返回给handler
- handler收到响应后,通过send 将结果返回给 client
3.5.2 方案优缺点分析
- 优点:可以充分的利用多核cpu 的处理能力
- 缺点:多线程数据共享和访问比较复杂, reactor 处理所有的事件的监听和响应,在单线程运行, 在高并发场景容易出现性能瓶颈.
3.6 主从 Reactor 多线程
3.6.1 工作原理及示意图
针对单 Reactor 多线程模型中,Reactor 在单线程中运 行,高并发场景下容易成为性能瓶颈,可以让 Reactor 在多线程中运行
- Reactor主线程 MainReactor 对象通过select 监听连接事件, 收 到事件后,通过Acceptor 处理连接事件
- 当 Acceptor 处理连接事件后,MainReactor 将连接分配给 SubReactor
- subreactor 将连接加入到连接队列进行监听,并创建handler 进行各种事件处理
- 当有新事件发生时, subreactor 就会调用对应的handler处 理
- handler 通过read 读取数据,分发给后面的worker 线程处理
- worker 线程池分配独立的worker 线程进行业务处理,并返 回结果
3.6.2 Scalable IO in Java 对 Multiple Reactors 的原理图解
3.6.3 方案优缺点说明
- 优点:父线程与子线程的数据交互简单职责明确,父线程只需要接收新连接,子线程完成后续的业务处理。
- 优点:父线程与子线程的数据交互简单,Reactor 主线程只需要把新连接传给子线程,子线程无需返回数据。
- 缺点:编程复杂度较高
结合实例:这种模型在许多项目中广泛使用,包括Nginx 主从Reactor 多进程模型,Memcached 主从多线程,Netty 主从多线程模型的支持
3.7 Reactor 模式小结
- 响应快,不必为单个同步时间所阻塞,虽然 Reactor 本身依然是同步的
- 可以最大程度的避免复杂的多线程及同步问题,并且避免了多线程/进程的切换开销
- 扩展性好,可以方便的通过增加 Reactor 实例个数来充分利用CPU资源
- 复用性好,Reactor 模型本身与具体事件处理逻辑无关,具有很高的复用性
4. Netty模型
4.1 工作原理示意图1-简单版
Netty 主要基于主从 Reactors 多线程模型(如图)做了一定的改进,其中主从Reactor多线程模型有多个 Reactor
- BossGroup 线程维护Selector , 只关注Accecpt
- 当接收到Accept事件,获取到对应的SocketChannel, 封装成NIOScoketChannel并注册到Worker 线程(事件循环), 并进行维护
- 当Worker线程监听到selector 中通道发生自己感兴趣的事件后,就进行处理(就由handler),注意handler 已经加入到通道
4.2 工作原理示意图2-进阶版
Netty 主要基于主从 Reactors 多线程模型(如 图)做了一定的改进,其 中主从 Reactor 多线程模 型有多个 Reacto
- BossGroup 中有多个循环事件NioEventLoop,每一个NioEventLoop都有一个selector
- WorkerGroup 中有多个循环事件NioEventLoop,每一个NioEventLoop都有一个selector
- 较之简单版:一个BossGroup 或者WorkerGroup 可以有多个selector,每一个selector由一个循环事件NioEventLoop来封装执行
4.3 工作原理示意图-详细版
下图中的标识有些不准确:
- NioEventGroup应为NioEventLoop
- BossGroup和NioEventLoop之间应该再包一层NioEventLoopGroup
- Netty抽象出两组线程池 BossGroup 专门负责接收客户端的连接, WorkerGroup 专门负责网络的读写
- BossGroup 和 WorkerGroup 类型都是 NioEventLoopGroup
- NioEventLoopGroup 相当于一个事件循环组, 这个组中含有多个事件循 环 ,每一个事件循环是 NioEventLoop
- NioEventLoop 表示一个不断循环的执行处理任务的线程, 每个 NioEventLoop 都有一个selector , 用于监听绑定在其上的socket的网络 通讯
- NioEventLoopGroup 可以有多个线程, 即可以含有多个NioEventLoop
- 每个Boss NioEventLoop 循环执行的步骤有3步
- 轮询accept 事件
- 处理accept 事件 , 与client建立连接 , 生成NioScocketChannel , 并将其 注册到某个worker NIOEventLoop 上的 selector
- 处理任务队列的任务 , 即 runAllTasks
- 每个 Worker NIOEventLoop 循环执行的步骤
- 轮询read, write 事件
- .处理I/O事件, 即read , write 事件,在对应NioScocketChannel 处理
- 处理任务队列的任务 , 即 runAllTasks
- 每个WorkerNIOEventLoop处理业务时,会使用pipeline(管道)
- pipeline中包含了channel,即通过pipeline可以获取到对应的通道;
- 管道中维护了很多处理器
5. Netty快速入门实例-TCP服务
实例要求:
- 使用IDEA 创建Netty项目
- Netty 服务器在 6668 端口监听,客户端能发送消息给服务器"hello, 服务器~"
- 服务器可以回复消息给客户端 “hello, 客户端~”
- 目的:对Netty 线程模型 有一个初步认识, 便于理解Netty 模型理论
- 编写服务端
- 编写客户端
- 对netty 程序进行分析,看看netty模型特点
5.1 引入依赖
我创建的项目是maven项目,所以我用maven的方式引入,但是我看maven仓库老师使用的版本有漏洞,我就使用的目前使用人最多的没有漏洞的版本
4.1.42.Final
<!-- https://mvnrepository.com/artifact/io.netty/netty-all -->
<dependency>
<groupId>io.netty</groupId>
<artifactId>netty-all</artifactId>
<version>4.1.42.Final</version>
</dependency>
5.2 服务端
5.2.1 服务端自定义handler
代码解读及注意:
自定义Handler需要继承ChannelInboundHandlerAdapter
该handler主要重新三个方法
channelRead(ChannelHandlerContext ctx, Object msg)
- ChannelHandlerContext ctx:上下文对象, 含有 管道pipeline , 通道channel, 地址
- Object msg: 就是客户端发送的数据 默认Object
- 读取通道时
channelReadComplete(ChannelHandlerContext ctx)
- 读取通道后
exceptionCaught(ChannelHandlerContext ctx, Throwable cause)
- 处理异常, 一般是需要关闭通道
ctx.writeAndFlush()方法:
- writeAndFlush 是 write + flush
package site.zhourui.nioAndNetty.netty;
import io.netty.buffer.ByteBuf;
import io.netty.buffer.Unpooled;
import io.netty.channel.ChannelHandlerContext;
import io.netty.channel.ChannelInboundHandlerAdapter;
import io.netty.util.CharsetUtil;
import java.nio.charset.StandardCharsets;
/*
说明
1. 我们自定义一个Handler 需要继续netty 规定好的某个HandlerAdapter(规范)
2. 这时我们自定义一个Handler , 才能称为一个handler
*/
public class NettyServerHandler extends ChannelInboundHandlerAdapter {
//读取数据实际(这里我们可以读取客户端发送的消息)
/*
1. ChannelHandlerContext ctx:上下文对象, 含有 管道pipeline , 通道channel, 地址
2. Object msg: 就是客户端发送的数据 默认Object
*/
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
System.out.println("server ctx =" + ctx);
//将 msg 转成一个 ByteBuf
//ByteBuf 是 Netty 提供的,不是 NIO 的 ByteBuffer.
ByteBuf buf = (ByteBuf) msg;
System.out.println("客户端发送消息是:" +buf.toString(StandardCharsets.UTF_8));
System.out.println("客户端地址:" + ctx.channel().remoteAddress());
}
//数据读取完毕
@Override
public void channelReadComplete(ChannelHandlerContext ctx) throws Exception {
//writeAndFlush 是 write + flush
//将数据写入到缓存,并刷新
//一般讲,我们对这个发送的数据进行编码
ctx.writeAndFlush(Unpooled.copiedBuffer("hello, 客户端~(>^ω^<)喵1", CharsetUtil.UTF_8));
}
//处理异常, 一般是需要关闭通道
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
ctx.close();
}
}
5.2.2 服务端
代码解读及注意:
服务端需要BossGroup 和 WorkerGroup
new NioEventLoopGroup();不填写参数时
- bossGroup 和 workerGroup 含有的子线程(NioEventLoop)的个数默认实际 cpu核数 * 2
创建服务器端的启动对象,配置参数
为启动参数设置BossGroup和 WorkerGroup两个线程组
第一个参数为bossGroup,第二个参数为WorkerGroup
配置什么通道来作为服务器的实现
设置bossGroup的额外参数
设置WorkerGroup的额外参数
为WorkerGroup添加处理器
绑定一个端口并且同步, 生成了一个 ChannelFuture 对象
对关闭通道进行监听
最后不要忘了关闭BossGroup 和 WorkerGroup
package site.zhourui.nioAndNetty.netty;
import io.netty.buffer.ByteBuf;
import io.netty.buffer.Unpooled;
import io.netty.channel.Channel;
import io.netty.channel.ChannelHandlerContext;
import io.netty.channel.ChannelInboundHandlerAdapter;
import io.netty.channel.ChannelPipeline;
import io.netty.util.CharsetUtil;
import java.nio.charset.StandardCharsets;
/*
说明
1. 我们自定义一个Handler 需要继续netty 规定好的某个HandlerAdapter(规范)
2. 这时我们自定义一个Handler , 才能称为一个handler
*/
public class NettyServerHandler extends ChannelInboundHandlerAdapter {
//读取数据实际(这里我们可以读取客户端发送的消息)
/*
1. ChannelHandlerContext ctx:上下文对象, 含有 管道pipeline , 通道channel, 地址
2. Object msg: 就是客户端发送的数据 默认Object
*/
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
System.out.println("服务器读取线程 " + Thread.currentThread().getName() + " channle =" + ctx.channel());
System.out.println("server ctx =" + ctx);
System.out.println("看看channel 和 pipeline的关系");
Channel channel = ctx.channel();
ChannelPipeline pipeline = ctx.pipeline(); //本质是一个双向链接, 出站入站
//将 msg 转成一个 ByteBuf
//ByteBuf 是 Netty 提供的,不是 NIO 的 ByteBuffer.
ByteBuf buf = (ByteBuf) msg;
System.out.println("客户端发送消息是:" + buf.toString(CharsetUtil.UTF_8));
System.out.println("客户端地址:" + channel.remoteAddress());
}
//数据读取完毕
@Override
public void channelReadComplete(ChannelHandlerContext ctx) throws Exception {
//writeAndFlush 是 write + flush
//将数据写入到缓存,并刷新
//一般讲,我们对这个发送的数据进行编码
ctx.writeAndFlush(Unpooled.copiedBuffer("hello, 客户端~(>^ω^<)喵1", CharsetUtil.UTF_8));
}
//处理异常, 一般是需要关闭通道
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
ctx.close();
}
}
5.3 客户端
5.3.1 客户端自定义handler
该handler和服务端的handler规范一致,主要是看实现的业务如何从而选择重新对应的方法
- 通道启动时会向服务端发送一条信息
- 通道发生读事件时会打印服务端的地址及消息
package site.zhourui.nioAndNetty.netty;
import io.netty.buffer.ByteBuf;
import io.netty.buffer.Unpooled;
import io.netty.channel.ChannelHandlerContext;
import io.netty.channel.ChannelInboundHandlerAdapter;
import io.netty.util.CharsetUtil;
public class NettyClientHandler extends ChannelInboundHandlerAdapter {
//当通道就绪就会触发该方法
@Override
public void channelActive(ChannelHandlerContext ctx) throws Exception {
System.out.println("client ctx" + ctx);
ctx.writeAndFlush(Unpooled.copiedBuffer("hello, server: (>^ω^<)喵", CharsetUtil.UTF_8));
}
//当通道有读取事件时,会触发
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
ByteBuf buf = (ByteBuf) msg;
System.out.println("服务器回复的消息:" + buf.toString(CharsetUtil.UTF_8));
System.out.println("服务器的地址: "+ ctx.channel().remoteAddress());
}
//当通道有异常时触发
@Override
public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) throws Exception {
cause.printStackTrace();
ctx.close();
}
}
5.3.2 客户端
客户端与服务端基本都是一样的但有以下区别
- 客户端只需要一个事件循环组
- 注意客户端启动对象使用的不是 ServerBootstrap 而是 Bootstrap
- 客户端启动对象配置完成后是连接到服务器bootstrap.connect,而不是bootstrap.bind
package site.zhourui.nioAndNetty.netty;
import io.netty.bootstrap.Bootstrap;
import io.netty.channel.ChannelFuture;
import io.netty.channel.ChannelInitializer;
import io.netty.channel.nio.NioEventLoopGroup;
import io.netty.channel.socket.SocketChannel;
import io.netty.channel.socket.nio.NioSocketChannel;
public class NettyClient {
public static void main(String[] args) throws InterruptedException {
//客户端需要一个事件循环组
NioEventLoopGroup group = new NioEventLoopGroup();
try {
//创建客户端启动对象
//注意客户端使用的不是 ServerBootstrap 而是 Bootstrap
Bootstrap bootstrap = new Bootstrap();
bootstrap.group(group)
.channel(NioSocketChannel.class)
.handler(new ChannelInitializer<SocketChannel>() {
@Override
protected void initChannel(SocketChannel socketChannel) throws Exception {
socketChannel.pipeline().addLast(new NettyClientHandler());
}
});
System.out.println("客户端 ok..");
//启动客户端去连接服务器端
//关于 ChannelFuture 要分析,涉及到netty的异步模型
ChannelFuture cf = bootstrap.connect("127.0.0.1", 6668).sync();
//给关闭通道进行监听
cf.channel().closeFuture().sync();
}finally {
group.shutdownGracefully();
}
}
}
5.4 测试
5.4.1 普通测试
-
启动一个服务端
-
再启动一个客户端
5.4.2 验证:bossGroup 和 workerGroup 含有的子线程(NioEventLoop)的个数默认实际 cpu核数 * 2
5.4.2.1 源码分析
- 当我们不传入参数时默认值为0
- 实际上调用的方法是
MultithreadEventLoopGroup
,所以线程数为DEFAULT_EVENT_LOOP_THREADS
- 而DEFAULT_EVENT_LOOP_THREADS在静态代码块中赋值为NettyRuntime.availableProcessors() * 2
- 即为我们cpu核数*2
5.4.2.2 debug测试
我的cpu有24核
debug有48个NioEventLoop
5.4.3 workerGoup在NioEventLoop为8时,多个客户端与服务器进行通讯,workerGoup怎么将NioEventLoop进行分配
-
首先修改NettyServer的workerGoup和workerGoup的NioEventLoop数量为指定数量
-
连接第一个客户端
-
连接第二个客户端
-
连接第三个客户端
-
连接第八个客户端
-
连接第九个客户端
结论:workerGoup在NioEventLoop为8时,多个客户端与服务器进行通讯,workerGoup将按序分配NioEventLoop,如果超出NioEventLoop个数将会从头再次循环分配
5.4.4 一个NioEventLoop所含有的数据
5.4.5 ctx(ChannelHandlerContext ctx:上下文对象),pipeline和channel的关系
ctx数据
channel数据
pipeline数据
结论:
ctx中有head和tail说明是双向链表
可以通过ctx拿到pipeline,然后通过pipeline拿到channel
channel 和 pipeline是相互包含的关系
pipeline本质是一个双向链接, 出站入站,里面有head和tail