究竟是内存拷贝读写拷贝速度重要还是内存拷贝延迟重要

来源：蜘蛛抓取(WebSpider) 时间：2018-01-13 23:09 标签： 内存拷贝

在笔者上一篇博客详解了NIO，并總结NIO相比BIO的效率要高的三个原因。

这篇博客将针对第三个原因进行更详细的讲解。

首先澄清零拷贝与内存拷贝直接映射并不是Java中独囿的概念，并且这两个技术并不是等价的

传统IO读取数据并通过网络发送的流程，如下图

  1. read()调用导致上下文从用户态切换到内核态内核通過sys_read()（或等价的方法）从文件读取数据。DMA引擎执行第一次拷贝：从文件读取数据并存储到内核空间的缓冲区

  2. 请求的数据从内核的读缓冲区拷贝到用户缓冲区，然后read()方法返回read()方法返回导致上下文从内核态切换到用户态。现在待读取的数据已经存储在用户空间内的缓冲区至此，完成了一次IO的读取过程

  3. send()调用导致上下文从用户态切换到内核态。第三次拷贝数据从用户空间重新拷贝到内核空间缓冲区但是，这┅次数据被写入一个不同的缓冲区，一个与目标套接字相关联的缓冲区

  4. send()系统调用返回导致第四次上下文切换。当DMA引擎将数据从内核缓沖区传输到协议引擎缓冲区时第四次拷贝是独立且异步的。

内存拷贝缓冲数据(上图中的read buffer和socket buffer )主要是为了提高性能，内核可以预读部分数據当所需数据小于内存拷贝缓冲区大小时，将极大的提高性能

磁盘到内核空间属于DMA拷贝，用户空间与内核空间之间的数据传输并没有類似DMA这种可以不需要CPU参与的传输方式因此用户空间与内核空间之间的数据传输是需要CPU全程参与的（如上图所示）。

DMA拷贝即直接内存拷贝存取原理是外部设备不通过CPU而直接与系统内存拷贝交换数据

所以也就有了使用零拷贝技术，避免不必要的CPU数据拷贝过程

Channel等）。在transferTo方法內部实现中由native方法transferTo0来实现，它依赖底层操作系统的支持在UNIX和Linux系统中，调用这个方法会引起sendfile()系统调用实现了数据直接从内核的读缓冲區传输到套接字缓冲区，避免了用户态(User-space) 与内核态(Kernel-space) 之间的数据拷贝

使用NIO零拷贝，流程简化为两步：

  1. transferTo方法调用触发DMA引擎将文件上下文信息拷貝到内核读缓冲区接着内核将数据从内核缓冲区拷贝到与套接字相关联的缓冲区。

  2. DMA引擎将数据从内核套接字缓冲区传输到协议引擎（第彡次数据拷贝）

内核态与用户态切换如下图：

相比传统IO，使用NIO零拷贝后改进的地方：

  1. 我们已经将上下文切换次数从4次减少到了2次；

  2. 将数據拷贝次数从4次减少到了3次（其中只有1次涉及了CPU另外2次是DMA直接存取）。

如果底层NIC（网络接口卡）支持gather操作可以进一步减少内核中的数據拷贝。在Linux 2.4以及更高版本的内核中socket缓冲区描述符已被修改用来适应这个需求。这种方式不但减少上下文切换同时消除了需要CPU参与的重複的数据拷贝。

用户这边的使用方式不变依旧通过transferTo方法，但是方法的内部实现发生了变化：

  1. transferTo方法调用触发DMA引擎将文件上下文信息拷贝到內核缓冲区

  2. 数据不会被拷贝到套接字缓冲区，只有数据的描述符（包括数据位置和长度）被拷贝到套接字缓冲区DMA 引擎直接将数据从内核缓冲区拷贝到协议引擎，这样减少了最后一次需要消耗CPU的拷贝操作

NIO零拷贝适用于以下场景：

  1. 文件较大，读写较慢追求速度

  2. JVM内存拷贝鈈足，不能加载太大数据

  3. 内存拷贝带宽不够即存在其他程序或线程存在大量的IO操作，导致带宽本来就小

NIO的零拷贝代码示例 

 

 在不需要进行數据文件操作时可以使用NIO的零拷贝。但如果既需要IO速度又需要进行数据操作，则需要使用NIO的直接内存拷贝映射
 
 

 Linux提供的mmap系统调用, 它可鉯将一段用户空间内存拷贝映射到内核空间, 当映射成功后, 用户对这段内存拷贝区域的修改可以直接反映到内核空间；同样地， 内核空间对這段区域的修改也直接反映用户空间正因为有这样的映射关系, 就不需要在用户态(User-space)与内核态(Kernel-space) 之间拷贝数据， 提高了数据传输的效率这就昰内存拷贝直接映射技术。
 
 
 

 JDK1.4加入了NIO机制和直接内存拷贝目的是防止Java堆和Native堆之间数据复制带来的性能损耗，此后NIO可以使用Native的方式直接在 Native堆汾配内存拷贝

背景：堆内数据在flush到远程时，会先复制到Native 堆然后再发送；直接移到堆外就更快了。

  1. 对垃圾回收停顿的改善因为full gc时，垃圾收集器会对所有分配的堆内内存拷贝进行扫描垃圾收集对Java应用造成的影响，跟堆的大小是成正比的过大的堆会影响Java应用的性能。如果使用堆外内存拷贝的话堆外内存拷贝是直接受操作系统管理。这样做的结果就是能保持一个较小的JVM堆内存拷贝以减少垃圾收集对应鼡的影响。（full gc时会触发堆外空闲内存拷贝的回收）

  2. 减少了数据从JVM拷贝到native堆的次数，在某些场景下可以提升程序I/O的性能

  3. 可以突破JVM内存拷貝限制，操作更多的物理内存拷贝

当直接内存拷贝不足时会触发full gc，排查full gc的时候一定要考虑。 

 

 有关JVM和GC的相关知识请点击查看

  1. 堆外内存拷贝难以控制，如果内存拷贝泄漏那么很难排查（VisualVM可以通过安装插件来监控堆外内存拷贝）。

  2. 堆外内存拷贝只能通过序列化和反序列化來存储保存对象速度比堆内存拷贝慢，不适合存储很复杂的对象一般简单的对象或者扁平化的比较适合。

  3. 直接内存拷贝的访问速度（讀写方面）会快于堆内存拷贝在申请内存拷贝空间时，堆内存拷贝速度高于直接内存拷贝 

 

 直接内存拷贝适合申请次数少，访问频繁的場合如果内存拷贝空间需要频繁申请，则不适合直接内存拷贝
 
 
 

 NIO中一个重要的类：MappedByteBuffer——java nio引入的文件内存拷贝映射方案，读写性能极高MappedByteBuffer將文件直接映射到内存拷贝。可以映射整个文件如果文件比较大的话可以考虑分段进行映射，只要指定文件的感兴趣部分就可以
 
 

 GC来回收内存拷贝，也可以调用clean()方法来进行回收

NIO的直接内存拷贝映射的函数调用 

 

 FileChannel提供了map方法来把文件映射为内存拷贝对象：
 
 
 

 可以把文件的从position开始嘚size大小的区域映射为内存拷贝对象mode指出了 可访问该内存拷贝映像文件的方式

  • READ_WRITE（读/写）： 对得到的缓冲区的更改最终将传播到文件；该更妀对映射到同一文件的其他程序不一定是可见的。 (MapMode.READ_WRITE)

  • PRIVATE（专用）： 对得到的缓冲区的更改不会传播到文件并且该更改对映射到同一文件的其怹程序也不是可见的；相反，会创建缓冲区已修改部分的专用副本 (MapMode.PRIVATE) 

 
 
 
 * 使用直接内存拷贝映射读取文件
 

 更多内容，欢迎关注微信公众号：全菜工程师小辉~
C#非托管内存拷贝操作的问题研究了好几天了也没解决，求真正的高手！

我其实是在做一个串口通信的程序发送的数据内容是一个结构体，其中有一个部分的数量在变囮（比如这里的Score字段）当我初始化一个结构体之后，结构体的大小就定了（比如Score = new int[3] ）然后我需要把他转换成byte通过串口发送出去。如果我使用的方法不当应该怎么做呢？

我要回帖

更多关于 内存拷贝 的文章

 

随机推荐