堆外内存DirectByteBuffer
文件拷贝
假设用伪代码实现从一个文件中读出数据并将数据传到另一台服务器上。
或许我们的伪代码是这样的
File.read(file, buf, len);Socket.send(socket, buf, len);
现在的问题是,以上的场景涉及到了几次数据拷贝?
1、应用程序中调用read()
方法,这里会涉及到一次上下文切换(用户态->内核态),底层采用DMA(direct memory access)读取磁盘的文件,并把内容存储到内核地址空间的读取缓存区。
2、由于应用程序无法读取内核地址空间的数据,如果应用程序要操作这些数据,必须把这些内容从读取缓冲区拷贝到用户缓冲区。这个时候,read()
调用返回,且引发一次上下文切换(内核态->用户态),现在数据已经被拷贝到了用户地址空间缓冲区,这时,如果有需要,应用程序可以操作修改这些内容。
3、我们最终目的是把这个文件内容通过Socket传到另一个服务中,调用Socket的send()
方法,这里又涉及到一次上下文切换(用户态->内核态),同时,文件内容被进行第三次拷贝,被再次拷贝到内核地址空间缓冲区,但是这次的缓冲区与目标套接字相关联,与读取缓冲区没有半点关系。
4、send()
调用返回,引发第四次的上下文切换,同时进行第四次的数据拷贝,通过DMA把数据从目标套接字相关的缓存区传到协议引擎进行发送。
所谓的 "零拷贝技术 zero-copy"
如果在应用程序中,不需要操作内容,过程2和3就是多余的,如果可以直接把内核态读取缓存冲区数据直接拷贝到套接字相关的缓存区,是不是可以达到优化的目的?
这种实现,可以有以下几点改进:
- 上下文切换的次数从四次减少到了两次
- 数据拷贝次数从四次减少到了三次(其中DMA copy 2次,CPU copy 1次)
在 Linux 内核 2.4 及后期版本中,针对套接字缓冲区描述符做了相应调整,DMA自带了收集功能,对于用户方面,用法还是一样的,但是内部操作已经发生了改变:
- 第一步,transferTo() 方法引发 DMA 将文件内容拷贝到内核读取缓冲区。
- 第二步,把包含数据位置和长度信息的描述符追加到套接字缓冲区,避免了内容整体的拷贝,DMA 引擎直接把数据从内核缓冲区传到协议引擎,从而消除了最后一次 CPU参与的拷贝动作。
在Java中,正好FileChannel的transferTo() 方法可以实现这个过程,该方法将数据从文件通道传输到给定的可写字节通道, 上面的file.read()
和 socket.send()
调用动作可以替换为 transferTo()
调用
public void transferTo(long position, long count, WritableByteChannel target);
DirectByteBuffer
实际上 transferTo能够实现减少拷贝的真正法宝就是 DirectByteBuffer(堆外内存),原理就是上面所说的
使用方面可以参考 https://blog.csdn.net/mc90716/article/details/80041757
使用DirectByteBuffer有些需要注意的地方:
- 如果我们的应用中使用了java nio中的direct memory,那么使用-XX:+DisableExplicitGC一定要小心,存在潜在的内存泄露风险(堆外内存会显示调用System.gc()释放内存。)。
- 需要注意的是DirectBuffer的创建是比较耗时的,所以在一些高性能的中间件或者应用下一般会做一个对象池,用于重复利用DirectBuffer。使用堆外内存时确保知道自己正在干什么,为什么要使用堆外内存。
参考
https://www.jianshu.com/p/2581342317ce
https://blog.csdn.net/aitangyong/article/details/39403031
以上是 堆外内存DirectByteBuffer 的全部内容, 来源链接: utcz.com/z/512875.html