NIO总结笔记

发表于 |

Java I/O

I/O NIO
面向流 面向缓冲
阻塞IO 非阻塞IO
无 选择器
  • I/O 与 NIO 一个比较重要的区别是我们使用 I/O 的时候往往会引入多线程，每个连接使用一个单独的线程，而 NIO 则是使用单线程或者只使用少量的多线程，每个连接共用一个线程。而由于 NIO 的非阻塞需要一直轮询，比较消耗系统资源，所以异步非阻塞模式 AIO 就诞生了。

5 种 I/O模型

  1. blocking I/O
  2. nonblocking I/O
  3. I/O multiplexing (select and poll)
  4. signal driven I/O (SIGIO)
  5. asynchronous I/O (the POSIX aio_functions)。
  • 不同的操作系统对上述模型支持不同，UNIX 支持 IO 多路复用。不同系统叫法不同，freebsd 里面叫 kqueue，Linux 叫 epoll。而 Windows2000 的时候就诞生了 IOCP 用以支持 asynchronous I/O。
  • Java 是一种跨平台语言，为了支持异步 I/O，诞生了 NIO，Java1.4 引入的 NIO1.0 是基于 I/O 复用的，它在各个平台上会选择不同的复用方式。Linux 用的 epoll，BSD 上用 kqueue，Windows 上是重叠 I/O。
  • IO多路复用，Java NIO的核心类库多路复用器Selector就是基于epoll的多路复用技术实现。
  • IO复用的系统调用方式：select，pselect，poll，epoll（IO复用属于同步IO）
  • 同步阻塞BIO，同步非阻塞NIO，异步非阻塞AIO
    同步IO和异步IO的区别就在于：数据拷贝的时候进程是否阻塞！
    阻塞IO和非阻塞IO的区别就在于：应用程序的调用是否立即返回！

Java I/O 的相关方法

  1. 同步并阻塞 (I/O 方法)：服务器实现模式为一个连接启动一个线程，每个线程亲自处理 I/O 并且一直等待 I/O 直到完成，即客户端有连接请求时服务器端就需要启动一个线程进行处理。但是如果这个连接不做任何事情就会造成不必要的线程开销，当然可以通过线程池机制改善这个缺点。I/O 的局限是它是面向流的、阻塞式的、串行的一个过程。对每一个客户端的 Socket 连接 I/O 都需要一个线程来处理，而且在此期间，这个线程一直被占用，直到 Socket 关闭。在这期间，TCP 的连接、数据的读取、数据的返回都是被阻塞的。也就是说这期间大量浪费了 CPU 的时间片和线程占用的内存资源。此外，每建立一个 Socket 连接时，同时创建一个新线程对该 Socket 进行单独通信 (采用阻塞的方式通信)。这种方式具有很快的响应速度，并且控制起来也很简单。在连接数较少的时候非常有效，但是如果对每一个连接都产生一个线程无疑是对系统资源的一种浪费，如果连接数较多将会出现资源不足的情况；
  2. 同步非阻塞 (NIO 方法)：服务器实现模式为一个请求启动一个线程，每个线程亲自处理 I/O，但是另外的线程轮询检查是否 I/O 准备完毕，不必等待 I/O 完成，即客户端发送的连接请求都会注册到多路复用器上，多路复用器轮询到连接有 I/O 请求时才启动一个线程进行处理。NIO 则是面向缓冲区，非阻塞式的，基于选择器的，用一个线程来轮询监控多个数据传输通道，哪个通道准备好了 (即有一组可以处理的数据) 就处理哪个通道。服务器端保存一个 Socket 连接列表，然后对这个列表进行轮询，如果发现某个 Socket 端口上有数据可读时，则调用该 Socket 连接的相应读操作；如果发现某个 Socket 端口上有数据可写时，则调用该 Socket 连接的相应写操作；如果某个端口的 Socket 连接已经中断，则调用相应的析构方法关闭该端口。这样能充分利用服务器资源，效率得到大幅度提高；
  3. 异步非阻塞 (AIO 方法，JDK7 发布)：服务器实现模式为一个有效请求启动一个线程，客户端的 I/O 请求都是由操作系统先完成了再通知服务器应用去启动线程进行处理，每个线程不必亲自处理 I/O，而是委派操作系统来处理，并且也不需要等待 I/O 完成，如果完成了操作系统会另行通知的。该模式采用了 Linux 的 epoll 模型。
  • 在连接数不多的情况下，传统 I/O 模式编写较为容易，使用上也较为简单。但是随着连接数的不断增多，传统 I/O 处理每个连接都需要消耗一个线程，而程序的效率，当线程数不多时是随着线程数的增加而增加，但是到一定的数量之后，是随着线程数的增加而减少的。所以传统阻塞式 I/O 的瓶颈在于不能处理过多的连接。非阻塞式 I/O 出现的目的就是为了解决这个瓶颈。非阻塞 IO 处理连接的线程数和连接数没有联系，例如系统处理 10000 个连接，非阻塞 I/O 不需要启动 10000 个线程，你可以用 1000 个，也可以用 2000 个线程来处理。因为非阻塞 IO 处理连接是异步的，当某个连接发送请求到服务器，服务器把这个连接请求当作一个请求“事件”，并把这个“事件”分配给相应的函数处理。我们可以把这个处理函数放到线程中去执行，执行完就把线程归还，这样一个线程就可以异步的处理多个事件。而阻塞式 I/O 的线程的大部分时间都被浪费在等待请求上了。

AIO 相关的类和接口

  • java.nio.channels.AsynchronousChannel：标记一个 Channel 支持异步 IO 操作；
  • java.nio.channels.AsynchronousServerSocketChannel：ServerSocket 的 AIO 版本，创建 TCP 服务端，绑定地址，监听端口等；
  • java.nio.channels.AsynchronousSocketChannel：面向流的异步 Socket Channel，表示一个连接；
  • java.nio.channels.AsynchronousChannelGroup：异步 Channel 的分组管理，目的是为了资源共享。一个 AsynchronousChannelGroup 绑定一个线程池，这个线程池执行两个任务：处理 IO 事件和派发 CompletionHandler。AsynchronousServerSocketChannel 创建的时候可以传入一个 AsynchronousChannelGroup，那么通过 AsynchronousServerSocketChannel 创建的 AsynchronousSocketChannel 将同属于一个组，共享资源；
  • java.nio.channels.CompletionHandler：异步 IO 操作结果的回调接口，用于定义在 IO 操作完成后所作的回调工作。AIO 的 API 允许两种方式来处理异步操作的结果：返回的 Future 模式或者注册 CompletionHandler，推荐用 CompletionHandler 的方式，这些 handler 的调用是由 AsynchronousChannelGroup 的线程池派发的。这里线程池的大小是性能的关键因素。

Reactor线程模型

常用的Reactor线程模型有三种，分别如下：

  1. Reactor单线程模型；
  2. Reactor多线程模型；
  3. 主从Reactor多线程模型
    • Netty的线程模型并非固定不变，通过在启动辅助类中创建不同的EventLoopGroup实例并通过适当的参数配置，就可以支持上述三种Reactor线程模型。

Netty线程模型

  • http://www.infoq.com/cn/articles/netty-threading-model
  • 主从Reactor线程模型
  • Netty线程开发最佳实践
    • 2.4.1. 时间可控的简单业务直接在IO线程上处理
      如果业务非常简单，执行时间非常短，不需要与外部网元交互、访问数据库和磁盘，不需要等待其它资源，则建议直接在业务ChannelHandler中执行，不需要再启业务的线程或者线程池。避免线程上下文切换，也不存在线程并发问题。
    • 2.4.2. 复杂和时间不可控业务建议投递到后端业务线程池统一处理
      对于此类业务，不建议直接在业务ChannelHandler中启动线程或者线程池处理，建议将不同的业务统一封装成Task，统一投递到后端的业务线程池中进行处理。
      过多的业务ChannelHandler会带来开发效率和可维护性问题，不要把Netty当作业务容器，对于大多数复杂的业务产品，仍然需要集成或者开发自己的业务容器，做好和Netty的架构分层。
    • 2.4.3. 业务线程避免直接操作ChannelHandler
      对于ChannelHandler，IO线程和业务线程都可能会操作，因为业务通常是多线程模型，这样就会存在多线程操作ChannelHandler。为了尽量避免多线程并发问题，建议按照Netty自身的做法，通过将操作封装成独立的Task由NioEventLoop统一执行，而不是业务线程直接操作
      ctx.executor().execute(new Runnable(){})
      如果你确认并发访问的数据或者并发操作是安全的，则无需多此一举，这个需要根据具体的业务场景进行判断，灵活处理。

Netty的“零拷贝”

  • Netty的接收和发送ByteBuffer采用DIRECT BUFFERS，使用堆外直接内存进行Socket读写，不需要进行字节缓冲区的二次拷贝。
  • Netty提供了组合Buffer对象，可以聚合多个ByteBuffer对象，用户可以像操作一个Buffer那样方便的对组合Buffer进行操作，避免了传统通过内存拷贝的方式将几个小Buffer合并成一个大的Buffer。
  • Netty的文件传输采用了transferTo方法，它可以直接将文件缓冲区的数据发送到目标Channel，避免了传统通过循环write方式导致的内存拷贝问题。

Netty - 灵活的TCP参数配置能力

  • SO_RCVBUF和SO_SNDBUF：通常建议值为128K或者256K；
  • SO_TCPNODELAY：NAGLE算法通过将缓冲区内的小封包自动相连，组成较大的封包，阻止大量小封包的发送阻塞网络，从而提高网络应用效率。但是对于时延敏感的应用场景需要关闭该优化算法；
  • 软中断：如果Linux内核版本支持RPS（2.6.35以上版本），开启RPS后可以实现软中断，提升网络吞吐量。RPS根据数据包的源地址，目的地址以及目的和源端口，计算出一个hash值，然后根据这个hash值来选择软中断运行的cpu，从上层来看，也就是说将每个连接和cpu绑定，并通过这个hash值，来均衡软中断在多个cpu上，提升网络并行处理性能。

心跳实现

  • 使用TCP协议层的Keeplive机制，但是该机制默认的心跳时间是2小时，依赖操作系统实现不够灵活
  • 应用层实现自定义心跳机制，比如Netty实现心跳机制
    • 服务端添加IdleStateHandler心跳检测处理器，并添加自定义处理Handler类实现userEventTriggered()方法作为超时事件的逻辑处理

Netty中比较常用的帧解码器

  1. 固定长度帧解码器 - FixedLengthFrameDecoder
    • 适用场景：每个上层数据包的长度，都是固定的，比如 100。在这种场景下，只需要把这个解码器加到 pipeline 中，Netty 会把底层帧，拆分成一个个长度为 100 的数据包 (ByteBuf)，发送到下一个 channelHandler入站处理器。
  2. 行分割帧解码器 - LineBasedFrameDecoder
    • 适用场景：每个上层数据包，使用换行符或者回车换行符做为边界分割符。发送端发送的时候，每个数据包之间以换行符/回车换行符作为分隔。在这种场景下，只需要把这个解码器加到 pipeline 中，Netty 会使用换行分隔符，把底层帧分割成一个一个完整的应用层数据包，发送到下一站。前面的例子，已经对这个解码器进行了演示。
  3. 自定义分隔符帧解码器 - DelimiterBasedFrameDecoder
    • DelimiterBasedFrameDecoder 是LineBasedFrameDecoder的通用版本。不同之处在于，这个解码器，可以自定义分隔符，而不是局限于换行符。如果使用这个解码器，在发送的时候，末尾必须带上对应的分隔符。
  4. 自定义长度帧解码器 - LengthFieldBasedFrameDecoder
    • 这是一种基于灵活长度的解码器。在数据包中，加了一个长度字段（长度域），保存上层包的长度。解码的时候，会按照这个长度，进行上层ByteBuf应用包的提取。
    • LengthFieldPrepender(编码)：如果协议中的第一个字段为长度字段，netty提供了LengthFieldPrepender编码器，它可以计算当前待发送消息的二进制字节长度，将该长度添加到ByteBuf的缓冲区头中

Netty API

JDK ByteBuffer VS Netty ByteBuf

  • https://blog.csdn.net/u013828625/article/details/79845512
  • Netty中的ByteBuf则完全对JDK中的ByteBuffer的缺点进行了改进
  • 网络数据的基本单位永远是 byte(字节)。Java NIO 提供 ByteBuffer 作为字节的容器，但该类过于复杂，有点难用。ByteBuf是Netty当中的最重要的工具类，它与JDK的ByteBuffer原理基本上相同，也分为堆内与堆外俩种类型，但是ByteBuf做了极大的优化，具有更简单的API，更多的工具方法和优秀的内存池设计。
  • ByteBuf 维护俩不同索引：一个用于读取，一个用于写入：从 ByteBuf 读取时，其 readerIndex 将会被递增已经被读取的字节数；当写入 ByteBuf 时，writerIndex 也会被递增

SimpleChannelInboundHandler

  1. ChannelInboundHandlerAdapter
    • ChannelInboundHandlerAdapter是ChannelInboundHandler的一个简单实现，默认情况下不会做任何处理，只是简单的将操作通过fire*方法传递到ChannelPipeline中的下一个ChannelHandler中让链中的下一个ChannelHandler去处理。
    • 需要注意的是信息经过channelRead方法处理之后不会自动释放（因为信息不会被自动释放所以能将消息传递给下一个ChannelHandler处理）。
  2. SimpleChannelInboundHandler
    • SimpleChannelInboundHandler支持泛型的消息处理，默认情况下消息处理完将会被自动释放，无法提供fire*方法传递给ChannelPipeline中的下一个ChannelHandler,如果想要传递给下一个ChannelHandler需要调用ReferenceCountUtil#retain方法。
    • channelRead0方法在将来将会重命名为messageReceived

channelRead()和channelReadComplete()

  • channelRead()和channelReadComplete() 方法的区别是什么？
  • channelRead表示接收消息，可以看到msg转换成了ByteBuf，然后打印，也就是把Client传过来的消息打印了一下，你会发现每次打印完后，channelReadComplete也会调用，如果你试着传一个超长的字符串过来，超过1024个字母长度，你会发现channelRead会调用多次，而channelReadComplete只调用一次。

ctx.write() vd ctx.channel().write()

自定义消息协议

  • len : 表示消息的长度,通常用4个字节保存

  • head : 消息头部

  • body : 消息内容

  • 在实际的项目中,消息格式可能会增加一些标志,例如,开始标记,结束标志,消息序列号,消息的协议类型(json或者二进制等)

Netty 没用JDK1.7的AIO

  • 为什么Netty不用AIO而用NIO?
According to the book the main reasons were:
1. Not faster than NIO (epoll) on unix systems (which is true)
There is no daragram suppport
2. Unnecessary threading model (too much abstraction without usage)
3. I agree that AIO will not easily replace NIO, but it is useful for windows developers nonetheless.

We obviously did not consider Windows as a serious platform so far, and that's why we were neglecting NIO.2 AIO API which was implemented using IOCP on Windows. (On Linux, it wasn't any faster because it was using the same OS facility - epoll.)

Netty-Epoll

  • epoll的两种工作模式：
    • LT：level-trigger，水平触发模式，只要某个socket处于readable/writable状态，无论什么时候进行epoll_wait都会返回该socket。
      当epoll_wait检测到描述符事件发生并将此事件通知应用程序，应用程序可以不立即处理该事件。下次调用epoll_wait时，会再次响应应用程序并通知此事件。
    • ET：edge-trigger，边缘触发模式，只有某个socket从unreadable变为readable或从unwritable变为writable时，epoll_wait才会返回该socket。
      当epoll_wait检测到描述符事件发生并将此事件通知应用程序，应用程序必须立即处理该事件。如果不处理，下次调用epoll_wait时，不会再次响应应用程序并通知此事件。
      ET模式在很大程度上减少了epoll事件被重复触发的次数，因此效率要比LT模式高。epoll工作在ET模式的时候，必须使用非阻塞套接口，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。
  • 在Linux系统中JDK NIO使用的是 LT ，而Netty epoll使用的是 ET。

其他

  • JDK中有自带的ByteBuffer类，但是netty中的 ByteBuf 算是对Byte Buffer的重新实现。他们没有关联关系。
  • netty推荐使用io.netty.buffer.Unpooled来进行Buff的创建工作。Unpooled是一个工具类，可以为ByteBuf分配空间、拷贝或者封装操作
  • DirectBuffer：使用 DirectBuffer 是一种更加接近系统底层的方法，所以，它的速度比普通的 ByteBuffer 更快。DirectBuffer 相对于 ByteBuffer 而言，读写访问速度快很多，但是创建和销毁 DirectBuffer 的花费却比 ByteBuffer 高。
  • Netty的并发处理能力主要体现在两个方面：
    1. 利用Java语言自身的多线程机制实现消息的并行处理；
    2. 利用Java NIO类库的Selector实现多路复用，一个NIO线程可以同时并发处理成百上千个通信链路，实现海量客户端的并发接入和处理。
  • netty.pipeline执行顺序：在给定的示例配置中，当事件进入到入站时，处理程序计算顺序为(代码行：从上到下)。当一个事件出站时，顺序是(代码行：从下到上)。

Reference