Netty中的零拷贝与我们传统理解的零拷贝不太一样。
传统的零拷贝指的是数据传输过程中,不需要CPU进行数据的拷贝。主要是数据在用户空间与内核中间之间的拷贝。
传统意义的零拷贝
Zero-Copy describes computer operations in which the CPU does not perform the task of copying data from one memory area to another.
在发送数据的时候,传统的实现方式是:
File.read(bytes)
Socket.send(bytes)
这种方式需要四次数据拷贝和四次上下文切换:
明显上面的第二步和第三步是没有必要的,通过java的FileChannel.transferTo方法,可以避免上面两次多余的拷贝(当然这需要底层操作系统支持)。
上面的两次操作都不需要CPU参与,所以就达到了零拷贝。
Netty中也用到了FileChannel.transferTo方法,所以Netty的零拷贝也包括上面将的操作系统级别的零拷贝,除此之外,在ByteBuf的实现上,Netty也提供了零拷贝的一些实现。
关于ByteBuffer,Netty提供了两个接口:
对于ByteBuf,Netty提供了多种实现:
直接在内存区域分配空间,而不是在堆内存中分配。
如果在JVM 内部执行 I/O 操作时,必须将数据拷贝到堆外内存,才能执行系统调用。
VM语言都会存在的问题,那么为什么操作系统不能直接使用JVM堆内存进行 I/O 的读写呢?
传统的ByteBuffer,如果需要将两个ByteBuffer中的数据组合到一起,我们需要首先创建一个size=size1+size2大小的新的数组,然后将两个数组中的数据拷贝到新的数组中。但是使用Netty提供的组合ByteBuf,就可以避免这样的操作,因为CompositeByteBuf并没有真正将多个Buffer组合起来,而是保存了它们的引用,从而避免了数据的拷贝,实现了零拷贝。
Netty中使用了FileChannel的transferTo方法,该方法依赖于操作系统实现零拷贝。
Netty的零拷贝体现在三个方面:
Netty的接收和发送ByteBuffer采用DIRECT BUFFERS,使用堆外直接内存进行Socket读写,不需要进行字节缓冲区的二次拷贝。
如果使用传统的堆内存(HEAP BUFFERS)进行Socket读写,JVM会将堆内存Buffer拷贝一份到直接内存中,然后才写入Socket中。相比于堆外直接内存,消息在发送过程中多了一次缓冲区的内存拷贝。
Netty提供了组合Buffer对象,可以聚合多个ByteBuffer对象,用户可以像操作一个Buffer那样方便的对组合Buffer进行操作,避免了传统通过内存拷贝的方式将几个小Buffer合并成一个大的Buffer。
Netty的文件传输采用了transferTo方法,它可以直接将文件缓冲区的数据发送到目标Channel,避免了传统通过循环write方式导致的内存拷贝问题。
堆外内存的回收其实依赖于我们的GC机制
System.gc()会对新生代的老生代都会进行内存回收,这样会比较彻底地回收,DirectByteBuffer对象以及他们关联的堆外内存.
DirectByteBuffer对象本身其实是很小的,但是它后面可能关联了一个非常大的堆外内存,因此我们通常称之为冰山对象。
做ygc的时候会将新生代里的不可达的DirectByteBuffer对象及其堆外内存回收了,但是无法对old里的DirectByteBuffer对象及其堆外内存进行回收,这也是我们通常碰到的最大的问题.
如果有大量的DirectByteBuffer对象移到了old,但是又一直没有做cms gc或者full gc,而只进行ygc,那么我们的物理内存可能被慢慢耗光,但是我们还不知道发生了什么,因为heap明明剩余的内存还很多。
https://www.jianshu.com/p/61a7916b37fd
极限就是为了超越而存在的
版权说明 : 本文为转载文章, 版权归原作者所有 版权申明
原文链接 : https://www.cnblogs.com/liboware/p/15726921.html
内容来源于网络,如有侵权,请联系作者删除!