java-nio之zero copy深入分析

对于所有的io操作，底层一定是调用操作系统的api来进行读写。受限于不同的操作系统，操作方式一定是有差异的。以下read和write操作，可以看做服务器从磁盘硬件上读取文件数据，然后通过socket发送给客户端的流程。

传统io服务端对客户端的传输

对于读操作：jvm虚拟机一定会发送一个read（）操作系统级别的方法，由此会产生一个上下文的切换，从程序所在的用户空间切换至系统的内核空间，内核空间向磁盘空间请求数据，通过DMA直接内存访问的方式将数据读取到内核空间缓冲区，此时用户空间是无法直接使用的，所以下面会将这份缓冲数据原封不动的拷贝到用户空间，至此read操作就结束。期间有两次上下文的切换，和两次数据的拷贝

对于写操作：将文件读取之后需要发送给远端socket客户端。同样调用系统级别的write方法，需要将上述读到的用户空间的数据原封不动的拷贝到内核上的socket缓冲区，然后DMA 引擎将数据从该缓冲区传到协议引擎，这一次拷贝独立地、异步地发生 。

对于这种io的操作，用户空间只是作为一个中转站，会和内核空间有不必要的上下文切换和数据之间的拷贝

操作系统对于io的一种优化方式

对于优化方式，需要系统直接的支持，jvm是无法提供任何的帮助。对于传统的linux、unix等操作系统是支持的

对于读写操作：用户空间向操作系统发送sendfile()方法，后续的操作只会在内核空间完成。对于所有的读写操作将只会有两次的用户空间和内核空间切换，这种操作称为操作系统意义上的零拷贝。同样的后续会通过DMA的方式向磁盘空间读取数据，读到内核空间的缓冲区，然后将这部分数据写到socket缓冲区，然后通过socket缓冲区向客户端发送数据，完成之后向内核空间然后向用户空间发送数据。相比于第一种方式有了极大的改善。

io的进一步优化方式

相对于上一种方案，内核空间会将数据复制一份到socket缓冲区，因为对于DMA直接内存访问的机制，希望内存地址是连续的，当然buffer的地址是连续的，因此会多一步拷贝到socket缓冲区，如果操作系统支持buffer中的scatter/gather，那么我们就能够有效的避免这种问题。可以通过scatter/gather的方式来读取数据到内核空间然后直接进行后续的写操作，从而减少中间的一步拷贝。

最佳的方式

通过DMA的方式拷贝数据到内核缓冲区，将对应的文件描述符写到socket buffer中，包含了内核的缓冲区的地址和数据长度，并不需要将数据拷贝到socket buffer中，只用存文件描述符。最后协议引擎发送数据的时候，从kernel buffer和socket buffer里面读取数据，对于kernel buffer是真实数据的读取，而对于socket buffer是文件描述符的读取，通过gather操作最终一起发送给客户端

很多的web应用程序都支持零拷贝，比如apache和tomcat，Java中提供的nio的方式是通过transferTo来实现

对于我们上面所述的所有方式，用户是无法对文件进行一定的操作。我们可以通过内存映射在中间过程来对文件进行一定的操作：

参考：

http://xcorpion.tech/2016/09/10/It-s-all-about-buffers-zero-copy-mmap-and-Java-NIO/
https://www.ibm.com/developerworks/library/j-zerocopy/