Java IO模型 NIO AIO 零拷贝

​​​​​​​https://mp.weixin.qq.com/s?__biz=MzkwMDE1MzkwNQ==&mid=2247495864&idx=2&sn=e75bd45f56fc6922bb66a5c8e271a790&source=41#wechat_redirect

https://tech.meituan.com/nio.html

看Netty权威指南第2章

看Linux  网络模型的那个笔记 Unix 5种网络模型

Java IO模型 （看Netty权威指南第2章）

java 中的 BIO、NIO和AIO理解为是 Java 语言在操作系统层面对这三种 IO 模型的封装。程序员在使用这些 封装API 的时候，不需要关心操作系统层面的知识，也不需要根据不同操作系统编写不同的代码，只需要使用Java的API就可以了。由此，为了使读者对这三种模型有个比较具体和递推式的了解，并且和本文主题NIO有个清晰的对比，下面继续延伸。

一、Java BIO

BIO编程方式通常是是Java的上古产品，自JDK 1.0-JDK1.4就有的东西。编程实现过程为：首先在服务端启动一个ServerSocket来监听网络请求，客户端启动Socket发起网络请求，默认情况下SeverSocket会建立一个线程来处理此请求，如果服务端没有线程可用，客户端则会阻塞等待或遭到拒绝。服务器实现模式为一个连接一个线程，即客户端有连接请求时服务器端就需要启动一个线程进行处理。大致结构如下：

如果要让 BIO 通信模型能够同时处理多个客户端请求，就必须使用多线程（主要原因是 socket.accept()、socket.read()、 socket.write() 涉及的三个主要函数都是同步阻塞的），也就是说它在接收到客户端连接请求之后为每个客户端创建一个新的线程进行链路处理，处理完成之后，通过输出流返回应答给客户端，线程销毁。这就是典型的 一请求一应答通信模型 。我们可以设想一下如果这个连接不做任何事情的话就会造成不必要的线程开销，不过可以通过线程池机制改善，线程池还可以让线程的创建和回收成本相对较低。使用线程池机制改善后的 BIO 模型图如下:

BIO方式适用于连接数目比较小且固定的架构，这种方式对服务器资源要求比较高，并发局限于应用中，是JDK1.4以前的唯一选择，但程序直观简单易懂。Java BIO编程示例网上很多，这里就不进行coding举例了，毕竟后面NIO才是重点。

二、Java 伪异步IO

三、Java NIO

NIO（New IO或者No-Blocking IO），从JDK1.4 开始引入的非阻塞IO，是一种非阻塞+ 同步的通信模式。这里的No Blocking IO用于区分上面的BIO。

NIO本身想解决 BIO的并发问题，通过Reactor模式的事件驱动机制来达到Non Blocking的。当 socket 有流可读或可写入 socket 时，操作系统会相应的通知应用程序进行处理，应用再将流读取到缓冲区或写入操作系统。

也就是说，这个时候，已经不是一个连接就 要对应一个处理线程了，而是有效的请求，对应一个线程，当连接没有数据时，是没有工作线程来处理的。

当一个连接创建后，不需要对应一个线程，这个连接会被注册到 多路复用器上面，所以所有的连接只需要一个线程就可以搞定，当这个线程中的多路复用器 进行轮询的时候，发现连接上有请求的话，才开启一个线程进行处理，也就是一个请求一个线程模式。

NIO提供了与传统BIO模型中的Socket和ServerSocket相对应的SocketChannel和ServerSocketChannel两种不同的套接字通道实现，如下图结构所示。这里涉及的Reactor设计模式、多路复用Selector、Buffer等暂时不用管，后面会讲到。

NIO 方式适用于连接数目多且连接比较短(轻操作)的架构，比如聊天服务器，并发局 限于应用中，编程复杂，JDK1.4 开始支持。同时，NIO和普通IO的区别主要可以从存储数据的载体、是否阻塞等来区分：

NIO和普通IO区别.png

四、Java AIO

与 NIO 不同，当进行读写操作时，只须直接调用 API 的 read 或 write 方法即可。这两种方法均为异步的，对于读操作而言，当有流可读取时，操作系统会将可读的流传入 read 方 法的缓冲区，并通知应用程序；对于写操作而言，当操作系统将 write 方法传递的流写入完毕时，操作系统主动通知应用程序。即可以理解为，read/write 方法都是异步的，完成后会主动调用回调函数。在 JDK7 中，提供了异步文件通道和异步套接字通道的实现，这部分内容被称作 NIO.

AIO 方式使用于连接数目多且连接比较长(重操作)的架构，比如相册服务器，充分调用 OS 参与并发操作，编程比较复杂，JDK7 开始支持。

目前来说 AIO 的应用还不是很广泛，Netty 之前也尝试使用过 AIO，不过又放弃了。

Java IO模型对比：

Java NIO存在的问题

使用NIO != 高性能，当连接数<1000，并发程度不高或者局域网环境下NIO并没有显著的性能优势。（主要说的是Selector）

NIO并没有完全屏蔽平台差异，它仍然是基于各个操作系统的I/O系统实现的，差异仍然存在。使用NIO做网络编程构建事件驱动模型并不容易，陷阱重重。

推荐大家使用成熟的NIO框架，如Netty，MINA等。解决了很多NIO的陷阱，并屏蔽了操作系统的差异，有较好的性能和编程模型。

New I/O

java.nio

新IO采用内存映射的方式来处理输入输出，新IO将文件或文件的一段区域映射到内存中。

为什么说NIO是基于缓冲区的IO方式呢？因为，当一个链接建立完成后，IO的数据未必会马上到达，为了当数据到达时能够正确完成IO操作，在BIO（阻塞IO）中，等待IO的线程必须被阻塞，以全天候地执行IO操作。为了解决这种IO方式低效的问题，引入了缓冲区的概念，当数据到达时，可以预先被写入缓冲区，再由缓冲区交给线程，因此线程无需阻塞地等待IO。 

Java NIO 由以下几个核心部分组成：

• Channels

• Buffers

• Selectors

Channel 和 Buffer

基本上，所有的 IO 在NIO 中都从一个Channel 开始。Channel 有点象流。 数据可以从Channel读到Buffer中，也可以从Buffer 写到Channel中。

• 既可以从通道中读取数据，又可以写数据到通道。但流的读写通常是单向的。

• 通道可以异步地读写。

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

主要Channel的实现：

• FileChannel  文件锁

• DatagramChannel

• SocketChannel

• ServerSocketChannel

关键的Buffer实现：

• ByteBuffer

• CharBuffer

• DoubleBuffer

• FloatBuffer

• IntBuffer

• LongBuffer

• ShortBuffer

Buffer  http://ifeve.com/buffers/

0 <= mark <= position <= limit <= capacity

Selector  SelectableChannel对象的多路复用器. 。

https://docs.oracle.com/javase/7/docs/api/java/nio/channels/Selector.html

Selector允许单线程处理多个 Channel。所以希望采用非阻塞方式进行通信的Channel都应注册到Selector对象。可以通过调用此类的open()静态方法来创建Selector实例，该方法使用系统默认的Selector来返回新的Selector。

Selector可以同时监控多个SelectableChannel的IO状况。一个Selector实例有3个SelectionKey的集合：

1.所有SelectionKey集合：代表了注册在该Selector上的Channel，这个集合可以通过keys()方法返回。

2.被选择的SelectionKey集合：代表了所有可通过select()方法监测到、需要进行IO处理的Channel，这个集合可以通过selectedKeys()返回。

3.被取消的SelectionKey集合：代表了所有被取消注册关系的Channel，在下一次执行select()方法时，这些Channel对应的SelectionKey会被彻底删除，程序通常无须直接访问该集合。

除此之外，Selector还提供了系列和select()相关的方法，如下所示：

  int select()：监控所有注册的Channel，当它们中间有需要处理的IO操作时，该方法返回，并将对应的SelectionKey加入被选择的SelectionKey集合中，该方法返回这些Channel的数量。

  int select(long timeout)：可以设置超时时长的select()操作。

  int selectNow()：执行一个立即返回的select()操作，相对于无参数的select()方法而言，该方法不会阻塞线程。

  Selector wakeup()：使一个还未返回的select()方法立刻返回。

当Selector上注册的所有Channel都没有需要处理的IO操作时，select()方法将被阻塞，调用该方法的线程被阻塞。

Selector.wakeup()

主要作用

解除阻塞在Selector.select()/select(long)上的线程，立即返回。

两次成功的select之间多次调用wakeup等价于一次调用。

如果当前没有阻塞在select上，则本次wakeup调用将作用于下一次select——“记忆”作用。

为什么要唤醒？

注册了新的channel或者事件。

channel关闭，取消注册。

优先级更高的事件触发（如定时器事件），希望及时处理。

原理

Linux上利用pipe调用创建一个管道，Windows上则是一个loopback的tcp连接。这是因为win32的管道无法加入select的fd set，将管道或者TCP连接加入select fd set。

wakeup往管道或者连接写入一个字节，阻塞的select因为有I/O事件就绪，立即返回。可见，wakeup的调用开销不可忽视。

  SelectableChannel：它代表可以支持非阻塞IO操作的Channel对象，可以将其注册到Selector上，这种注册的关系由SelectionKey实例表示。Selector对象提供了一个select()方法，该方法允许应用程序同时监控多个IO Channel。

应用程序可调用SelectableChannel 的register()方法将其注册到指定Selector上，当该Selector上某些SelectableChannel上有需要处理的IO操作时，程序可以调用Selector实例的select()方法获取它们的数量，并可以通过selectedKeys()方法返回它们对应的SelectKey集合——通过该集合就可以获取所有需要处理IO操作的SelectableChannel集。

SelectableChannel对象支持阻塞和非阻塞两种模式（所有channel默认都是阻塞模式），必须使用非阻塞式模式才可以利用非阻塞IO操作。SelectableChannel提供了如下两个方法来设置和返回该Channel的模式状态：

ü  SelectableChannel configureBlocking(boolean block)：设置是否采用阻塞模式。

ü  boolean isBlocking()：返回该Channel是否是阻塞模式。

不同的SelectableChannel所支持的操作不一样，例如ServerSocketChannel代表一个ServerSocket，它就只支持OP_ACCEPT操作。SelectableChannel提供如下方法来返回它支持的所有操作：

ü  int validOps() ：返回一个bit mask，表示这个channel上支持的IO操作。

在SelectionKey中，用静态常量定义了4种IO操作：OP_READ（1）、OP_WRITE（4）、OP_CONNECT（8）、OP_ACCEP（16），这四值任意2个、3个、4个进行按位或的结果和相加的结果相等，而且它们任意2个、3个、4个相加的结果总是互不相同，所以系统可以根据validOps()方法的返回值确定该SelectableChannel支持的操作。例如返回5，我们知道它支持读（1）和写（4）。

除此之外，SelectableChannel还提供了如下几个方法来获取它的注册状态：

ü  boolean isRegistered()：返回该Channel是否已注册在一个或多个Selector上。

ü  SelectionKey keyFor(Selector sel)：返回该Channel和sel Selector之间的注册关系，如果不存在注册关系，则返回null。

Ø  SelectionKey：该对象代表SelectableChannel和Selector之间的注册关系。

Ø  ServerSocketChannel：支持非阻塞操作，对应于java.net.ServerSocket这个类，提供了TCP协议IO接口，只支持OP_ACCEPT操作。该类也提供了accept()方法，功能相当于ServerSocket提供的accept()方法。

Ø  SocketChannel：支持非阻塞操作，对应于java.net.Socket这个类，提供了TCP协议IO接口，支持OP_CONNECT，OP_READ和OP_WRITE操作。这个类还实现了ByteChannel接口、ScatteringByteChannel接口和GatheringByteChannel接口，所以可以直接通过SocketChannel来读写ByteBuffer对象。

这是在一个单线程中使用一个Selector处理3个Channel的图示：

要使用Selector，得向Selector注册Channel，然后调用它的select()方法。这个方法会一直阻塞到某个注册的通道有事件就绪。一旦这个方法返回，线程就可以处理这些事件，事件的例子有如新连接进来，数据接收等。

为什么使用Selector?

仅用单个线程来处理多个Channels的好处是，只需要更少的线程来处理通道。事实上，可以只用一个线程处理所有的通道。对于操作系统来说，线程之间上下文切换的开销很大，而且每个线程都要占用系统的一些资源（如内存）。因此，使用的线程越少越好。

但是，需要记住，现代的操作系统和CPU在多任务方面表现的越来越好，所以多线程的开销随着时间的推移，变得越来越小了。实际上，如果一个CPU有多个内核，不使用多任务可能是在浪费CPU能力。不管怎么说，关于那种设计的讨论应该放在另一篇不同的文章中。在这里，只要知道使用Selector能够处理多个通道就足够了。

传统的BIO里面socket.read()，如果TCP RecvBuffer里没有数据，函数会一直阻塞，直到收到数据，返回读到的数据。

对于NIO，如果TCP RecvBuffer有数据，就把数据从网卡读到内存，并且返回给用户；反之则直接返回0，永远不会阻塞。

最新的AIO(Async I/O)里面会更进一步：不但等待就绪是非阻塞的，就连数据从网卡到内存的过程也是异步的。

换句话说，BIO里用户最关心“我要读”，NIO里用户最关心"我可以读了"，在AIO模型里用户更需要关注的是“读完了”。

NIO一个重要的特点是：socket主要的读、写、注册和接收函数，在等待就绪阶段都是非阻塞的，真正的I/O操作是同步阻塞的（消耗CPU但性能非常高）。

AIO   异步IO

异步Channel

Linux是不支持AIO的，因此基于AIO的程序运行在Linux上的效率相比NIO反而更低。而Linux是最主要的服务器OS，因此相比AIO，目前NIO的应用更加广泛。

Proactor与Reactor

一般情况下，I/O 复用机制需要事件分发器（event dispatcher）。 事件分发器的作用，即将那些读写事件源分发给各读写事件的处理者，就像送快递的在楼下喊: 谁谁谁的快递到了， 快来拿吧！开发人员在开始的时候需要在分发器那里注册感兴趣的事件，并提供相应的处理者（event handler)，或者是回调函数；事件分发器在适当的时候，会将请求的事件分发给这些handler或者回调函数。

涉及到事件分发器的两种模式称为：Reactor和Proactor。 Reactor模式是基于同步I/O的，而Proactor模式是和异步I/O相关的。在Reactor模式中，事件分发器等待某个事件或者可应用或个操作的状态发生（比如文件描述符可读写，或者是socket可读写），事件分发器就把这个事件传给事先注册的事件处理函数或者回调函数，由后者来做实际的读写操作。

而在Proactor模式中，事件处理者（或者代由事件分发器发起）直接发起一个异步读写操作（相当于请求），而实际的工作是由操作系统来完成的。发起时，需要提供的参数包括用于存放读到数据的缓存区、读的数据大小或用于存放外发数据的缓存区，以及这个请求完后的回调函数等信息。事件分发器得知了这个请求，它默默等待这个请求的完成，然后转发完成事件给相应的事件处理者或者回调。举例来说，在Windows上事件处理者投递了一个异步IO操作（称为overlapped技术），事件分发器等IO Complete事件完成。这种异步模式的典型实现是基于操作系统底层异步API的，所以我们可称之为“系统级别”的或者“真正意义上”的异步，因为具体的读写是由操作系统代劳的。

举个例子，将有助于理解Reactor与Proactor二者的差异，以读操作为例（写操作类似）。

在Reactor中实现读

• 注册读就绪事件和相应的事件处理器。

• 事件分发器等待事件。

• 事件到来，激活分发器，分发器调用事件对应的处理器。

• 事件处理器完成实际的读操作，处理读到的数据，注册新的事件，然后返还控制权。

在Proactor中实现读：

• 处理器发起异步读操作（注意：操作系统必须支持异步IO）。在这种情况下，处理器无视IO就绪事件，它关注的是完成事件。

• 事件分发器等待操作完成事件。

• 在分发器等待过程中，操作系统利用并行的内核线程执行实际的读操作，并将结果数据存入用户自定义缓冲区，最后通知事件分发器读操作完成。

• 事件分发器呼唤处理器。

• 事件处理器处理用户自定义缓冲区中的数据，然后启动一个新的异步操作，并将控制权返回事件分发器。

可以看出，两个模式的相同点，都是对某个I/O事件的事件通知（即告诉某个模块，这个I/O操作可以进行或已经完成)。在结构上，两者也有相同点：事件分发器负责提交IO操作（异步)、查询设备是否可操作（同步)，然后当条件满足时，就回调handler；不同点在于，异步情况下（Proactor)，当回调handler时，表示I/O操作已经完成；同步情况下（Reactor)，回调handler时，表示I/O设备可以进行某个操作（can read 或 can write)。

下面，我们将尝试应对为Proactor和Reactor模式建立可移植框架的挑战。在改进方案中，我们将Reactor原来位于事件处理器内的Read/Write操作移至分发器（不妨将这个思路称为“模拟异步”），以此寻求将Reactor多路同步I/O转化为模拟异步I/O。以读操作为例子，改进过程如下：

• 注册读就绪事件和相应的事件处理器。并为分发器提供数据缓冲区地址，需要读取数据量等信息。

• 分发器等待事件（如在select()上等待）。

• 事件到来，激活分发器。分发器执行一个非阻塞读操作（它有完成这个操作所需的全部信息），最后调用对应处理器。

• 事件处理器处理用户自定义缓冲区的数据，注册新的事件（当然同样要给出数据缓冲区地址，需要读取的数据量等信息），最后将控制权返还分发器。

  如我们所见，通过对多路I/O模式功能结构的改造，可将Reactor转化为Proactor模式。改造前后，模型实际完成的工作量没有增加，只不过参与者间对工作职责稍加调换。没有工作量的改变，自然不会造成性能的削弱。对如下各步骤的比较，可以证明工作量的恒定：

标准/典型的Reactor：

• 步骤1：等待事件到来（Reactor负责）。

• 步骤2：将读就绪事件分发给用户定义的处理器（Reactor负责）。

• 步骤3：读数据（用户处理器负责）。

• 步骤4：处理数据（用户处理器负责）。

改进实现的模拟Proactor：

• 步骤1：等待事件到来（Proactor负责）。

• 步骤2：得到读就绪事件，执行读数据（现在由Proactor负责）。

• 步骤3：将读完成事件分发给用户处理器（Proactor负责）。

• 步骤4：处理数据（用户处理器负责）。

  对于不提供异步I/O API的操作系统来说，这种办法可以隐藏Socket API的交互细节，从而对外暴露一个完整的异步接口。借此，我们就可以进一步构建完全可移植的，平台无关的，有通用对外接口的解决方案。

NIO和IO到底有什么区别？有什么关系？

首先说一下核心区别：

1. NIO是以块的方式处理数据，但是IO是以最基础的字节流的形式去写入和读出的。所以在效率上的话，肯定是NIO效率比IO效率会高出很多。

2. NIO不在是和IO一样用OutputStream和InputStream 输入流的形式来进行处理数据的，但是又是基于这种流的形式，而是采用了通道和缓冲区的形式来进行处理数据的。

3. 还有一点就是NIO的通道是可以双向的，但是IO中的流只能是单向的。

4. 还有就是NIO的缓冲区（其实也就是一个字节数组）还可以进行分片，可以建立只读缓冲区、直接缓冲区和间接缓冲区，只读缓冲区很明显就是字面意思，直接缓冲区是为加快 I/O 速度，而以一种特殊的方式分配其内存的缓冲区。

5. 补充一点：NIO比传统的BIO核心区别就是，NIO采用的是多路复用的IO模型，普通的IO用的是阻塞的IO模型，两个之间的效率肯定是多路复用效率更高

缓冲区是什么意思：

• Buffer 是一个对象， 它包含一些要写入或者刚读出的数据。在 NIO 中加入 Buffer 对象，体现了新库与原 I/O 的一个重要区别。在面向流的 I/O 中，您将数据直接写入或者将数据直接读到 Stream 对象中

• 在 NIO 库中，所有数据都是用缓冲区处理的。在读取数据时，它是直接读到缓冲区中的。在写入数据时，它是写入到缓冲区中的。任何时候访问 NIO 中的数据，您都是将它放到缓冲区中。

• 缓冲区实质上是一个数组。通常它是一个字节数组，但是也可以使用其他种类的数组。但是一个缓冲区不 仅仅 是一个数组。缓冲区提供了对数据的结构化访问，而且还可以跟踪系统的读/写进程

Java NIO 由以下几个核心部分组成： 

- Channels

- Buffers

- Selectors

Channel 和 Buffer

基本上，所有的 IO 在NIO 中都从一个Channel 开始。Channel 有点象流。 数据可以从Channel读到Buffer中，也可以从Buffer 写到Channel中。这里有个图示：

Channel和Buffer有好几种类型。下面是JAVA NIO中的一些主要Channel的实现： 

• FileChannel

• DatagramChannel

• SocketChannel

• ServerSocketChannel

正如你所看到的，这些通道涵盖了UDP 和 TCP 网络IO，以及文件IO。 

与这些类一起的有一些有趣的接口，但为简单起见，我尽量在概述中不提到它们。本教程其它章节与它们相关的地方我会进行解释。 

以下是Java NIO里关键的Buffer实现： 

• ByteBuffer

• CharBuffer

• DoubleBuffer

• FloatBuffer

• IntBuffer

• LongBuffer

• ShortBuffer

这些Buffer覆盖了你能通过IO发送的基本数据类型：byte, short, int, long, float, double 和 char。 

Java NIO 还有个 Mappedyteuffer，用于表示内存映射文件， 我也不打算在概述中说明。 

Buffer的基本用法

使用Buffer读写数据一般遵循以下四个步骤：

1. 写入数据到Buffer

2. 调用flip()方法

3. 从Buffer中读取数据

4. 调用clear()方法或者compact()方法

当向buffer写入数据时，buffer会记录下写了多少数据。一旦要读取数据，需要通过flip()方法将Buffer从写模式切换到读模式。在读模式下，可以读取之前写入到buffer的所有数据。

一旦读完了所有的数据，就需要清空缓冲区，让它可以再次被写入。有两种方式能清空缓冲区：调用clear()或compact()方法。clear()方法会清空整个缓冲区。compact()方法只会清除已经读过的数据。任何未读的数据都被移到缓冲区的起始处，新写入的数据将放到缓冲区未读数据的后面。

Buffer的capacity,position和limit

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

为了理解Buffer的工作原理，需要熟悉它的三个属性：

• capacity

• position

• limit

position和limit的含义取决于Buffer处在读模式还是写模式。不管Buffer处在什么模式，capacity的含义总是一样的。

这里有一个关于capacity，position和limit在读写模式中的说明，详细的解释在插图后面。

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的例子。

1	ByteBuffer buf = ByteBuffer.allocate(48);

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

1	CharBuffer buf = CharBuffer.allocate(1024);

向Buffer中写数据

写数据到Buffer有两种方式：

• 从Channel写到Buffer。

• 通过Buffer的put()方法写到Buffer里。

从Channel写到Buffer的例子

1	int bytesRead = inChannel.read(buf); //read into buffer.

通过put方法写Buffer的例子：

1	buf.put(127);

put方法有很多版本，允许你以不同的方式把数据写入到Buffer中。例如， 写到一个指定的位置，或者把一个字节数组写入到Buffer。 更多Buffer实现的细节参考JavaDoc。

flip()方法

flip方法将Buffer从写模式切换到读模式。调用flip()方法会将position设回0，并将limit设置成之前position的值。

换句话说，position现在用于标记读的位置，limit表示之前写进了多少个byte、char等 —— 现在能读取多少个byte、char等。

从Buffer中读取数据

从Buffer中读取数据有两种方式：

1. 从Buffer读取数据到Channel。

2. 使用get()方法从Buffer中读取数据。

从Buffer读取数据到Channel的例子：

1	//read from buffer into channel.

2	int bytesWritten = inChannel.write(buf);

使用get()方法从Buffer中读取数据的例子

1	byte aByte = buf.get();

get方法有很多版本，允许你以不同的方式从Buffer中读取数据。例如，从指定position读取，或者从Buffer中读取数据到字节数组。更多Buffer实现的细节参考JavaDoc。

rewind()方法

Buffer.rewind()将position设回0，所以你可以重读Buffer中的所有数据。limit保持不变，仍然表示能从Buffer中读取多少个元素（byte、char等）。

clear()与compact()方法

一旦读完Buffer中的数据，需要让Buffer准备好再次被写入。可以通过clear()或compact()方法来完成。

如果调用的是clear()方法，position将被设回0，limit被设置成 capacity的值。换句话说，Buffer 被清空了。Buffer中的数据并未清除，只是这些标记告诉我们可以从哪里开始往Buffer里写数据。

如果Buffer中有一些未读的数据，调用clear()方法，数据将“被遗忘”，意味着不再有任何标记会告诉你哪些数据被读过，哪些还没有。

如果Buffer中仍有未读的数据，且后续还需要这些数据，但是此时想要先先写些数据，那么使用compact()方法。

compact()方法将所有未读的数据拷贝到Buffer起始处。然后将position设到最后一个未读元素正后面。limit属性依然像clear()方法一样，设置成capacity。现在Buffer准备好写数据了，但是不会覆盖未读的数据。

mark()与reset()方法

通过调用Buffer.mark()方法，可以标记Buffer中的一个特定position。之后可以通过调用Buffer.reset()方法恢复到这个position。例如：

1	buffer.mark();

2

3	//call buffer.get() a couple of times, e.g. during parsing.

4

5	buffer.reset();  //set position back to mark.

equals()与compareTo()方法

可以使用equals()和compareTo()方法两个Buffer。

equals()

当满足下列条件时，表示两个Buffer相等：

1. 有相同的类型（byte、char、int等）。

2. Buffer中剩余的byte、char等的个数相等。

3. Buffer中所有剩余的byte、char等都相同。

如你所见，equals只是比较Buffer的一部分，不是每一个在它里面的元素都比较。实际上，它只比较Buffer中的剩余元素。

compareTo()方法

compareTo()方法比较两个Buffer的剩余元素(byte、char等)， 如果满足下列条件，则认为一个Buffer“小于”另一个Buffer：

1. 第一个不相等的元素小于另一个Buffer中对应的元素 。

2. 所有元素都相等，但第一个Buffer比另一个先耗尽(第一个Buffer的元素个数比另一个少)。

Java NIO开始支持scatter/gather，scatter/gather用于描述从Channel（译者注：Channel在中文经常翻译为通道）中读取或者写入到Channel的操作。

分散（scatter）从Channel中读取是指在读操作时将读取的数据写入多个buffer中。因此，Channel将从Channel中读取的数据“分散（scatter）”到多个Buffer中。

聚集（gather）写入Channel是指在写操作时将多个buffer的数据写入同一个Channel，因此，Channel 将多个Buffer中的数据“聚集（gather）”后发送到Channel。

scatter / gather经常用于需要将传输的数据分开处理的场合，例如传输一个由消息头和消息体组成的消息，你可能会将消息体和消息头分散到不同的buffer中，这样你可以方便的处理消息头和消息体。

Scattering Reads

Scattering Reads是指数据从一个channel读取到多个buffer中。如下图描述：

正在上传…重新上传取消

Java NIO: Scattering Read

代码示例如下：

1	ByteBuffer header = ByteBuffer.allocate(128);

2	ByteBuffer body   = ByteBuffer.allocate(1024);

3

4	ByteBuffer[] bufferArray = { header, body };

5

6	channel.read(bufferArray);

注意buffer首先被插入到数组，然后再将数组作为channel.read() 的输入参数。read()方法按照buffer在数组中的顺序将从channel中读取的数据写入到buffer，当一个buffer被写满后，channel紧接着向另一个buffer中写。

Scattering Reads在移动下一个buffer前，必须填满当前的buffer，这也意味着它不适用于动态消息(译者注：消息大小不固定)。换句话说，如果存在消息头和消息体，消息头必须完成填充（例如 128byte），Scattering Reads才能正常工作。

Gathering Writes

Gathering Writes是指数据从多个buffer写入到同一个channel。如下图描述：

正在上传…重新上传取消

Java NIO: Gathering Write

代码示例如下：

1	ByteBuffer header = ByteBuffer.allocate(128);

2	ByteBuffer body   = ByteBuffer.allocate(1024);

3

4	//write data into buffers

5

6	ByteBuffer[] bufferArray = { header, body };

7

8	channel.write(bufferArray);

buffers数组是write()方法的入参，write()方法会按照buffer在数组中的顺序，将数据写入到channel，注意只有position和limit之间的数据才会被写入。因此，如果一个buffer的容量为128byte，但是仅仅包含58byte的数据，那么这58byte的数据将被写入到channel中。因此与Scattering Reads相反，Gathering Writes能较好的处理动态消息。

Selector 

Selector允许单线程处理多个 Channel。如果你的应用打开了多个连接（通道），但每个连接的流量都很低，使用Selector就会很方便。例如，在一个聊天服务器中。 

这是在一个单线程中使用一个Selector处理3个Channel的图示： 

要使用Selector，得向Selector注册Channel，然后调用它的select()方法。这个方法会一直阻塞到某个注册的通道有事件就绪。一旦这个方法返回，线程就可以处理这些事件，事件的例子有如新连接进来，数据接收等。

要使用Selector，得向Selector注册Channel，然后调用它的select()方法。这个方法会一直阻塞到某个注册的通道有事件就绪。一旦这个方法返回，线程就可以处理这些事件，事件的例子有如新连接进来，数据接收等。 

Java NIO和IO的主要区别 

下表总结了Java NIO和IO之间的主要差别，我会更详细地描述表中每部分的差异。 

IO	NIO
Stream oriented	Buffer oriented
Blocking IO	Non blocking IO
	Selectors

面向流与面向缓冲 

Java NIO和IO之间第一个最大的区别是，IO是面向流的，NIO是面向缓冲区的。 Java IO面向流意味着每次从流中读一个或多个字节，直至读取所有字节，它们没有被缓存在任何地方。此外，它不能前后移动流中的数据。如果需要前后移动从流中读取的数据，需要先将它缓存到一个缓冲区。 Java NIO的缓冲导向方法略有不同。数据读取到一个它稍后处理的缓冲区，需要时可在缓冲区中前后移动。这就增加了处理过程中的灵活性。但是，还需要检查是否该缓冲区中包含所有您需要处理的数据。而且，需确保当更多的数据读入缓冲区时，不要覆盖缓冲区里尚未处理的数据。 

阻塞与非阻塞IO 

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

选择器（Selectors） 

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

Selector（选择器）是Java NIO中能够检测一到多个NIO通道，并能够知晓通道是否为诸如读写事件做好准备的组件。这样，一个单独的线程可以管理多个channel，从而管理多个网络连接。

下面是本文所涉及到的主题列表：

1. 为什么使用Selector?

2. Selector的创建

3. 向Selector注册通道

4. SelectionKey

5. 通过Selector选择通道

6. wakeUp()

7. close()

8. 完整的示例

为什么使用Selector?

仅用单个线程来处理多个Channels的好处是，只需要更少的线程来处理通道。事实上，可以只用一个线程处理所有的通道。对于操作系统来说，线程之间上下文切换的开销很大，而且每个线程都要占用系统的一些资源（如内存）。因此，使用的线程越少越好。

但是，需要记住，现代的操作系统和CPU在多任务方面表现的越来越好，所以多线程的开销随着时间的推移，变得越来越小了。实际上，如果一个CPU有多个内核，不使用多任务可能是在浪费CPU能力。不管怎么说，关于那种设计的讨论应该放在另一篇不同的文章中。在这里，只要知道使用Selector能够处理多个通道就足够了。

下面是单线程使用一个Selector处理3个channel的示例图：

Selector的创建

通过调用Selector.open()方法创建一个Selector，如下：

1	Selector selector = Selector.open();

向Selector注册通道

为了将Channel和Selector配合使用，必须将channel注册到selector上。通过SelectableChannel.register()方法来实现，如下：

1	channel.configureBlocking(false);

2	SelectionKey key = channel.register(selector,

3	Selectionkey.OP_READ);

与Selector一起使用时，Channel必须处于非阻塞模式下。这意味着不能将FileChannel与Selector一起使用，因为FileChannel不能切换到非阻塞模式。而套接字通道都可以。

注意register()方法的第二个参数。这是一个“interest集合”，意思是在通过Selector监听Channel时对什么事件感兴趣。可以监听四种不同类型的事件：

1. Connect

2. Accept

3. Read

4. Write

通道触发了一个事件意思是该事件已经就绪。所以，某个channel成功连接到另一个服务器称为“连接就绪”。一个server socket channel准备好接收新进入的连接称为“接收就绪”。一个有数据可读的通道可以说是“读就绪”。等待写数据的通道可以说是“写就绪”。

这四种事件用SelectionKey的四个常量来表示：

1. SelectionKey.OP_CONNECT

2. SelectionKey.OP_ACCEPT

3. SelectionKey.OP_READ

4. SelectionKey.OP_WRITE

如果你对不止一种事件感兴趣，那么可以用“位或”操作符将常量连接起来，如下：

1	int interestSet = SelectionKey.OP_READ | SelectionKey.OP_WRITE;

在下面还会继续提到interest集合。

SelectionKey

在上一小节中，当向Selector注册Channel时，register()方法会返回一个SelectionKey对象。这个对象包含了一些你感兴趣的属性：

• interest集合

• ready集合

• Channel

• Selector

• 附加的对象（可选）

下面我会描述这些属性。

interest集合

就像向Selector注册通道一节中所描述的，interest集合是你所选择的感兴趣的事件集合。可以通过SelectionKey读写interest集合，像这样：

1	int interestSet = selectionKey.interestOps();

2

3	boolean isInterestedInAccept  = (interestSet & SelectionKey.OP_ACCEPT) == SelectionKey.OP_ACCEPT；

4	boolean isInterestedInConnect = interestSet & SelectionKey.OP_CONNECT;

5	boolean isInterestedInRead    = interestSet & SelectionKey.OP_READ;

6	boolean isInterestedInWrite   = interestSet & SelectionKey.OP_WRITE;

可以看到，用“位与”操作interest 集合和给定的SelectionKey常量，可以确定某个确定的事件是否在interest 集合中。

ready集合

ready 集合是通道已经准备就绪的操作的集合。在一次选择(Selection)之后，你会首先访问这个ready set。Selection将在下一小节进行解释。可以这样访问ready集合：

1	int readySet = selectionKey.readyOps();

可以用像检测interest集合那样的方法，来检测channel中什么事件或操作已经就绪。但是，也可以使用以下四个方法，它们都会返回一个布尔类型：

1	selectionKey.isAcceptable();

2	selectionKey.isConnectable();

3	selectionKey.isReadable();

4	selectionKey.isWritable();

Channel + Selector

从SelectionKey访问Channel和Selector很简单。如下：

1	Channel  channel  = selectionKey.channel();

2	Selector selector = selectionKey.selector();

附加的对象

可以将一个对象或者更多信息附着到SelectionKey上，这样就能方便的识别某个给定的通道。例如，可以附加 与通道一起使用的Buffer，或是包含聚集数据的某个对象。使用方法如下：

1	selectionKey.attach(theObject);

2	Object attachedObj = selectionKey.attachment();

还可以在用register()方法向Selector注册Channel的时候附加对象。如：

1	SelectionKey key = channel.register(selector, SelectionKey.OP_READ, theObject);

通过Selector选择通道

一旦向Selector注册了一或多个通道，就可以调用几个重载的select()方法。这些方法返回你所感兴趣的事件（如连接、接受、读或写）已经准备就绪的那些通道。换句话说，如果你对“读就绪”的通道感兴趣，select()方法会返回读事件已经就绪的那些通道。

下面是select()方法：

• int select()

• int select(long timeout)

• int selectNow()

select()阻塞到至少有一个通道在你注册的事件上就绪了。

select(long timeout)和select()一样，除了最长会阻塞timeout毫秒(参数)。

selectNow()不会阻塞，不管什么通道就绪都立刻返回（译者注：此方法执行非阻塞的选择操作。如果自从前一次选择操作后，没有通道变成可选择的，则此方法直接返回零。）。

select()方法返回的int值表示有多少通道已经就绪。亦即，自上次调用select()方法后有多少通道变成就绪状态。如果调用select()方法，因为有一个通道变成就绪状态，返回了1，若再次调用select()方法，如果另一个通道就绪了，它会再次返回1。如果对第一个就绪的channel没有做任何操作，现在就有两个就绪的通道，但在每次select()方法调用之间，只有一个通道就绪了。

selectedKeys()

一旦调用了select()方法，并且返回值表明有一个或更多个通道就绪了，然后可以通过调用selector的selectedKeys()方法，访问“已选择键集（selected key set）”中的就绪通道。如下所示：

1	Set selectedKeys = selector.selectedKeys();

当像Selector注册Channel时，Channel.register()方法会返回一个SelectionKey 对象。这个对象代表了注册到该Selector的通道。可以通过SelectionKey的selectedKeySet()方法访问这些对象。

可以遍历这个已选择的键集合来访问就绪的通道。如下：

01	Set selectedKeys = selector.selectedKeys();

02	Iterator keyIterator = selectedKeys.iterator();

03	while(keyIterator.hasNext()) {

04	SelectionKey key = keyIterator.next();

05	if(key.isAcceptable()) {

06	// a connection was accepted by a ServerSocketChannel.

07	} else if (key.isConnectable()) {

08	// a connection was established with a remote server.

09	} else if (key.isReadable()) {

10	// a channel is ready for reading

11	} else if (key.isWritable()) {

12	// a channel is ready for writing

13

}

14	keyIterator.remove();

15

}

这个循环遍历已选择键集中的每个键，并检测各个键所对应的通道的就绪事件。

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

SelectionKey.channel()方法返回的通道需要转型成你要处理的类型，如ServerSocketChannel或SocketChannel等。

wakeUp()

某个线程调用select()方法后阻塞了，即使没有通道已经就绪，也有办法让其从select()方法返回。只要让其它线程在第一个线程调用select()方法的那个对象上调用Selector.wakeup()方法即可。阻塞在select()方法上的线程会立马返回。

如果有其它线程调用了wakeup()方法，但当前没有线程阻塞在select()方法上，下个调用select()方法的线程会立即“醒来（wake up）”。

close()

用完Selector后调用其close()方法会关闭该Selector，且使注册到该Selector上的所有SelectionKey实例无效。通道本身并不会关闭。

完整的示例

这里有一个完整的示例，打开一个Selector，注册一个通道注册到这个Selector上(通道的初始化过程略去),然后持续监控这个Selector的四种事件（接受，连接，读，写）是否就绪。

01	Selector selector = Selector.open();

02	channel.configureBlocking(false);

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

04	while(true) {

05	int readyChannels = selector.select();

06	if(readyChannels == 0) continue;

07	Set selectedKeys = selector.selectedKeys();

08	Iterator keyIterator = selectedKeys.iterator();

09	while(keyIterator.hasNext()) {

10	SelectionKey key = keyIterator.next();

11	if(key.isAcceptable()) {

12	// a connection was accepted by a ServerSocketChannel.

13	} else if (key.isConnectable()) {

14	// a connection was established with a remote server.

15	} else if (key.isReadable()) {

16	// a channel is ready for reading

17	} else if (key.isWritable()) {

18	// a channel is ready for writing

19

}

20	keyIterator.remove();

21

}

22

}

零拷贝  https://mp.weixin.qq.com/s/fygQ5rXJc8mm3eWTXQA5sA

https://mp.weixin.qq.com/s/FN5ChS0se5AD0NaawDXxMA

零拷贝，从字面意思理解就是数据不需要来回的拷贝，大大提升了系统的性能。我们也经常在 Java NIO，Netty，Kafka，RocketMQ 等框架中听到零拷贝，它经常作为其提升性能的一大亮点；下面从 I/O 的几个概念开始，进而再分析零拷贝。

I/O 概念

缓冲区

缓冲区是所有 I/O 的基础，I/O 讲的无非就是把数据移进或移出缓冲区；进程执行 I/O 操作，就是向操作系统发出请求，让它要么把缓冲区的数据排干(写)，要么填充缓冲区（读）。

下面看一个 Java 进程发起 Read 请求加载数据大致的流程图：

进程发起 Read 请求之后，内核接收到 Read 请求之后，会先检查内核空间中是否已经存在进程所需要的数据，如果已经存在，则直接把数据 Copy 给进程的缓冲区。

如果没有内核随即向磁盘控制器发出命令，要求从磁盘读取数据，磁盘控制器把数据直接写入内核 Read 缓冲区，这一步通过 DMA 完成。

接下来就是内核将数据 Copy 到进程的缓冲区；如果进程发起 Write 请求，同样需要把用户缓冲区里面的数据 Copy 到内核的 Socket 缓冲区里面，然后再通过 DMA 把数据 Copy 到网卡中，发送出去。

你可能觉得这样挺浪费空间的，每次都需要把内核空间的数据拷贝到用户空间中，所以零拷贝的出现就是为了解决这种问题的。

关于零拷贝提供了两种方式分别是：

• mmap+write

• Sendfile

虚拟内存

所有现代操作系统都使用虚拟内存，使用虚拟的地址取代物理地址，这样做的好处是：

• 一个以上的虚拟地址可以指向同一个物理内存地址。

• 虚拟内存空间可大于实际可用的物理地址。

利用第一条特性可以把内核空间地址和用户空间的虚拟地址映射到同一个物理地址，这样 DMA 就可以填充对内核和用户空间进程同时可见的缓冲区了。

大致如下图所示：

省去了内核与用户空间的往来拷贝，Java 也利用操作系统的此特性来提升性能，下面重点看看 Java 对零拷贝都有哪些支持。

mmap+write 方式

使用 mmap+write 方式代替原来的 read+write 方式，mmap 是一种内存映射文件的方法，即将一个文件或者其他对象映射到进程的地址空间，实现文件磁盘地址和进程虚拟地址空间中一段虚拟地址的一一对应关系。

这样就可以省掉原来内核 Read 缓冲区 Copy 数据到用户缓冲区，但是还是需要内核 Read 缓冲区将数据 Copy 到内核 Socket 缓冲区。

大致如下图所示：

Sendfile 方式

Sendfile 系统调用在内核版本 2.1 中被引入，目的是简化通过网络在两个通道之间进行的数据传输过程。

Sendfile 系统调用的引入，不仅减少了数据复制，还减少了上下文切换的次数，大致如下图所示：数据传送只发生在内核空间，所以减少了一次上下文切换；但是还是存在一次 Copy，能不能把这一次 Copy 也省略掉？

Linux2.4 内核中做了改进，将 Kernel buffer 中对应的数据描述信息（内存地址，偏移量）记录到相应的 Socket 缓冲区当中，这样连内核空间中的一次 CPU Copy 也省掉了。

Java 零拷贝

MappedByteBuffer

Java NIO 提供的 FileChannel 提供了 map() 方法，该方法可以在一个打开的文件和 MappedByteBuffer 之间建立一个虚拟内存映射。

MappedByteBuffer 继承于 ByteBuffer，类似于一个基于内存的缓冲区，只不过该对象的数据元素存储在磁盘的一个文件中。

调用 get() 方法会从磁盘中获取数据，此数据反映该文件当前的内容，调用 put() 方法会更新磁盘上的文件，并且对文件做的修改对其他阅读者也是可见的。

下面看一个简单的读取实例，然后再对 MappedByteBuffer 进行分析：

public class MappedByteBufferTest {

    public static void main(String[] args) throws Exception {

        File file = new File("D://db.txt");

        long len = file.length();

        byte[] ds = new byte[(int) len];

        MappedByteBuffer mappedByteBuffer = new FileInputStream(file).getChannel().map(FileChannel.MapMode.READ_ONLY, 0,

                len);

        for (int offset = 0; offset < len; offset++) {

            byte b = mappedByteBuffer.get();

            ds[offset] = b;

        }

        Scanner scan = new Scanner(new ByteArrayInputStream(ds)).useDelimiter(" ");

        while (scan.hasNext()) {

            System.out.print(scan.next() + " ");

        }

    }

}

主要通过 FileChannel 提供的 map() 来实现映射，map() 方法如下：

    public abstract MappedByteBuffer map(MapMode mode,

                                         long position, long size)

        throws IOException;

分别提供了三个参数，MapMode，Position 和 Size，分别表示：

• MapMode：映射的模式，可选项包括：READ_ONLY，READ_WRITE，PRIVATE。

• Position：从哪个位置开始映射，字节数的位置。

• Size：从 Position 开始向后多少个字节。

重点看一下 MapMode，前两个分别表示只读和可读可写，当然请求的映射模式受到 Filechannel 对象的访问权限限制，如果在一个没有读权限的文件上启用 READ_ONLY，将抛出 NonReadableChannelException。

PRIVATE 模式表示写时拷贝的映射，意味着通过 put() 方法所做的任何修改都会导致产生一个私有的数据拷贝并且该拷贝中的数据只有 MappedByteBuffer 实例可以看到。

该过程不会对底层文件做任何修改，而且一旦缓冲区被施以垃圾收集动作（garbage collected），那些修改都会丢失。

大致浏览一下 map() 方法的源码：

    public MappedByteBuffer map(MapMode mode, long position, long size)

        throws IOException

    {

            ...省略...

            int pagePosition = (int)(position % allocationGranularity);

            long mapPosition = position - pagePosition;

            long mapSize = size + pagePosition;

            try {

                // If no exception was thrown from map0, the address is valid

                addr = map0(imode, mapPosition, mapSize);

            } catch (OutOfMemoryError x) {

                // An OutOfMemoryError may indicate that we've exhausted memory

                // so force gc and re-attempt map

                System.gc();

                try {

                    Thread.sleep(100);

                } catch (InterruptedException y) {

                    Thread.currentThread().interrupt();

                }

                try {

                    addr = map0(imode, mapPosition, mapSize);

                } catch (OutOfMemoryError y) {

                    // After a second OOME, fail

                    throw new IOException("Map failed", y);

                }

            }

            // On Windows, and potentially other platforms, we need an open

            // file descriptor for some mapping operations.

            FileDescriptor mfd;

            try {

                mfd = nd.duplicateForMapping(fd);

            } catch (IOException ioe) {

                unmap0(addr, mapSize);

                throw ioe;

            }

            assert (IOStatus.checkAll(addr));

            assert (addr % allocationGranularity == 0);

            int isize = (int)size;

            Unmapper um = new Unmapper(addr, mapSize, isize, mfd);

            if ((!writable) || (imode == MAP_RO)) {

                return Util.newMappedByteBufferR(isize,

                                                 addr + pagePosition,

                                                 mfd,

                                                 um);

            } else {

                return Util.newMappedByteBuffer(isize,

                                                addr + pagePosition,

                                                mfd,

                                                um);

            }

     }

大致意思就是通过 Native 方法获取内存映射的地址，如果失败，手动 GC 再次映射。

最后通过内存映射的地址实例化出 MappedByteBuffer，MappedByteBuffer 本身是一个抽象类，其实这里真正实例化出来的是 DirectByteBuffer。

DirectByteBuffer

DirectByteBuffer 继承于 MappedByteBuffer，从名字就可以猜测出开辟了一段直接的内存，并不会占用 JVM 的内存空间。

上一节中通过 Filechannel 映射出的 MappedByteBuffer 其实际也是 DirectByteBuffer，当然除了这种方式，也可以手动开辟一段空间：

ByteBuffer directByteBuffer = ByteBuffer.allocateDirect(100);

如上开辟了 100 字节的直接内存空间。

Channel-to-Channel 传输

经常需要从一个位置将文件传输到另外一个位置，FileChannel 提供了 transferTo() 方法用来提高传输的效率，首先看一个简单的实例：

public class ChannelTransfer {

    public static void main(String[] argv) throws Exception {

        String files[]=new String[1];

        files[0]="D://db.txt";

        catFiles(Channels.newChannel(System.out), files);

    }

    private static void catFiles(WritableByteChannel target, String[] files)

            throws Exception {

        for (int i = 0; i < files.length; i++) {

            FileInputStream fis = new FileInputStream(files[i]);

            FileChannel channel = fis.getChannel();

            channel.transferTo(0, channel.size(), target);

            channel.close();

            fis.close();

        }

    }

}

通过 FileChannel 的 transferTo() 方法将文件数据传输到 System.out 通道，接口定义如下：

    public abstract long transferTo(long position, long count,

                                    WritableByteChannel target)

        throws IOException;

几个参数也比较好理解，分别是开始传输的位置，传输的字节数，以及目标通道；transferTo() 允许将一个通道交叉连接到另一个通道，而不需要一个中间缓冲区来传递数据。

注：这里不需要中间缓冲区有两层意思：第一层不需要用户空间缓冲区来拷贝内核缓冲区，另外一层两个通道都有自己的内核缓冲区，两个内核缓冲区也可以做到无需拷贝数据。

Netty 零拷贝

Netty 提供了零拷贝的 Buffer，在传输数据时，最终处理的数据会需要对单个传输的报文，进行组合和拆分，NIO 原生的 ByteBuffer 无法做到，Netty 通过提供的 Composite（组合）和 Slice（拆分）两种 Buffer 来实现零拷贝。

看下面一张图会比较清晰：

TCP 层 HTTP 报文被分成了两个 ChannelBuffer，这两个 Buffer 对我们上层的逻辑（HTTP 处理）是没有意义的。

但是两个 ChannelBuffer 被组合起来，就成为了一个有意义的 HTTP 报文，这个报文对应的 ChannelBuffer，才是能称之为“Message”的东西，这里用到了一个词“Virtual Buffer”。

可以看一下 Netty 提供的 CompositeChannelBuffer 源码：

public class CompositeChannelBuffer extends AbstractChannelBuffer {

    private final ByteOrder order;

    private ChannelBuffer[] components;

    private int[] indices;

    private int lastAccessedComponentId;

    private final boolean gathering;

    public byte getByte(int index) {

        int componentId = componentId(index);

        return components[componentId].getByte(index - indices[componentId]);

    }

    ...省略...

Components 用来保存的就是所有接收到的 Buffer，Indices 记录每个 buffer 的起始位置，lastAccessedComponentId 记录上一次访问的 ComponentId。

CompositeChannelBuffer 并不会开辟新的内存并直接复制所有 ChannelBuffer 内容，而是直接保存了所有 ChannelBuffer 的引用，并在子 ChannelBuffer 里进行读写，实现了零拷贝。

其他零拷贝

RocketMQ 的消息采用顺序写到 commitlog 文件，然后利用 consume queue 文件作为索引。

RocketMQ 采用零拷贝 mmap+write 的方式来回应 Consumer 的请求。

同样 Kafka 中存在大量的网络数据持久化到磁盘和磁盘文件通过网络发送的过程，Kafka使用了 Sendfile 零拷贝方式。

总结

零拷贝如果简单用 Java 里面对象的概率来理解的话，其实就是使用的都是对象的引用，每个引用对象的地方对其改变就都能改变此对象，永远只存在一份对象。