JAVA NIO 和 AIO 的区别

Python036

JAVA NIO 和 AIO 的区别,第1张

Java NIO : 同步非阻塞,服务器实现模式为一个请求一个线程,即客户端发送的连接请求都会注册到多路复用器上,多路复用器轮询到连接有I/O请求时才启动一个线程进行处理。

Java AIO(NIO.2) : 异步非阻塞,服务器实现模式为一个有效请求一个线程,客户端的I/O请求都是由OS先完成了再通知服务器应用去启动线程进行处理,

NIO方式适用于连接数目多且连接比较短(轻操作)的架构,比如聊天服务器,并发局限于应用中,编程比较复杂,JDK1.4开始支持。

AIO方式使用于连接数目多且连接比较长(重操作)的架构,比如相册服务器,充分调用OS参与并发操作,编程比较复杂,JDK7开始支持

I/O属于底层操作,需要操作系统支持,并发也需要操作系统的支持,所以性能方面不同操作系统差异会比较明显。另外NIO的非阻塞,需要一直轮询,也是一个比较耗资源的。所以出现AIO

BIO是一个连接一个线程。

NIO是一个请求一个线程。

AIO是一个有效请求一个线程。

先来个例子理解一下概念,以银行取款为例:

同步 : 自己亲自出马持银行卡到银行取钱(使用同步IO时,Java自己处理IO读写);

异步 : 委托一小弟拿银行卡到银行取钱,然后给你(使用异步IO时,Java将IO读写委托给OS处理,需要将数据缓冲区地址和大小传给OS(银行卡和密码),OS需要支持异步IO操作API);

阻塞 : ATM排队取款,你只能等待(使用阻塞IO时,Java调用会一直阻塞到读写完成才返回);

非阻塞 : 柜台取款,取个号,然后坐在椅子上做其它事,等号广播会通知你办理,没到号你就不能去,你可以不断问大堂经理排到了没有,大堂经理如果说还没到你就不能去(使用非阻塞IO时,如果不能读写Java调用会马上返回,当IO事件分发器会通知可读写时再继续进行读写,不断循环直到读写完成)

Java对BIO、NIO、AIO的支持:

Java BIO : 同步并阻塞,服务器实现模式为一个连接一个线程,即客户端有连接请求时服务器端就需要启动一个线程进行处理,如果这个连接不做任何事情会造成不必要的线程开销,当然可以通过线程池机制改善。

Java NIO : 同步非阻塞,服务器实现模式为一个请求一个线程,即客户端发送的连接请求都会注册到多路复用器上,多路复用器轮询到连接有I/O请求时才启动一个线程进行处理。

Java AIO(NIO.2) : 异步非阻塞,服务器实现模式为一个有效请求一个线程,客户端的I/O请求都是由OS先完成了再通知服务器应用去启动线程进行处理,

基本原理 要实现网络机器间的通讯,首先得来看看计算机系统网络通信的基本原理,在底层层面去看,网络通信需要做的就是将流从一台计算机传输到另外一台计算机,基于传输协议和网络 IO 来实现,其中传输协议比较出名的有 http、tcp、 udp 等等,http、tcp、udp 都是在基于Socket 概念上为某类应用场景而扩展出的传输协议,网络IO,主要有bio、nio、aio 三种方式,所有的分布式应用通讯都基于这个原理而实现,只是为了应用的易用,各种语言通常都会提供一些更为贴近应用易用的应用层协议。 应用级协议 远程服务通讯,需要达到的目标是在一台计算机发起请求,另外一台机器在接收到请求后进行相应的处理并将结果返回给请求端,这其中又会有诸如 onewayrequest、同步请求、异步请求等等请求方式,按照网络通信原理,需要实现这个需要做的就是将请求转换成流,通过传输协议传输至远端,远端计算机在接收到请求的流后进行处理,处理完毕后将结果转化为流,并通过传输协议返回给调用端。原理是这样的,但为了应用的方便,业界推出了很多基于此原理之上的应用级的协议,使得大家可以不用去直接操作这么底层的东西,通常应用级的远程通信协议会提供: 1.为了避免直接做流操作这么麻烦,提供一种更加易用或贴合语言的标准传输格式2.网络通信机制的实现,就是替你完成了将传输格式转化为流,通过某种传输协议传输至远端计算机,远端计算机在接收到流后转化为传输格式,并进行存储或以某种方式通知远端计算机。 所以在学习应用级的远程通信协议时,我们可以带着这几个问题进行学习: 1.传输的标准格式是什么?2.怎么样将请求转化为传输的流?3.怎么接收和处理流?4.传输协议是? 不过应用级的远程通信协议并不会在传输协议上做什么多大的改进,主要是在流操作方面,让应用层生成流和处理流的这个过程更加的贴合所使用的语言或标准,至于传输协议则通常都是可选的,在java 领域中知名的有:RMI、 XML-RPC、Binary-RPC、SOAP、CORBA、JMS,来具体的看看这些远程通信的应用级协议: RMIRMI 是个典型的为java 定制的远程通信协议,我们都知道,在 singlevm 中,我们可以通过直接调用javaobjectinstance 来实现通信,那么在远程通信时,如果也能按照这种方式当然是最好了,这种远程通信的机制成为RPC(RemoteProcedureCall),RMI 正是朝着这个目标而诞生的。 来看下基于RMI 的一次完整的远程通信过程的原理: 1.客户端发起请求,请求转交至RMI 客户端的stub 类2.stub 类将请求的接口、方法、参数等信息进行序列化3.基于socket 将序列化后的流传输至服务器端4.服务器端接收到流后转发至相应的skelton 类5.skelton 类将请求的信息反序列化后调用实际的处理类6.处理类处理完毕后将结果返回给 skelton 类7.Skelton 类将结果序列化,通过socket 将流传送给客户端的 stub8.stub 在接收到流后反序列化,将反序列化后的JavaObject 返回给调用者。 根据原理来回答下之前学习应用级协议带着的几个问题: 1.传输的标准格式是什么?是JavaObjectStream。2.怎么样将请求转化为传输的流?基于Java 串行化机制将请求的javaobject 信息转化为流。3.怎么接收和处理流?根据采用的协议启动相应的监听端口,当有流进入后基于Java 串行化机制将流进行反序列化,并根据RMI 协议获取到相应的处理对象信息,进行调用并处理,处理完毕后的结果同样基于java 串行化机制进行返回。4.传输协议是?Socket。 XML-RPCXML-RPC 也是一种和RMI 类似的远程调用的协议,它和RMI 的不同之处在于它以标准的 xml 格式来定义请求的信息(请求的对象、方法、参数等),这样的好处是什么呢,就是在跨语言通讯的时候也可以使用。 来看下XML-RPC 协议的一次远程通信过程: 1.客户端发起请求,按照XML-RPC 协议将请求信息进行填充2.填充完毕后将xml 转化为流,通过传输协议进行传输3.接收到在接收到流后转换为xml,按照XML-RPC 协议获取请求的信息并进行处理4.处理完毕后将结果按照XML- RPC 协议写入xml 中并返回。 同样来回答问题: 1.传输的标准格式是?标准格式的XML。2.怎么样将请求转化为传输的流? 将XML 转化为流。3.怎么接收和处理流?通过监听的端口获取到请求的流,转化为XML,并根据协议获取请求的信息,进行处理并将结果写入XML 中返回。4. 传输协议是?Http。 Binary-RPCBinary-RPC 看名字就知道和XML-RPC 是差不多的了,不同之处仅在于传输的标准格式由XML 转为了二进制的格式。 同样来回答问题: 1.传输的标准格式是?标准格式的二进制文件。2.怎么样将请求转化为传输的流?将二进制格式文件转化为流。3.怎么接收和处理流?通过监听的端口获取到请求的流,转化为二进制文件,根据协议获取请求的信息,进行处理并将结果写入XML 中返回。4.传输协议是?Http。 SOAPSOAP 原意为SimpleObjectAccessProtocol,是一个用于分布式环境的、轻量级的、基于XML 进行信息交换的通信协议,可以认为SOAP 是XMLRPC 的高级版,两者的原理完全相同,都是http+XML,不同的仅在于两者定义的XML 规范不同,SOAP 也是Webservice 采用的服务调用协议标准,因此在此就不多加阐述了。 CORBACommonObjectRequestBrokerArchitecture(公用对象请求代理[调度]程序体系结构),是一组用来定义"分布式对象系统"的标准,由 OMG(ObjectMenagementGroup)作为发起和标准制定单位。CORBA 的目的是定义一套协议,符合这个协议的对象可以互相交互,不论它们是用什么样的语言写的,不论它们运行于什么样的机器和操作系统。CORBA 在我看来是个类似于SOA 的体系架构,涵盖可选的远程通信协议,但其本身不能列入通信协议这里来讲,而且CORBA 基本淘汰,再加上对CORBA 也不怎么懂,在此就不进行阐述了。 JMSJMS 呢,是实现java 领域远程通信的一种手段和方法,基于JMS 实现远程通信时和RPC 是不同的,虽然可以做到RPC 的效果,但因为不是从协议级别定义的,因此我们不认为JMS 是个RPC 协议,但它确实是个远程通信协议,在其他的语言体系中也存在着类似JMS 的东西,可以统一的将这类机制称为消息机制,而消息机制呢,通常是高并发、分布式领域推荐的一种通信机制,这里的主要一个问题是容错(详细见ErLang 论文)。 来看JMS 中的一次远程通信的过程: 1.客户端将请求转化为符合JMS 规定的Message2.通过JMSAPI 将Message 放入JMSQueue 或Topic 中3.如为JMSQueue,则发送中相应的目标Queue 中,如为Topic,则发送给订阅了此Topic 的JMSQueue。4.处理端则通过轮训 JMSQueue,来获取消息,接收到消息后根据JMS 协议来解析Message 并处理。 回答问题: 1.传输的标准格式是?JMS 规定的Message。2.怎么样将请求转化为传输的流?将参数信息放入Message 中即可。3.怎么接收和处理流?轮训JMSQueue 来接收Message,接收到后进行处理,处理完毕后仍然是以Message 的方式放入 Queue 中发送或Multicast。4.传输协议是?不限。 基于JMS 也是常用的实现远程异步调用的方法之一。