NIO网络编程

NIO网络编程

网络三种I/O模型

分类：

BIO:（同步 阻塞）jdk1.4以前 java.io包

NIO:（同步 非阻塞）jdk1.4 java.nio包

AIO:（异步 非阻塞）jdk1.7 java.nio包

如何如何理解：

当我们去吃饭可以有以下几种模式：

饭店 -> 服务器

饭菜-> 数据

饭菜好了-> 数据就绪

端菜 /送菜 -> 数据读取

BIO：食堂排队打饭模式：排队在窗口，打好才走；

NIO：点单、等待被叫模式：等待被叫，好了自己去端；

AIO：包厢模式：点单后菜直接被端上桌。

阻塞与非阻塞

菜没好，要不要死等 -> 数据就绪前要不要等待？

**阻塞：**没有数据传过来时，读会阻塞直到有数据；缓冲区满时，写操作也会阻塞。

**非阻塞：**遇到这些情况，都是直接返回

同步与异步

菜好了，谁端 -> 数据就绪后，数据操作谁完成？

**同步：**数据就绪后需要自己去读是同步

**异步：**数据就绪直接读好再回调给程序是异步

一般是不建议使用BIO的，原因如下：

连接数高的情况下：阻塞 -> 耗资源、效率低

Linux系统也是不推荐使用AIO的，原因如下：

Windows 实现成熟，但是很少用来做服务器

Linux 常用来做服务器，但是 AIO 实现不够成熟

Linux 下 AIO 相比较 NIO 的性能提升不明显

JDK中的NIO

NIO 库是在 JDK 1.4 中引入的。NIO 弥补了原来的 I/O 的不足，它在标准 Java 代码中提供了高速的、面向块的 I/O。NIO翻译成 no-blocking io 或者 new io都说得通。

NIO和BIO的主要区别

面向流与面向缓冲

Java NIO和IO之间第一个最大的区别是，IO是面向流的，NIO是面向缓冲区的。 Java IO面向流意味着每次从流中读一个或多个字节，直至读取所有字节，它们没有被缓存在任何地方。此外，它不能前后移动流中的数据。如果需要前后移动从流中读取的数据，需要先将它缓存到一个缓冲区。

Java NIO的缓冲导向方法略有不同。数据读取到一个它稍后处理的缓冲区，需要时可在缓冲区中前后移动。这就增加了处理过程中的灵活性。但是，还需要检查是否该缓冲区中包含所有需要处理的数据。而且，需确保当更多的数据读入缓冲区时，不要覆盖缓冲区里尚未处理的数据。

阻塞与非阻塞IO

Java IO的各种流是阻塞的。这意味着，当一个线程调用read() 或 write()时，该线程被阻塞，直到有一些数据被读取，或数据完全写入。该线程在此期间不能再干任何事情了。

Java NIO的非阻塞模式，使一个线程从某通道发送请求读取数据，但是它仅能得到目前可用的数据，如果目前没有数据可用时，就什么都不会获取。而不是保持线程阻塞，所以直至数据变的可以读取之前，该线程可以继续做其他的事情。非阻塞写也是如此。一个线程请求写入一些数据到某通道，但不需要等待它完全写入，这个线程同时可以去做别的事情。线程通常将非阻塞IO的空闲时间用于在其它通道上执行IO操作，所以一个单独的线程现在可以管理多个输入和输出通道（channel）。

NIO三大核心组件

NIO有三大核心组件：Selector选择器、Channel管道、buffer缓冲区。

Selector

Selector的英文含义是“选择器”，也可以称为为“轮询代理器”、“事件订阅器”、“channel容器管理机”都行。

Java NIO的选择器允许一个单独的线程来监视多个输入通道，你可以注册多个通道使用一个选择器(Selectors)，然后使用一个单独的线程来操作这个选择器，进而“选择”通道：这些通道里已经有可以处理的输入，或者选择已准备写入的通道。这种选择机制，使得一个单独的线程很容易来管理多个通道。

应用程序将向Selector对象注册需要它关注的Channel，以及具体的某一个Channel会对哪些IO事件感兴趣。Selector中也会维护一个“已经注册的Channel”的容器。

Channel

通道，被建立的一个应用程序和操作系统交互事件、传递内容的渠道（注意是连接到操作系统）。那么既然是和操作系统进行内容的传递，那么说明应用程序可以通过通道读取数据，也可以通过通道向操作系统写数据，而且可以同时进行读写。

• 所有被Selector（选择器）注册的通道，只能是继承了SelectableChannel类的子类。
• ServerSocketChannel：应用服务器程序的监听通道。只有通过这个通道，应用程序才能向操作系统注册支持“多路复用IO”的端口监听。同时支持UDP协议和TCP协议。
• ScoketChannel：TCP

  Socket套接字的监听通道，一个Socket套接字对应了一个客户端IP：端口到服务器IP：端口的通信连接。

  通道中的数据总是要先读到一个Buffer，或者总是要从一个Buffer中写入。

  buffer缓冲区

  网络通讯中负责数据读写的区域

  JDK的NIO实战

  

  原生JDK网络编程-NIO实战

  

  1、Selector对象是通过调用静态工厂方法open()来实例化的，如下：

  Selector Selector=Selector.open()；
  

  2、要实现Selector管理Channel，需要将channel注册到相应的Selector上，如下：

  channel.configureBlocking(false);
  SelectionKey key= channel.register(selector,SelectionKey,OP_READ);
  

  通过调用通道的register()方法会将它注册到一个选择器上。与Selector一起使用时，Channel必须处于非阻塞模式下，否则将抛出IllegalBlockingModeException异常，这意味着不能将FileChannel与Selector一起使用，因为FileChannel不能切换到非阻塞模式，而套接字通道都可以。另外通道一旦被注册，将不能再回到阻塞状态，此时若调用通道的configureBlocking(true)将抛出BlockingModeException异常。

  3、在实际运行中，我们通过Selector的select（）方法可以选择已经准备就绪的通道（这些通道包含你感兴趣的的事件）。

  

  下面是Selector几个重载的select()方法：

  select():阻塞到至少有一个通道在你注册的事件上就绪了。
  select(long timeout)：和select()一样，但最长阻塞时间为timeout毫秒。
  selectNow():非阻塞，立刻返回。
  

  select()方法返回的int值表示有多少通道已经就绪,是自上次调用select()方法后有多少通道变成就绪状态。

  一旦调用select()方法，并且返回值不为0时，则可以通过调用Selector的selectedKeys()方法来访问已选择键集合。

  Set selectedKeys=selector.selectedKeys();

  这个时候，循环遍历selectedKeys集中的每个键，并检测各个键所对应的通道的就绪事件，再通过SelectionKey关联的Selector和Channel进行实际的业务处理。

  注意每次迭代末尾的keyIterator.remove()调用。Selector不会自己从已选择键集中移除SelectionKey实例。必须在处理完通道时自己移除，否则的话，下次该通道变成就绪时，Selector会再次将其放入已选择键集中。

  SelectionKey

  什么是SelectionKey

  

  SelectionKey是一个抽象类,表示selectableChannel在Selector中注册的标识.每个Channel向Selector注册时,都将会创建一个SelectionKey。SelectionKey将Channel与Selector建立了关系,并维护了channel事件。

  可以通过cancel方法取消键,取消的键不会立即从selector中移除,而是添加到cancelledKeys中,在下一次select操作时移除它.所以在调用某个key时,需要使用isValid进行校验.

  

  SelectionKey类型和就绪条件

  在向Selector对象注册感兴趣的事件时，JAVA NIO共定义了四种：OP_READ、OP_WRITE、OP_CONNECT、OP_ACCEPT（定义在SelectionKey中），分别对应读、写、请求连接、接受连接等网络Socket操作。

  操作类型	就绪条件及说明
  OP_READ	当操作系统读缓冲区有数据可读时就绪。并非时刻都有数据可读，所以一般需要注册该操作，仅当有就绪时才发起读操作，有的放矢，避免浪费CPU。
  OP_WRITE	当操作系统写缓冲区有空闲空间时就绪。一般情况下写缓冲区都有空闲空间，小块数据直接写入即可，没必要注册该操作类型，否则该条件不断就绪浪费CPU；但如果是写密集型的任务，比如文件下载等，缓冲区很可能满，注册该操作类型就很有必要，同时注意写完后取消注册。
  OP_CONNECT	当SocketChannel.connect()请求连接成功后就绪。该操作只给客户端使用。
  OP_ACCEPT	当接收到一个客户端连接请求时就绪。该操作只给服务器使用。

  服务端和客户端分别感兴趣的类型

  ServerSocketChannel和SocketChannel可以注册自己感兴趣的操作类型，当对应操作类型的就绪条件满足时OS会通知channel，下表描述各种Channel允许注册的操作类型，Y表示允许注册，N表示不允许注册，其中服务器SocketChannel指由服务器ServerSocketChannel.accept()返回的对象。

  

  服务器启动ServerSocketChannel，关注OP_ACCEPT事件，

  客户端启动SocketChannel，连接服务器，关注OP_CONNECT事件

  服务器接受连接，启动一个服务器的SocketChannel，这个SocketChannel可以关注OP_READ、OP_WRITE事件，一般连接建立后会直接关注OP_READ事件

  客户端这边的客户端SocketChannel发现连接建立后，可以关注OP_READ、OP_WRITE事件，一般是需要客户端需要发送数据了才关注OP_READ事件

  连接建立后客户端与服务器端开始相互发送消息（读写），根据实际情况来关注OP_READ、OP_WRITE事件。

  Buffer

  Buffer用于和NIO通道进行交互。数据是从通道读入缓冲区，从缓冲区写入到通道中的。以写为例，应用程序都是将数据写入缓冲，再通过通道把缓冲的数据发送出去，读也是一样，数据总是先从通道读到缓冲，应用程序再读缓冲的数据。

  缓冲区本质上是一块可以写入数据，然后可以从中读取数据的内存（其实就是数组）。这块内存被包装成NIO Buffer对象，并提供了一组方法，用来方便的访问该块内存。

  

  

  重要属性

  

  capacity

  作为一个内存块，Buffer有一个固定的大小值，也叫“capacity”.你只能往里写capacity个byte、long，char等类型。一旦Buffer满了，需要将其清空（通过读数据或者清除数据）才能继续写数据往里写数据。

  position

  当你写数据到Buffer中时，position表示当前能写的位置。初始的position值为0。当一个byte、long等数据写到Buffer后， position会向前移动到下一个可插入数据的Buffer单元。position最大可为capacity – 1.

  当读取数据时，也是从某个特定位置读。当将Buffer从写模式切换到读模式，position会被重置为0. 当从Buffer的position处读取数据时，position向前移动到下一个可读的位置。

  limit

  在写模式下，Buffer的limit表示你最多能往Buffer里写多少数据。写模式下，limit等于Buffer的capacity。

  当切换Buffer到读模式时， limit表示你最多能读到多少数据。因此，当切换Buffer到读模式时，limit会被设置成写模式下的position值。换句话说，你能读到之前写入的所有数据（limit被设置成已写数据的数量，这个值在写模式下就是position）

  Buffer的分配

  要想获得一个Buffer对象首先要进行分配。每一个Buffer类都有allocate方法(可以在堆上分配，也可以在直接内存上分配)。

  分配48字节capacity的ByteBuffer的例子

  ByteBuffer buf = ByteBuffer.allocate(48);
  

  分配一个可存储1024个字符的CharBuffer：

  CharBuffer buf = CharBuffer.allocate(1024);
  

  直接内存

  HeapByteBuffer与DirectByteBuffer，在原理上，前者可以看出分配的buffer是在heap区域的，其实真正flush到远程的时候会先拷贝到直接内存，再做下一步操作；在NIO的框架下，很多框架会采用DirectByteBuffer来操作，这样分配的内存不再是在java heap上，经过性能测试，可以得到非常快速的网络交互，在大量的网络交互下，一般速度会比HeapByteBuffer要快速好几倍。

  直接内存（Direct Memory）并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域，但是这部分内存也被频繁地使用，而且也可能导致OutOfMemoryError 异常出现。

  NIO可以使用Native 函数库直接分配堆外内存，然后通过一个存储在Java 堆里面的DirectByteBuffer 对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java 堆和Native 堆中来回复制数据。

  

  直接内存（堆外内存）与堆内存比较

  直接内存申请空间耗费更高的性能，当频繁申请到一定量时尤为明显

  直接内存IO读写的性能要优于普通的堆内存，在多次读写操作的情况下差异明显

  Buffer的读写

  Buffer方法总结

  limit(), limit(10)等	其中读取和设置这4个属性的方法的命名和jQuery中的val(),val(10)类似，一个负责get，一个负责set
  reset()	把position设置成mark的值，相当于之前做过一个标记，现在要退回到之前标记的地方
  clear()	position = 0;limit = capacity;mark = -1; 有点初始化的味道，但是并不影响底层byte数组的内容
  flip()	limit = position;position = 0;mark = -1; 翻转，也就是让flip之后的position到limit这块区域变成之前的0到position这块，翻转就是将一个处于存数据状态的缓冲区变为一个处于准备取数据的状态
  rewind()	把position设为0，mark设为-1，不改变limit的值
  remaining()	return limit - position;返回limit和position之间相对位置差
  hasRemaining()	return position
  compact()	把从position到limit中的内容移到0到limit-position的区域内，position和limit的取值也分别变成limit-position、capacity。如果先将positon设置到limit，再compact，那么相当于clear()
  get()	相对读，从position位置读取一个byte，并将position+1，为下次读写作准备
  get(int index)	绝对读，读取byteBuffer底层的bytes中下标为index的byte，不改变position
  get(byte[] dst, int offset, int length)	从position位置开始相对读，读length个byte，并写入dst下标从offset到offset+length的区域
  put(byte b)	相对写，向position的位置写入一个byte，并将postion+1，为下次读写作准备
  put(int index, byte b)	绝对写，向byteBuffer底层的bytes中下标为index的位置插入byte b，不改变position
  put(ByteBuffer src)	用相对写，把src中可读的部分（也就是position到limit）写入此byteBuffer
  put(byte[] src, int offset, int length)	从src数组中的offset到offset+length区域读取数据并使用相对写写入此byteBuffer

  NIO之Reactor模式

  Reactor 是一种开发模式，模式的核心流程：

  注册感兴趣的事件 -> 扫描是否有感兴趣的事件发生 -> 事件发生后做出相应的处理

  单线程Reactor模式

  

  ①服务器端的Reactor是一个线程对象，该线程会启动事件循环，并使用Selector(选择器)来实现IO的多路复用。注册一个Acceptor事件处理器到Reactor中，Acceptor事件处理器所关注的事件是ACCEPT事件，这样Reactor会监听客户端向服务器端发起的连接请求事件(ACCEPT事件)。

  ②客户端向服务器端发起一个连接请求，Reactor监听到了该ACCEPT事件的发生并将该ACCEPT事件派发给相应的Acceptor处理器来进行处理。Acceptor处理器通过accept()方法得到与这个客户端对应的连接(SocketChannel)，然后将该连接所关注的READ事件以及对应的READ事件处理器注册到Reactor中，这样一来Reactor就会监听该连接的READ事件了。

  ③当Reactor监听到有读或者写事件发生时，将相关的事件派发给对应的处理器进行处理。比如，读处理器会通过SocketChannel的read()方法读取数据，此时read()操作可以直接读取到数据，而不会堵塞与等待可读的数据到来。

  ④每当处理完所有就绪的感兴趣的I/O事件后，Reactor线程会再次执行select()阻塞等待新的事件就绪并将其分派给对应处理器进行处理。

  注意，Reactor的单线程模式的单线程主要是针对于I/O操作而言，也就是所有的I/O的accept()、read()、write()以及connect()操作都在一个线程上完成的。

  但在目前的单线程Reactor模式中，不仅I/O操作在该Reactor线程上，连非I/O的业务操作也在该线程上进行处理了，这可能会大大延迟I/O请求的响应。所以我们应该将非I/O的业务逻辑操作从Reactor线程上卸载，以此来加速Reactor线程对I/O请求的响应。

  多线程Reactor模式

  

  与单线程Reactor模式不同的是，添加了一个工作者线程池，并将非I/O操作从Reactor线程中移出转交给工作者线程池来执行。这样能够提高Reactor线程的I/O响应，不至于因为一些耗时的业务逻辑而延迟对后面I/O请求的处理。

  使用线程池的优势：

  ①通过重用现有的线程而不是创建新线程，可以在处理多个请求时分摊在线程创建和销毁过程产生的巨大开销。

  ②另一个额外的好处是，当请求到达时，工作线程通常已经存在，因此不会由于等待创建线程而延迟任务的执行，从而提高了响应性。

  ③通过适当调整线程池的大小，可以创建足够多的线程以便使处理器保持忙碌状态。同时还可以防止过多线程相互竞争资源而使应用程序耗尽内存或失败。

  改进的版本中，所以的I/O操作依旧由一个Reactor来完成，包括I/O的accept()、read()、write()以及connect()操作。

  对于一些小容量应用场景，可以使用单线程模型。但是对于高负载、大并发或大数据量的应用场景却不合适，主要原因如下：

  ①一个NIO线程同时处理成百上千的链路，性能上无法支撑，即便NIO线程的CPU负荷达到100%，也无法满足海量消息的读取和发送；

  ②当NIO线程负载过重之后，处理速度将变慢，这会导致大量客户端连接超时，超时之后往往会进行重发，这更加重了NIO线程的负载，最终会导致大量消息积压和处理超时，成为系统的性能瓶颈；

  主从多线程Reactor模式

  

  Reactor线程池中的每一Reactor线程都会有自己的Selector、线程和分发的事件循环逻辑。

  mainReactor可以只有一个，但subReactor一般会有多个。mainReactor线程主要负责接收客户端的连接请求，然后将接收到的SocketChannel传递给subReactor，由subReactor来完成和客户端的通信。

  流程：

  ①注册一个Acceptor事件处理器到mainReactor中，Acceptor事件处理器所关注的事件是ACCEPT事件，这样mainReactor会监听客户端向服务器端发起的连接请求事件(ACCEPT事件)。启动mainReactor的事件循环。

  ②客户端向服务器端发起一个连接请求，mainReactor监听到了该ACCEPT事件并将该ACCEPT事件派发给Acceptor处理器来进行处理。Acceptor处理器通过accept()方法得到与这个客户端对应的连接(SocketChannel)，然后将这个SocketChannel传递给subReactor线程池。

  ③ subReactor线程池分配一个subReactor线程给这个SocketChannel，即，将SocketChannel关注的READ事件以及对应的READ事件处理器注册到subReactor线程中。当然你也注册WRITE事件以及WRITE事件处理器到subReactor线程中以完成I/O写操作。Reactor线程池中的每一Reactor线程都会有自己的Selector、线程和分发的循环逻辑。

  ④当有I/O事件就绪时，相关的subReactor就将事件派发给响应的处理器处理。注意，这里subReactor线程只负责完成I/O的read()操作，在读取到数据后将业务逻辑的处理放入到线程池中完成，若完成业务逻辑后需要返回数据给客户端，则相关的I/O的write操作还是会被提交回subReactor线程来完成。

  注意，所以的I/O操作(包括，I/O的accept()、read()、write()以及connect()操作)依旧还是在Reactor线程(mainReactor线程或 subReactor线程)中完成的。Thread Pool(线程池)仅用来处理非I/O操作的逻辑。

  多Reactor线程模式将“接受客户端的连接请求”和“与该客户端的通信”分在了两个Reactor线程来完成。mainReactor完成接收客户端连接请求的操作，它不负责与客户端的通信，而是将建立好的连接转交给subReactor线程来完成与客户端的通信，这样一来就不会因为read()数据量太大而导致后面的客户端连接请求得不到即时处理的情况。并且多Reactor线程模式在海量的客户端并发请求的情况下，还可以通过实现subReactor线程池来将海量的连接分发给多个subReactor线程，在多核的操作系统中这能大大提升应用的负载和吞吐量。

  为什么不推荐使用JDK的NIO

  那么为什么我们不推荐使用JDK的NIO去实现，而是推荐使用Netty，这不是舍近求远吗？

  JDK的NIO是官方的，而Netty是 2004年由一个韩国人trust in Lee 开发的。能超越官方的，说明两个点。

  第一：Netty实现的功能更多，

  第二：Netty功能的实现更好。

  如果我们直接使用JDK的NIO，那么还需要做其他事情，比如要定义HTTP协议。这些都是我们需要去做的，而如果使用Netty的话，Netty已经帮我们封装好了。另外，如果我们走HTTP传输的话，那么就难以避免会出现粘包和半包问题，如果使用JDK的NIO，它是不会帮我们做这些事情的。而Netty已经帮助我们做好了。所以，做同样的事情，Netty实现的功能更多。

  Bug Database (java.com)

  

  JDK的NIO出现过5193个BUG。

  第二，Netty功能实现的更好，它体现在规避了JDK中NIO实现的BUG。比如，JDK的NIO有一个经典的BUG， 它叫做 epoll Bug,就是在Linux2.4的版本中

  它有时候会异常唤醒空转，从而导致CPU100%，导致我们程序卡死。并且这个问题在JDK中一直没有把它彻底解决。

  6670302

  

  而在Netty却很好的解决了这个BUG。所以，同样的功能，Netty实现的更好。

  8209152

  

  这个问题是Netty的使用者发现的，同时你看到的JDK是在12的版本后才解决这个问题