IO的阻塞与非阻塞、同步与异步以及Java网络IO交互方式
2015-10-22 14:18
971 查看
摘自:/article/6990225.html
看着感觉有点意思,挺有道理,就粘过来了;
前提
首先先强调上下文:下面提到了同步与异步、阻塞与非阻塞的概念都是在IO的场合下。它们在其它场合下有着不同的含义,比如操作系统中,通信技术上。
然后借鉴下《Unix网络编程卷》中的理论:
IO操作中涉及的2个主要对象为程序进程、系统内核。以读操作为例,当一个IO读操作发生时,通常经历两个步骤:
1,等待数据准备
2,将数据从系统内核拷贝到操作进程中
例如,在socket上的读操作,步骤1会等到网络数据包到达,到达后会拷贝到系统内核的缓冲区;步骤2会将数据包从内核缓冲区拷贝到程序进程的缓冲区中。
阻塞(blocking)与非阻塞(non-blocking)IO
IO的阻塞、非阻塞主要表现在一个IO操作过程中,如果有些操作很慢,比如读操作时需要准备数据,那么当前IO进程是否等待操作完成,还是得知暂时不能操作后先去做别的事情?一直等待下去,什么事也不做直到完成,这就是阻塞。抽空做些别的事情,这是非阻塞。
非阻塞IO会在发出IO请求后立即得到回应,即使数据包没有准备好,也会返回一个错误标识,使得操作进程不会阻塞在那里。操作进程会通过多次请求的方式直到数据准备好,返回成功的标识。
想象一下下面两种场景:
A 小明和小刚两个人都很耿直内向,一天小明来找小刚借书:“小刚啊,你那本XXX借我看看”。 于是小刚就去找书,小明就等着,找了半天找到了,把书给了小明。
B 小明和小刚两个人都很活泼外向,一天小明来找小刚借书:“嘿小刚,你那本XXX借我看看”。 小刚说:“我得找一会”,小明就去打球去了。过会又来,这次书找到了,把书给了小明。
结论:A是阻塞的,B是非阻塞的。
从CPU角度可以看出非阻塞明显提高了CPU的利用率,进程不会一直在那等待。但是同样也带来了线程切换的增加。增加的 CPU 使用时间能不能补偿系统的切换成本需要好好评估。
同步(synchronous)与异步(asynchronous)IO
先来看看正式点的定义,POSIX标准将IO模型分为了两种:同步IO和异步IO,Richard
Stevens在《Unix网络编程卷》中也总结道:
A
synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes;
An asynchronous I/O operation does not cause the requesting process to be blocked;
可以看出,判断同步和异步的标准在于:一个IO操作直到完成,是否导致程序进程的阻塞。如果阻塞就是同步的,没有阻塞就是异步的。这里的IO操作指的是真实的IO操作,也就是数据从内核拷贝到系统进程(读)的过程。
继续前面借书的例子,异步借书是这样的:
C 小明很懒,一天小明来找小刚借书:“嘿小刚,你那本XXX借我看看”。 小刚说:“我得找一会”,小明就出去打球了并且让小刚如果找到了就把书拿给他。小刚是个负责任的人,找到了书送到了小明手上。
A和B的借书方式都是同步的,有人要问了B不是非阻塞嘛,怎么还是同步?
前面说了IO操作的2个步骤:准备数据和把数据从内核中拷贝到程序进程。映射到这个例子,书即是准备的数据,小刚是内核,小明是程序进程,小刚把书给小明这是拷贝数据。在B方式中,小刚找书这段时间小明的确是没闲着,该干嘛干嘛,但是小刚找到书把书给小明的这个过程也就是拷贝数据这个步骤,小明还是得乖乖的回来候着小刚把书递手上。所以这里就阻塞了,根据上面的定义,所以是同步。
在涉及到 IO 处理时通常都会遇到一个是同步还是异步的处理方式的选择问题。同步能够保证程序的可靠性,而异步可以提升程序的性能。小明自己去取书不管等着不等着迟早拿到书,指望小刚找到了送来,万一小刚忘了或者有急事忙别的了,那书就没了。
讨论
说实话,网上关于同步与异步、阻塞与非阻塞的文章多之又多,大部分是拷贝的,也有些写的非常好的。参考了许多,也借鉴了许多,也经过自己的思考。
同步与异步、阻塞与非阻塞之间确实有很多相似的地方,很容易混淆。wiki更是把异步与非阻塞画上了等号,更多的人还是认为他们是不同的。原因可能有很多,每个人的知识背景不同,设定的上下文也不同。
我的看法是:在IO中,根据上面同步异步的概念,也可以看出来同步与异步往往是通过阻塞非阻塞的形式来表达的,并且是通过一种中间处理机制来达到异步的效果。同步与异步往往是IO操作请求者和回应者之间在IO实际操作阶段的协作方式,而阻塞非阻塞更确切的说是一种自身状态,当前进程或者线程的状态。
在发出IO读请求后,阻塞IO会一直等待有数据可读,当有数据可读时,会等待数据从内核拷贝至系统进程;而非阻塞IO都会立即返回。至于数据怎么处理是程序进程自己的事情,无关同步和异步。
两种方式的组合
组合的方式当然有四种,分别是:同步阻塞、同步非阻塞、异步阻塞、异步非阻塞。
Java网络IO实现和IO模型
不同的操作系统上有不同的IO模型,《Unix网络编程卷》将unix上的IO模型分为5类:blocking
I/O、nonblocking I/O、I/O multiplexing (select and poll)、signal driven I/O (SIGIO)以及asynchronous I/O (the POSIX aio_functions)。具体可参考《Unix网络编程卷1》6.2章节。
在windows上IO模型也是有5种:select
、WSAAsyncSelect、WSAEventSelect、Overlapped I/O 事件通知以及IOCP。具体可参考windows五种IO模型。
Java是平台无关的语言,在不同的平台上会调用底层操作系统的不同的IO实现,下面就来说一下Java提供的网络IO的工具和实现,为了扩大阻塞非阻塞的直观感受,我都使用了长连接。
阻塞IO
同步阻塞最常用的一种用法,使用也是最简单的,但是 I/O 性能一般很差,CPU 大部分在空闲状态。下面是一个简单的基于TCP的同步阻塞的Socket服务端例子:
使用SocketTest作为客户端工具进行测试,同时开启2个客户端连接Server端并发送消息,如下图:
再看下后台的打印
由于服务器端是单线程的,在第一个连接的客户端阻塞了线程后,第二个客户端必须等待第一个断开后才能连接。当输入“end”字符串断开客户端1,这时候看到后台继续打印:
所有的客户端连接在请求服务端时都会阻塞住,等待前面的完成。即使是使用短连接,数据在写入 OutputStream 或者从 InputStream 读取时都有可能会阻塞。这在大规模的访问量或者系统对性能有要求的时候是不能接受的。
阻塞IO + 每个请求创建线程/线程池
通常解决这个问题的方法是使用多线程技术,一个客户端一个处理线程,出现阻塞时只是一个线程阻塞而不会影响其它线程工作;为了减少系统线程的开销,采用线程池的办法来减少线程创建和回收的成本,模式如下图:
简单的实现例子如下,使用一个线程(Accptor)接收客户端请求,为每个客户端新建线程进行处理(Processor),线程池的我就不弄了:
使用2个客户端连接,这次没有阻塞,成功的收到了2个客户端的消息。
在单个线程处理中,我人为的使单个线程read后阻塞5秒,就像前面说的,出现阻塞也只是在单个线程中,没有影响到另一个客户端的处理。
这种阻塞IO的解决方案在大部分情况下是适用的,在出现NIO之前是最通常的解决方案,Tomcat里阻塞IO的实现就是这种方式。但是如果是大量的长连接请求呢?不可能创建几百万个线程保持连接。再退一步,就算线程数不是问题,如果这些线程都需要访问服务端的某些竞争资源,势必需要进行同步操作,这本身就是得不偿失的。
看着感觉有点意思,挺有道理,就粘过来了;
前提
首先先强调上下文:下面提到了同步与异步、阻塞与非阻塞的概念都是在IO的场合下。它们在其它场合下有着不同的含义,比如操作系统中,通信技术上。
然后借鉴下《Unix网络编程卷》中的理论:
IO操作中涉及的2个主要对象为程序进程、系统内核。以读操作为例,当一个IO读操作发生时,通常经历两个步骤:
1,等待数据准备
2,将数据从系统内核拷贝到操作进程中
例如,在socket上的读操作,步骤1会等到网络数据包到达,到达后会拷贝到系统内核的缓冲区;步骤2会将数据包从内核缓冲区拷贝到程序进程的缓冲区中。
阻塞(blocking)与非阻塞(non-blocking)IO
IO的阻塞、非阻塞主要表现在一个IO操作过程中,如果有些操作很慢,比如读操作时需要准备数据,那么当前IO进程是否等待操作完成,还是得知暂时不能操作后先去做别的事情?一直等待下去,什么事也不做直到完成,这就是阻塞。抽空做些别的事情,这是非阻塞。
非阻塞IO会在发出IO请求后立即得到回应,即使数据包没有准备好,也会返回一个错误标识,使得操作进程不会阻塞在那里。操作进程会通过多次请求的方式直到数据准备好,返回成功的标识。
想象一下下面两种场景:
A 小明和小刚两个人都很耿直内向,一天小明来找小刚借书:“小刚啊,你那本XXX借我看看”。 于是小刚就去找书,小明就等着,找了半天找到了,把书给了小明。
B 小明和小刚两个人都很活泼外向,一天小明来找小刚借书:“嘿小刚,你那本XXX借我看看”。 小刚说:“我得找一会”,小明就去打球去了。过会又来,这次书找到了,把书给了小明。
结论:A是阻塞的,B是非阻塞的。
从CPU角度可以看出非阻塞明显提高了CPU的利用率,进程不会一直在那等待。但是同样也带来了线程切换的增加。增加的 CPU 使用时间能不能补偿系统的切换成本需要好好评估。
同步(synchronous)与异步(asynchronous)IO
先来看看正式点的定义,POSIX标准将IO模型分为了两种:同步IO和异步IO,Richard
Stevens在《Unix网络编程卷》中也总结道:
A
synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes;
An asynchronous I/O operation does not cause the requesting process to be blocked;
可以看出,判断同步和异步的标准在于:一个IO操作直到完成,是否导致程序进程的阻塞。如果阻塞就是同步的,没有阻塞就是异步的。这里的IO操作指的是真实的IO操作,也就是数据从内核拷贝到系统进程(读)的过程。
继续前面借书的例子,异步借书是这样的:
C 小明很懒,一天小明来找小刚借书:“嘿小刚,你那本XXX借我看看”。 小刚说:“我得找一会”,小明就出去打球了并且让小刚如果找到了就把书拿给他。小刚是个负责任的人,找到了书送到了小明手上。
A和B的借书方式都是同步的,有人要问了B不是非阻塞嘛,怎么还是同步?
前面说了IO操作的2个步骤:准备数据和把数据从内核中拷贝到程序进程。映射到这个例子,书即是准备的数据,小刚是内核,小明是程序进程,小刚把书给小明这是拷贝数据。在B方式中,小刚找书这段时间小明的确是没闲着,该干嘛干嘛,但是小刚找到书把书给小明的这个过程也就是拷贝数据这个步骤,小明还是得乖乖的回来候着小刚把书递手上。所以这里就阻塞了,根据上面的定义,所以是同步。
在涉及到 IO 处理时通常都会遇到一个是同步还是异步的处理方式的选择问题。同步能够保证程序的可靠性,而异步可以提升程序的性能。小明自己去取书不管等着不等着迟早拿到书,指望小刚找到了送来,万一小刚忘了或者有急事忙别的了,那书就没了。
讨论
说实话,网上关于同步与异步、阻塞与非阻塞的文章多之又多,大部分是拷贝的,也有些写的非常好的。参考了许多,也借鉴了许多,也经过自己的思考。
同步与异步、阻塞与非阻塞之间确实有很多相似的地方,很容易混淆。wiki更是把异步与非阻塞画上了等号,更多的人还是认为他们是不同的。原因可能有很多,每个人的知识背景不同,设定的上下文也不同。
我的看法是:在IO中,根据上面同步异步的概念,也可以看出来同步与异步往往是通过阻塞非阻塞的形式来表达的,并且是通过一种中间处理机制来达到异步的效果。同步与异步往往是IO操作请求者和回应者之间在IO实际操作阶段的协作方式,而阻塞非阻塞更确切的说是一种自身状态,当前进程或者线程的状态。
在发出IO读请求后,阻塞IO会一直等待有数据可读,当有数据可读时,会等待数据从内核拷贝至系统进程;而非阻塞IO都会立即返回。至于数据怎么处理是程序进程自己的事情,无关同步和异步。
两种方式的组合
组合的方式当然有四种,分别是:同步阻塞、同步非阻塞、异步阻塞、异步非阻塞。
Java网络IO实现和IO模型
不同的操作系统上有不同的IO模型,《Unix网络编程卷》将unix上的IO模型分为5类:blocking
I/O、nonblocking I/O、I/O multiplexing (select and poll)、signal driven I/O (SIGIO)以及asynchronous I/O (the POSIX aio_functions)。具体可参考《Unix网络编程卷1》6.2章节。
在windows上IO模型也是有5种:select
、WSAAsyncSelect、WSAEventSelect、Overlapped I/O 事件通知以及IOCP。具体可参考windows五种IO模型。
Java是平台无关的语言,在不同的平台上会调用底层操作系统的不同的IO实现,下面就来说一下Java提供的网络IO的工具和实现,为了扩大阻塞非阻塞的直观感受,我都使用了长连接。
阻塞IO
同步阻塞最常用的一种用法,使用也是最简单的,但是 I/O 性能一般很差,CPU 大部分在空闲状态。下面是一个简单的基于TCP的同步阻塞的Socket服务端例子:
1 @Test 2 public void testJIoSocket() throws Exception 3 { 4 ServerSocket serverSocket = new ServerSocket(10002); 5 Socket socket = null; 6 try 7 { 8 while (true) 9 { 10 socket = serverSocket.accept(); 11 System.out.println("socket连接:" + socket.getRemoteSocketAddress().toString()); 12 BufferedReader in = new BufferedReader(new InputStreamReader(socket.getInputStream())); 13 while(true) 14 { 15 String readLine = in.readLine(); 16 System.out.println("收到消息" + readLine); 17 if("end".equals(readLine)) 18 { 19 break; 20 } 21 //客户端断开连接 22 socket.sendUrgentData(0xFF); 23 } 24 } 25 } 26 catch (SocketException se) 27 { 28 System.out.println("客户端断开连接"); 29 } 30 catch (IOException e) 31 { 32 e.printStackTrace(); 33 } 34 finally 35 { 36 System.out.println("socket关闭:" + socket.getRemoteSocketAddress().toString()); 37 socket.close(); 38 } 39 }
使用SocketTest作为客户端工具进行测试,同时开启2个客户端连接Server端并发送消息,如下图:
再看下后台的打印
socket连接:/127.0.0.1:54080 收到消息hello! 收到消息my name is client1
由于服务器端是单线程的,在第一个连接的客户端阻塞了线程后,第二个客户端必须等待第一个断开后才能连接。当输入“end”字符串断开客户端1,这时候看到后台继续打印:
socket连接:/127.0.0.1:54080 收到消息hello! 收到消息my name is client1
收到消息end
socket关闭:/127.0.0.1:54080
socket连接:/127.0.0.1:54091
收到消息hello!
收到消息my name is client2
所有的客户端连接在请求服务端时都会阻塞住,等待前面的完成。即使是使用短连接,数据在写入 OutputStream 或者从 InputStream 读取时都有可能会阻塞。这在大规模的访问量或者系统对性能有要求的时候是不能接受的。
阻塞IO + 每个请求创建线程/线程池
通常解决这个问题的方法是使用多线程技术,一个客户端一个处理线程,出现阻塞时只是一个线程阻塞而不会影响其它线程工作;为了减少系统线程的开销,采用线程池的办法来减少线程创建和回收的成本,模式如下图:
简单的实现例子如下,使用一个线程(Accptor)接收客户端请求,为每个客户端新建线程进行处理(Processor),线程池的我就不弄了:
public class MultithreadJIoSocketTest { @Test public void testMultithreadJIoSocket() throws Exception { ServerSocket serverSocket = new ServerSocket(10002); Thread thread = new Thread(new Accptor(serverSocket)); thread.start(); Scanner scanner = new Scanner(System.in); scanner.next(); } public class Accptor implements Runnable { private ServerSocket serverSocket; public Accptor(ServerSocket serverSocket) { this.serverSocket = serverSocket; } public void run() { while (true) { Socket socket = null; try { socket = serverSocket.accept(); if(socket != null) { System.out.println("收到了socket:" + socket.getRemoteSocketAddress().toString()); Thread thread = new Thread(new Processor(socket)); thread.start(); } } catch (IOException e) { e.printStackTrace(); } } } } public class Processor implements Runnable { private Socket socket; public Processor(Socket socket) { this.socket = socket; } @Override public void run() { try { BufferedReader in = new BufferedReader(new InputStreamReader(socket.getInputStream())); String readLine; while(true) { readLine = in.readLine(); System.out.println("收到消息" + readLine); if("end".equals(readLine)) { break; } //客户端断开连接 socket.sendUrgentData(0xFF); Thread.sleep(5000); } } catch (InterruptedException e) { e.printStackTrace(); } catch (SocketException se) { System.out.println("客户端断开连接"); } catch (IOException e) { e.printStackTrace(); } finally { try { socket.close(); } catch (IOException e) { e.printStackTrace(); } } } } }
使用2个客户端连接,这次没有阻塞,成功的收到了2个客户端的消息。
收到了socket:/127.0.0.1:55707 收到了socket:/127.0.0.1:55708 收到消息hello! 收到消息hello!
在单个线程处理中,我人为的使单个线程read后阻塞5秒,就像前面说的,出现阻塞也只是在单个线程中,没有影响到另一个客户端的处理。
这种阻塞IO的解决方案在大部分情况下是适用的,在出现NIO之前是最通常的解决方案,Tomcat里阻塞IO的实现就是这种方式。但是如果是大量的长连接请求呢?不可能创建几百万个线程保持连接。再退一步,就算线程数不是问题,如果这些线程都需要访问服务端的某些竞争资源,势必需要进行同步操作,这本身就是得不偿失的。
相关文章推荐
- Socket使用
- 【Linux/unix网络编程】之使用socket进行TCP编程
- tcp连接的3次握手
- Linux网络流量实时监控ifstat iftop命令详解(系列二)
- 遗传算法和bp神经网络结合(神经网络权值学习)
- Iterate HTTP request headers
- 虚拟机的网络
- Volley + https
- 操作系统与网络实现 之五
- NFS(网络文件系统)简单总结
- Mac OS X 更新到10.11后cocoapods安装出现的问题(- bad response Not Found 404 (http://ruby.taobao.org/latest_spe)
- http接口自动化测试框架实现
- Nginx调试日志[emerg]: invalid log level “debug_http” in /path/conf/nginx.conf:XX
- okHttp使用中报Could not find method java.nio.file.Files.newOutputStreamo警告问题
- 解决CentOS 7 开机网络设备不启动方法
- android中HttpClient的应用(POST方法)
- 转一篇关于http请求配置的文章
- 网络编程(1)--数据链路层访问
- TCP的拥塞控制
- CocoaAsyncSocket 网络通信使用之RHSocketKit框架(四)