1.Channel
Channel可以理解为是socket连接,在客户端与服务端连接的时候就会建立一个Channel,它负责基本的IO操作(binf()、connect()、rad()、write()等);
1.1 Channel的作用
- 通过Channel可获得当前网络连接的通道状态;
- 通过Channel可获得网络连接的配置参数(缓冲区大小等);
- Channel提供异步的网络IO操作,如连接的建立、数据的读写、端口的绑定等;
1.2 Channel的类型
- NioSocketChannel:NIO的客户端TCP socket连接;
- NioServerSocketChannel:NIO的服务器端TCP socket连接;
- NioDatagramChannel:UDP连接;
- NioSctpChannel:客户端Sctp(一种传输层协议)连接;
- NioSctpServerChannel:Sctp服务器端连接;
2.Event Loop、Event Loop Group
有了Channel连接服务,消息就可以流动,针对消息在服务器上的出站入站产生事件,而EventLoop就是一个监控和协调事件的机制;
Netty中每个Channel都会分配一个EventLoop,一个EventLoop可以服务于多个Channel,每个EventLoop会占用一个线程,同时这个线程会处理Event Loop上面发生的所有IO操作和事件;
而EventLoopGroup是用来生成EventLoop的,默认线程数为CPU核数*2;
3.ChannelHandler
数据的入站和出站的业务逻辑都是在ChannelHandler中,针对出入站分为ChannelInboundHandler(入站事件处理器)和ChannelOutBoundHandler(出站事件处理器),两个接口都继承ChannelHandler接口;
ChannelHandlerAdapter抽象类实现了ChannelHandler接口,提供了一些方法的默认实现,根据在服务端编写还是在客户端编写提供了ChannelInboundHandlerAdapter与SimpleChannelInboundHandler两个子类,前者不会释放消息数据的引用,后者会;
4.ChannelPipeline
在Channel的数据传递过程中,不同的业务逻辑实现都需要有ChannelHandler完成,一个Channel对应着多个ChannelHandler,ChannelPipeline就是用来管理多个ChannelHandler的;
一个Channel包含了一个ChannelPipeline,ChannelPipeline中维护了一个ChannelHandler的列表,ChannelHandler与Channel和ChannelPipeline之间的映射关系又由ChannelHandlerContext来维护;
- Channel Handler按照加入的顺序会组成一个双向链表,入站事件从链表的头往后传递到最后一个ChannelHandler,出站事件从链表的尾向前传递,直到最后一个ChannelHandler,两种类型的ChannelHandler相互不影响;
5.Bootstrap
Bootstrap(引导类)负责配置整个Netty程序,将各个组件都串起来,绑定端口启动Netty服务,针对客户端(Bootstrap)与服务端(ServerBootstrap)分为两种引导类;
- ServerBootstrap将绑定到一个端口,而Bootstrap不需要绑定本地端口只需连接到远程端口;
- Bootstrap只需要一个EventLoopGroup,而Server Bootstrap则需要两个,因为服务端需要两组不同的Channel,一组用来接收新的客户端连接请求,一组用来处理已连接的客户端Channel的读写事件;
6.Future
Future提供了一种在异步操作完成时通知应用程序的方式,Future对象可以看作一个异步操作结果的占位符,他将在未来的某个时刻完成,并提供对其结果的访问;
JDK内置的 java.util.concurrent.Future只允许手动检查对应的操作是否已完成,或阻塞到他完成,较为繁琐,Netty提供了他自己的Future实现--ChannelFuture;
- ChannelFuture提供了几种额外的方法,使得我们能够注册一个或多个ChannelFutureListener实例;
- 监听器的回调方法operationComplete(),将会在对应的操作完成时被调用,监听器就能知道操作是成功了还是出错了;
- 每个Netty的出站IO操作都将返回一个ChannelFuture,也就是说他们都不会阻塞;
7.ByteBuf缓冲区
ByteBuf是Netty用于处理字节数据的核心类,是一个灵活高效的字节容器,提供了丰富的API来操作字节数据,是Netty对JDK自带的ByteBuffer的替代品;
ByteBuf内部结构如下:
- discardable bytes:可丢弃的字节空间;
- readable bytes:可读的字节空间;
- writable bytes:可写的字节空间;
- capacity bytes:最大的可容量空间;
7.1 ByteBuf的工作原理
ByteBuf由一串字节数组构成,数组中每个字节用来存放信息,ByteBuf有两个索引,分别用来读写数据,通过两个索引在数组中移动,来定位需要读或写的位置;
当从ByteBuf中读取时,readerIndex(读索引)将会根据读取的字节数递增,当写ByteBuf时,writerIndex(写索引)也会根据写入的字节数进行递增;当readerIndex超过writerIndex的时候,Netty会抛出IndexOutOf-BoundsException;
7.2 索引指针
ByteBuf有三个指针:
- readerIndex(读指针):标记读取的起始位置,每读取一个字节加一,当readerIndex与writerIndex相等时不可读;
- writerIndex(写指针):标记写入的起始位置,每写入一个字节加一,当writerIndex与maxCapacity容量相等时不可写;
- maxCapacity(最大容量):指示ByteBuf可以扩容的最大容量,如果向ByteBuf写入数据时容量不足,可以扩容;
7.3 缓冲区的使用模式
根据存放缓冲区的不同分为三类:
- 堆缓冲区(HeapByteBuf):内存的分配和回收速度比较快,可以被JVM自动回收,但如果进行socket的IO读写,需要额外做一次内存复制,将堆内存对应的缓冲区复制到内核Channel中,这回对性能有所影响;
- 直接缓冲区(DirectByteBuf):非堆内存,相较比堆内存分配和回收速度慢一些,但是将他写入或从socket Channel中读取时少一次内存拷贝,这时比堆内存快;
- 复合缓冲区:Netty提供的CompsiteByteBuf就是将堆缓冲区与直接缓冲区的数据放在一起;
Nettty默认使用直接缓冲区模式;
7.4 ByteBuf的分配
Netty提供了接口ByteBufAllocator来分配ByteBuf实例,其有两个实现类
- PooledByteBufAllocator:实现了ByteBuf对象的池化,可复用ByteBuf实例,提高性能并最大限度的减少内存碎片;
- UnpooledByteBufAllocator:没有实现对象的池化,每次会生成新的ByteBuf对象实例;
7.5 ByteBuf的释放
ByteBuf如果采用堆缓冲区模式,可以由GC回收,如果采用直接缓冲区模式就得手动释放;
7.5.1 手动释放
使用完后,调用 ReferenceCountUtil.release(byteBuf) 来释放;
7.5.2 自动释放
- TailHandler:Netty的ChannelPiplelline的流水线的末端是TailHandler,默认情况下如果每个入站处理器都把消息往下传,TailHandler会释放掉ReferenceCounted类型的消息;
- SImpleChannelInboundHandler:当ChannelHandler继承了SimpleChannelInboundHandler后,在其中的channelRead()方法中,将会进行资源的释放,业务代码需要写入到channelRead0()中;
- HeadHandler:在每一个出站Handler中的处理完成后,最后消息会来到HeadHandler,经过一轮复杂调用在flush完成后释放掉;
7.5.3 释放总结
- 入站处理流程中,如果对原消息不做处理,调用 ctx.fireChannelRead(msg) 把原消息往下传,由流水线最后的 TailHandler 完成自动释放。
- 如果截断了入站处理流水线,则可以继承 SimpleChannelInboundHandler ,完成入站ByteBuf自动释放。
- 出站处理过程中,申请分配到的 ByteBuf,通过 HeadHandler 完成自动释放。
- 入站处理中,如果将原消息转化为新的消息并调用 ctx.fireChannelRead(newMsg)往下传,那必须把原消息release掉;
- 入站处理中,如果已经不再调用 ctx.fireChannelRead(msg) 传递任何消息,也没有继承SimpleChannelInboundHandler 完成自动释放,那更要把原消息release掉;