Netty基础系列(5) --零拷贝底层分析
2019-08-26 06:04:37来源:博客园 阅读 ()
Netty基础系列(5) --零拷贝底层分析
前言
上一节(堆外内存与零拷贝)当中我们从jvm堆内存的视角解释了一波零拷贝原理,但是仅仅这样还是不够的。
为了彻底搞懂零拷贝,我们趁热打铁,接着上一节来继续讲解零拷贝的底层原理。
感受一下NIO的速度
之前的章节中我们说过,Nio并不能解决网络传输的速度。但是为什么很多人却说Nio的速度比传统IO快呢?
没错,zero copy。我们先抛出一个案例,然后根据案例来讲解底层原理。
首先,我们实现一个IO的服务端接受数据,然后分别用传统IO传输方式和NIO传输方式来直观对比传输相同大小的文件所耗费的时间。
服务端代码如下:
public class OldIOServer {
public static void main(String[] args) throws Exception {
ServerSocket serverSocket = new ServerSocket(8899);
while (true) {
Socket socket = serverSocket.accept();
DataInputStream dataInputStream = new DataInputStream(socket.getInputStream());
try {
byte[] byteArray = new byte[4096];
while (true) {
int readCount = dataInputStream.read(byteArray, 0, byteArray.length);
if (-1 == readCount) {
break;
}
}
} catch (Exception ex) {
ex.printStackTrace();
}
}
}
}
这个是最普通的socket编程的服务端,没什么好多说的。就是绑定本地的8899端口,死循环不断接受数据。
传统IO传输
public class OldIOClient {
public static void main(String[] args) throws Exception {
Socket socket = new Socket("localhost", 8899);
String fileName = "C:\\Users\\Administrator\\Desktop\\test.zip"; //大小两百M的文件
InputStream inputStream = new FileInputStream(fileName);
DataOutputStream dataOutputStream = new DataOutputStream(socket.getOutputStream());
byte[] buffer = new byte[4096];
long readCount;
long total = 0;
long startTime = System.currentTimeMillis();
while ((readCount = inputStream.read(buffer)) >= 0) {
total += readCount;
dataOutputStream.write(buffer);
}
System.out.println("发送总字节数: " + total + ", 耗时: " + (System.currentTimeMillis() - startTime));
dataOutputStream.close();
socket.close();
inputStream.close();
}
}
客户端向服务端发送一个119M大小的文件。计算一下耗时用了多久
由于我的笔记本性能太渣,大概平均每次消耗的时间大概是 500ms左右。值得注意的是,我们客户端和服务端分配的缓存大小都是4096个字节。如果将这个字节分配的更小一点,那么所耗时间将会更多。因为上述传统的IO实际表现并不是我们想象的那样直接将文件读到内存,然后发送。
实际情况是什么样的呢?我们在后续分析。
NIO传输
public class NewIOClient {
public static void main(String[] args) throws Exception {
SocketChannel socketChannel = SocketChannel.open();
socketChannel.connect(new InetSocketAddress("localhost", 8899));
socketChannel.configureBlocking(true);
String fileName = "C:\\Users\\Administrator\\Desktop\\test.zip"; //大小200M的文件
FileChannel fileChannel = new FileInputStream(fileName).getChannel();
long startTime = System.currentTimeMillis();
long transferCount = fileChannel.transferTo(0, fileChannel.size(), socketChannel); //1
System.out.println("发送总字节数:" + transferCount + ",耗时: " + (System.currentTimeMillis() - startTime));
fileChannel.close();
}
}
NIO编程不熟的同学没关系,后面会有一篇专门的章节来讲。
这里我们来关注一下注释1关于FileChannel的transferTo方法。(方法的doc文档很长。我删除了很多,只看重点)
/**
* Transfers bytes from this channel's file to the given writable byte
* channel.
*
* <p> This method is potentially much more efficient than a simple loop
* that reads from this channel and writes to the target channel. Many
* operating systems can transfer bytes directly from the filesystem cache
* to the target channel without actually copying them. </p>
*/
public abstract long transferTo(long position, long count,
WritableByteChannel target)
throws IOException;
翻译一下:
将文件channel的数据写到指定的channel
这个方法可能比简单的将数据从一个channel循环读到另一个channel更有效,
许多操作系统可以直接从文件系统缓存传输字节到目标通道,**而不实际复制它们**。
意思是我们调用FileChannel的transferTo方法就实现了零拷贝(想实现零拷贝并不止这一种方法,有更优雅的方法,这里只是作为一个演示)。当然也要看你操作系统支不支持底层zero copy。因为这部分工作其实是操作系统来完成的。
我的电脑平均执行下来大概在200ms左右。比传统IO快了300ms。
底层原理
大家也可以用自己的电脑运行一下上述代码,看看NIO传输一个文件比IO传输一个文件快多少。
在上诉代码中,楼主这里指定的缓存只有4096个字节,而传送的文件大小有125581592个字节。
在前面我们分析过,对于传统的IO而言,读取的缓存满了以后会有两次零拷贝过程。那么换算下来传输这个文件大概在内存中进行了6w多次无意义的内存拷贝,这6w多次拷贝在我的笔记本上大概所耗费的时间就是300ms左右。这就是导致NIO比传统IO快的更本原因。
传统IO底层时序图
由上图我们可以看到。当我们想将磁盘中的数据通过网络发送的时候,
- 底层调用的了sendfile()方法,然后切换用户态(User space)->内核态(Kemel space)。
- 从本地磁盘获取数据。获取的数据存储在内核态的内存空间内。
- 将数据复制到用户态内存空间里。
- 切换内核态->用户态。
- 用户操作数据,这里就是我们编写的java代码的具体操作。
- 调用操作系统的write()方法,将数据复制到内核态的socket buffer中。
- 切换用户态->内核态。
- 发送数据。
- 发送完毕以后,切换内核态->用户态。继续执行我们编写的java代码。
由上图可以看出。传统的IO发送一次数据,进行了两次“无意义”的内存拷贝。虽然内存拷贝对于整个IO来说耗时是可以忽略不计的。但是操作达到一定次数以后,就像我们上面案例的代码。就会由量变引起质变。导致速率大大降低。
linux2.4版本前的NIO时序图
- 底层调用的了sendfile()方法,然后切换用户态(User space)->内核态(Kemel space)。
- 从本地磁盘获取数据。获取的数据存储在内核态的内存空间内。
- 将内核缓存中的数据拷贝到socket缓冲中。
- 将socket缓存的数据发送。
- 发送完毕以后,切换内核态->用户态。继续执行我们编写的java代码。
可以看出,即便我们使用了NIO,其实在我们的缓存中依旧会有一次内存拷贝。拷贝到socket buffer(也就是发送缓存区)中。
到这里我们可以看到,用户态已经不需要再缓存数据了。也就是少了用户态和系统态之间的数据拷贝过程。也少了两次用户态与内核态上下文切换的过程。但是还是不够完美。因为在底层还是执行了一次拷贝。
要想实现真真意义上的零拷贝,还是需要操作系统的支持,操作系统支持那就支持。不支持你代码写出花了也不会支持。所以在linux2.4版本以后,零拷贝进化为以下模式。
linux2.4版本后的NIO时序图
这里的步骤与上面的步骤是类似的。看图可以看出,到这里内存中才真正意义上实现了零拷贝。
很多人就会发问了。为什么少了一次内核缓存的数据拷贝到socket缓存的操作?
不急,听我慢慢道来~
我们再来看另一张NIO的流程图:
上面这个图稍稍有点复杂,都看到这里了,别半途而废。多看几遍是能看懂的!
首先第一条黑线我们可以看出,在NIO只切换了两次用户态与内核态之间的上下文切换。
我们重点看这张图下面的部分。
首先我们将硬盘(hard drive)上的数据复制到内核态缓存中(kemel buffer)。然后发生了一次拷贝(CPU copy)到socket缓存中(socket buffer)。最后再通过协议引擎将数据发送出去。
在linux2.4版本前的的确是这样。但是!!!!
在linux2.4版本以后,上图中的从内核态缓存中(kemel buffer)的拷贝到socket缓存中(socket buffer)的就不再是数据了。而是对内核态缓存中数据的描述符(也就是指针)。协议引擎发送数据的时候其实是通过socket缓存中的描述符。找到了内核态缓存中的数据。再将数据发送出去。这样就实现了真正的零拷贝。
总结
我们花了两篇文章,一篇从jvm堆内存的角度出发(堆外内存与零拷贝),以及本篇从操作体统底层出发来讲解零拷贝。足以说明零拷贝的重要性,各位可千万得重视哟,就算你觉得不重要,面试也是会经常被问到,如果你能把上面的流程讲明白,我相信一定也是一大亮点~
原文链接:https://www.cnblogs.com/zhxiansheng/p/11372413.html
如有疑问请与原作者联系
标签:
版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有
上一篇:Java JDBC 数据源
下一篇:Java HashMap解析
- Spring系列.ApplicationContext接口 2020-06-11
- 04.Java基础语法 2020-06-11
- 1-Java基础回顾整理_01 2020-06-10
- Java基础语法菜鸟教程笔记 2020-06-10
- logstash系列-入门整理 2020-06-10
IDC资讯: 主机资讯 注册资讯 托管资讯 vps资讯 网站建设
网站运营: 建站经验 策划盈利 搜索优化 网站推广 免费资源
网络编程: Asp.Net编程 Asp编程 Php编程 Xml编程 Access Mssql Mysql 其它
服务器技术: Web服务器 Ftp服务器 Mail服务器 Dns服务器 安全防护
软件技巧: 其它软件 Word Excel Powerpoint Ghost Vista QQ空间 QQ FlashGet 迅雷
网页制作: FrontPages Dreamweaver Javascript css photoshop fireworks Flash