BIO & NIO & NIO常见框架

BIO & NIO

BIO - Blocking IO - 同步式阻塞式IO --- UDP/TCP

NIO - New  IO - 同步式非阻塞式IO

AIO  - AsynchronousIO - 异步式非阻塞式IO - jdk1.8

BIO的缺点:

1.会产生阻塞行为 --- receive/accept/connect/read/write

2.一对一的连接:每连接一个客户端,在服务器端就需要开启一个线程去处理请求.在客户端较多的情况下,服务器端就会产生大量的线程 - 耗费内存

3.连接建立之后如果不发生任何的操作.那么就会导致服务器中的这个线程依然被占用,耗费服务器的资源

4.无法实现定点操作

NIO的三个基本组件:

Buffer-缓冲区, Channel-通道, Selector-多路复用选择器

Buffer-缓冲区

容器 - 存储数据 - 在底层存储数据的时候实际上是以数组形式来存储

capacity - 容量位 - 指定缓冲区的容量

limit - 限制位 - 限制操作位所能达到的尺度

position - 操作位 - 指定要操作的位置

mark - 标记位 - 标记位置,认为标记位置之前的数据是已经操作过的没有错误的数据

mark <= position <= limit <= capacity

flip - 反转缓冲区:先将限制位挪到操作位上, 然后将操作位归零, 清空标记位

clear - 清空缓冲区: 将操作位归零,将limit挪到capacity,将标记位清空

reset - 重置缓冲区: 将操作位挪到标记位

rewind - 重绕缓冲区: 将操作位归零,将标记位清空 --- 缓冲区多次读取

Channel-通道

传输数据 - 是面向缓冲区的。在java中,Channel默认也是阻塞的,需要手动将其设置为非阻塞模式。

BIO: File、UDP - DatagramSocket、TCP - Socket, ServerSocket

NIO: FileChannel、UDP - DatagramChannel、TCP - SocketChannel, ServerSocketChannel

FileChannel - 操作文件,可以利用通道实现相同平台之间的零拷贝技术。

Selector-多路复用选择器

进行选择 - 是面向通道进行操作。要求通道在使用的时候必须设置为非阻塞

客户端

可连接,可读、可写

服务端

可接受,可读,可写

通过Selector可以实现利用同一个服务器端来处理多个客户端的数据 --- 可以用少量线程处理大量的请求 --- 在底层处理的时候实际上依然是同步的

NIO的优势:

1.非阻塞:提高传输效率

2.一对多的连接:可以用一个或者少量的服务器中的线程来处理大量的请求,从而节省服务器的内存资源

3.即使已经建立连接,只要没有对应的读写事件,那么依然不能够使用服务器来进行处理

4.利用通道实现数据的双向传输

5.因为利用缓冲区来存储数据,所以可以对缓冲区中的数据实现定点操作

NIO常见框架比较

一.通信框架

流行基于Java NIO通信框架有Mina、Netty、Grizzly等。接下来说下它们之间的对比。 二.它们的出身

Mina出身于开源界的大牛Apache组织;

Netty出身于商业开源大亨Jboss;

Grizzly则出身于Sun公司。

三.它们的设计理念

1、Mina

Mina(Multipurpose Infrastructure for Network Applications) 是 Apache 组织一个较新的项目,它为开发高性能

和高可用性的网络应用程序提供了非常便利的框架。当前发行的 Mina 版本2.04支持基于 Java NIO 技术的

TCP/UDP 应用程序开发、串口通讯程序,Mina 所支持的功能也在进一步的扩展中。 目前,正在使用Mina的应用

包括:Apache Directory Project、AsyncWeb、AMQP(Advanced Message Queuing Protocol)、RED5

Server(Macromedia Flash Media RTMP)、ObjectRADIUS、 Openfire等等。

2、Netty

Netty是一款异步的事件驱动的网络应用框架和工具,用于快速开发可维护的高性能、高扩展性协议服务器和客户

端。也就是说,Netty是一个NIO客户端/服务器框架,支持快速、简单地开发网络应用,如协议服务器和客户端。

它极大简化了网络编程,如TCP和UDP套接字服务器。

3、Grizzly

Grizzly是一种应用程序框架,专门解决编写成千上万用户访问服务器时候产生的各种问题。使用JAVA NIO作为基

础,并隐藏其编程的复杂性。容易使用的高性能的API。带来非阻塞socket到协议处理层。利用高性能的缓冲和缓

冲管理使用高性能的线程池。

从设计的理念上来看,Mina的设计理念是最为优雅的。当然,由于Netty的主导作者与Mina的主导作者是同一人,

出自同一人之手的Netty在设计理念上与Mina基本上是一致的。而Grizzly在设计理念上就较差了点,几乎是

JavaNIO的简单封装。

四.Netty为什么这么火?

Netty是目前最流行的由JBOSS提供的一个Java开源框架NIO框架,Netty提供异步的、事件驱动的网络应用程序框

架和工具,用以快速开发高性能、高可靠性的网络服务器和客户端程序。 相比JDK原生NIO,Netty提供了相对十分

简单易用的API,非常适合网络编程。Netty是完全基于NIO实现的,所以Netty是异步的。

作为一个异步NIO框架,Netty的所有IO操作都是异步非阻塞的,通过Future-Listener机制,用户可以方便的主动

获取或者通过通知机制获得IO操作结果。

Netty无疑是NIO的老大,它的健壮性、功能、性能、可定制性和可扩展性在同类框架都是首屈一指的。它已经得

到成百上千的商业/商用项目验证,如Hadoop的RPC框架Avro、RocketMQ以及主流的分布式通信框架Dubbo等

等。 为什么这么火,是有原因的。

Netty的优点可以总结如下:

API使用简单,开发门槛低;

功能强大,预置了多种编解码功能,支持多种主流协议;

定制能力强,可以通过ChannelHandler对通信框架进行灵活地扩展;

性能高,通过与其他业界主流的NIO框架对比,Netty的综合性能最优;

成熟、稳定,Netty修复了已经发现的所有JDK NIO BUG,业务开发人员不需要再为NIO的BUG而烦

恼;

社区活跃,版本迭代周期短,发现的BUG可以被及时修复,同时,更多的新功能会加入;

经历了大规模的商业应用考验,质量得到验证。在互联网、大数据、网络游戏、企业应用、电信软件等

众多行业得到成功商用,证明了它已经完全能够满足不同行业的商业应用了。

与Mina相比有什么优势:

1. 都是Trustin Lee的作品,Netty更晚;

2. Mina将内核和一些特性的联系过于紧密,使得用户在不需要这些特性的时候无法脱离,相比下性能会有

所下降,Netty解决了这个设计问题;

3. Netty的文档更清晰,很多Mina的特性在Netty里都有;

4. Netty更新周期更短,新版本的发布比较快;

5. 它们的架构差别不大,Mina靠apache生存,而Netty靠jboss,和jboss的结合度非常高,Netty有对

google protocal buf的支持,有更完整的ioc容器支持(spring,guice,jbossmc和osgi);

6. Netty比Mina使用起来更简单,Netty里你可以自定义的处理upstream events或/和downstream

events,可以使用decoder和encoder来解码和编码发送内容;

7. Netty和Mina在处理UDP时有一些不同,Netty将UDP无连接的特性暴露出来;而Mina对UDP进行了高

级层次的抽象,可以把UDP当成"面向连接"的协议,而要Netty做到这一点比较困难。

8. 从任务调度粒度上看,mina会将有IO任务的session写入队列中,当循环执行任务时,则会轮询所有的

session,并依次把session中的所有任务取出来运行。这样粗粒度的调度是不公平调度,会导致某些请

求的延迟很高。

原文地址:https://www.cnblogs.com/chuijingjing/p/10117606.html

时间: 2024-11-06 01:50:10

BIO & NIO & NIO常见框架的相关文章

Java 网络IO编程总结(BIO、NIO、AIO均含完整实例代码)

转载请注明出处:http://blog.csdn.net/anxpp/article/details/51512200,谢谢! 本文会从传统的BIO到NIO再到AIO自浅至深介绍,并附上完整的代码讲解. 下面代码中会使用这样一个例子:客户端发送一段算式的字符串到服务器,服务器计算后返回结果到客户端. 代码的所有说明,都直接作为注释,嵌入到代码中,看代码时就能更容易理解,代码中会用到一个计算结果的工具类,见文章代码部分. 相关的基础知识文章推荐: Linux 网络 I/O 模型简介(图文) Jav

Java IO:BIO和NIO区别及各自应用场景

转载请注明出处:jiq?钦's technical Blog - 季义钦 引言 BIO和NIO是两种不同的网络通信模型,现如今NIO已经大量应用在Jetty.ZooKeeper.Netty等开源框架中. 下面通过一个例子解释两者区别: 假设当前服务端程序需要同时从与多个客户端建立的连接读取数据. 使用BIO 如果采用阻塞式IO,单线程情况下,处理者线程可能阻塞在其中一个套接字的read上,导致另一个套接字即使准备好了数据也无法处理,这个时候解决的方法就是针对每一个套接字,都新建一个线程处理其数据

Java BIO、NIO、AIO

同步与异步 同步与异步的概念, 关注的是 消息通信机制 同步是指发出一个请求, 在没有得到结果之前该请求就不返回结果, 请求返回时, 也就得到结果了. 比如洗衣服, 把衣服放在洗衣机里, 没有洗好之前我们一直看着, 直到洗好了才拿出来晾晒. 异步是指发出一个请求后, 立刻得到了回应, 但没有返回结果. 这时我们可以再处理别的事情(发送其他请求), 所以这种方式需要我们通过状态主动查看是否有了结果, 或者可以设置一个回调来通知调用者. 比如洗衣服时, 把衣服放到洗衣机里, 我们就可以去做别的事情,

Java IO:BIO和NIO差别及各自应用场景

转载请注明出处:jiq?钦's technical Blog - 季义钦 引言 BIO和NIO是两种不同的网络通信模型,现现在NIO已经大量应用在Jetty.ZooKeeper.Netty等开源框架中. 一个面向流.一个面向缓冲区 一个是堵塞式的.一个非堵塞 一个没有io多路复用器.一个有 以下通过一个样例解释两者差别: 假设当前服务端程序须要同一时候从与多个client建立的连接读取数据. 使用BIO 假设採用堵塞式IO.单线程情况下.处理者线程可能堵塞在当中一个套接字的read上,导致还有一

Java的中BIO、NIO、AIO-2

Java的中BIO.NIO.AIO-2 java 举个栗子 接上一篇接着说,C/S模式.Reactor模式.Proactor模式是服务器处理IO常用的处理模型,这一篇就来解释一下这几种模式: 以一个餐饮为例,每一个人来就餐就是一个事件,他会先看一下菜单,然后点餐.就像一个网站会有很多的请求,要求服务器做一些事情.处理这些就餐事件的就需要我们的服务人员了. 在多线程处理的方式会是这样的: 一个人来就餐,一个服务员去服务,然后客人会看菜单,点菜. 服务员将菜单给后厨. 二个人来就餐,二个服务员去服务

Java的中BIO、NIO、AIO-1

Java的中BIO.NIO.AIO-1 java 最近在项目中用到TCP通信来完成命令和运行结果的交互,用的是典型的TCP通信中的C/S架构,原因很简单:在业务需求低的环境下,这种架构简单.稳定还容易写.但是在实际部署的情况下,一直出现读不到数据的空指针异常,按说BIO模式开发的应该阻塞直到有数据读取,没有找到原因就变通写了一个消息队列,使用定时器每1s从定时器中拿数据,解决了这个问题.但是想想这种同步阻塞的形式,就想了解一下其他的模式:NIO.AIO.好了,啰嗦了好多,进入正题: IO操作的基

Java中的BIO、NIO、AIO-3

Java中的BIO.NIO.AIO-3 java 这一篇是代码篇,敲代码有助于理解记忆这些抽象的东西: 参考资料: http://www.blogjava.net/killme2008/archive/2012/09/17/295743.html Java AIO初探(异步网络IO) https://www.ibm.com/developerworks/cn/java/j-lo-nio2/index.html 在 Java 7 中体会 NIO.2 异步执行的快乐 https://blog.csd

AIO,BIO,NIO区别

AIO,BIO,NIO都进程进行IO的三种不同方式. 对于网络模型,这三种方式具体表现如下: BIO:最常见的阻塞同步IO,是指客户端请求时,服务端会起一个线程,或者是在线程池调一个线程去处理读写,并维护连接.如果此时是长连接的话,这种方式无法达到较高并发量,因为线程本身不能起太多. 试想如下场景:做一个聊天服务器,你要对每个用户维护一个长连接.如果你用户量很高,有10w个同时在线,那你要起10w个线程,显然不实际.而且这10w个用户可能只有一部分在发送信息,那一定有很多线程是在阻塞态的,能不能

基础 | BIO、NIO与AIO

本文链接:https://blog.csdn.net/bingbeichen/article/details/83617163 Java中的IO部分比较复杂,具体可参看书籍<Java NIO>和<Netty权威指南>.在此,仅对BIO.NIO和AIO进行概述性梳理,未涉及到具体实现细节,后续有空将深入展开. 同步IO和异步IO参考答案: IO操作主要分为两个步骤,即发起IO请求和实际IO操作,同步IO与异步IO的区别就在于第二个步骤是否阻塞. 若实际IO操作阻塞请求进程,即请求进程