nio

NIO的全称是non-blocking IO，也就是非阻塞IO，也有的人叫他New IO。他的核心内容主要有三部分，Channel（通道），Buffer（缓冲区）, Selecto（选择器）。下面我们针对这三部分详细了解一下NIO。 Buffer（缓冲区） Buffer缓冲是一个指定固定数据量的容器，一个连续数组。除内容之外，缓冲区还具有位置和界限，其中位置是要读写的下一个元素的索引，界限是第一个应该读写的元素的索引。 java中每个非布尔基本类型都有一个缓冲区类。 Buffer通过 capacity, position, limit, mark 这四个变量来保存这个数据的当前位置状态，下面介绍一下这四个属性的意义。 capacity（ 容量值 ）：缓冲区数组的总长度 position（ 位置 ）：下一个要操作的数据元素的位置 limit（ 极限 ）：缓冲区数组中不可操作的下一个元素的位置 mark（ 标记 ）：用于记录当前position的位置，默认是-1 基本 Buffer 类定义了这些属性以及清除、反转和重绕方法，用以标记当前位置，以及将当前位置重置为前一个标记处。 clear() 使缓冲区准备好信道读取或相对 放置 操作的一个新的序列：它设置了限制的能力和位置为零。 flip() 使缓冲区准备好新的通道写入或相对 获取操作 序列：它将限制设置为当前位置，然后将位置设置为零。

Java中IO的模型分为三种，同步阻塞的BIO、同步非阻塞的NIO、异步非阻塞的AIO。 BIO【同步阻塞】 在JDK1.4出来之前，我们建立网络连接的时候采用BIO模式，需要先在服务端启动一个ServerSocket，然后在客户端启动Socket来对服务端进行通信，默认情况下服务端需要对每个请求建立一堆线程等待请求，而客户端发送请求后，先咨询服务端是否有线程相应，如果没有则会一直等待或者遭到拒绝请求，如果有的话，客户端会线程会等待请求结束后才继续执行。 NIO【同步非阻塞】 NIO本身是基于事件驱动思想来完成的，其主要想解决的是BIO的大并发问题： 在使用同步I/O的网络应用中，如果要同时处理多个客户端请求，或是在客户端要同时和多个服务器进行通讯，就必须使用多线程来处理。也就是说，将每一个客户端请求分配给一个线程来单独处理。这样做虽然可以达到我们的要求，但同时又会带来另外一个问题。由于每创建一个线程，就要为这个线程分配一定的内存空间（也叫工作存储器），而且操作系统本身也对线程的总数有一定的限制。如果客户端的请求过多，服务端程序可能会因为不堪重负而拒绝客户端的请求，甚至服务器可能会因此而瘫痪。 NIO基于Reactor，当socket有流可读或可写入socket时，操作系统会相应的通知引用程序进行处理，应用再将流读取到缓冲区或写入操作系统。 也就是说，这个时候

Java NIO的Buffer通常是用来和Channel作交互的。如你所知的，数据的读取是通过channel到buffer的，而数据的写入，是从buffer到channel的。 Buffer的本质是内存中的一个可读可写的数据块，这个数据块由NIO的Buffer对象封装，提供了一系列的支持内存操作的函数。 Buffer的基础用法 使用buffer，读写数据一般来说都有以下四步： 把数据写入到Buffer 调用flip函数 从Buffer中读取数据 调用clear函数或者compact函数 当你向buffer中写入数据时，buffer会持续追踪已经写入数据的数量。一旦你需要读取数据，就需要调用flip函数把buffer从writing模式转化成reading模式。在reading模式下，可以从buffer中读取所有已写入的数据。 一旦所有数据读取完毕，你需要清空buffer，以便buffer可以准备下一次的写入。清空可以使用调用clear方法或compact方法实现。clear方法会把整个buffer的数据清空，compact只会清空那些已经读取过的数据。那些未读取的数据会被移动到buffer的头部，后续的新数据会接在未读数据后面写入。 下面是一个简单的Buffer例子： RandomAccessFile aFile = new RandomAccessFile("data/nio

BIO与NIO、AIO的区别 名词解释： I/O：输入/输出(Input/Output)，分为IO设备和IO接口两个部分 Java 针对I/O设计的三种不同数据传输模式 BIO : 同步阻塞I/O NIO : 同步非阻塞I/O AIO : 异步阻塞I/O 1、区别比较优缺点 2、理解同步与异步区别、阻塞与非阻塞的区别 同步:发送一个请求,等待返回,然后再发送下一个请求 （比如广播，就是一个异步例子。发起者不关心接收者的状态。不需要等待接收者的返回信息） 异步:发送一个请求,不等待返回,随时可以再发送下一个请求 (电话，就是一个同步例子。发起者需要等待接收者，接通电话后，通信才开始。需要等待接收者的返回信息 ) 阻塞 非阻塞 3、适用场景 参考详细的文章 来源： CSDN 作者： 你这名字不好听 链接： https://blog.csdn.net/lizhenyu666/article/details/103898012

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 接上一篇 《异步IO实现IoFuture》 Filter 我们很熟悉，在 Mina 中， filter chain 的用法也类似于 Servlet 的 filters ，这种拦截器的设计思想能够狠轻松的帮助我们实现对资源的统一处理。我们先大致连接下 mina 中的 filter 能给我们带来什么。 LoggingFilter logs all events and requests. ProtocolCodecFilter converts an incoming ByteBuffer into message POJO and vice versa. CompressionFilter compresses all data. SSLFilter adds SSL - TLS - StartTLS support. and many more! 当然这中间最实用，而且源码篇幅最多的就是对 codec 的拦截器，这部分的应用就是可以实现自定义的编码器和解码器，并附上自定义的协议来进行通信。这部分的应用可以看： 《 Mina实现自定义协议的通信 》 在Mina源码中，对filter的描述主要分两部分，org.apache.mina.core.filterchain以及org.apache.mina.filter.

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 接上一篇 《Mina的连接IoConnector》 IoSession 是 Mina 管理两端的一个重要部分，也是 Mina 的核心， Session 具有了生命周期的概念，它的生命周期和连接时紧密相关的，这点在后面的介绍中会涉及。另外，好像 hibernate 中也有 session 也有生命周期（真的是好久没有用了，连 hibernate 有里 session 是干嘛的都想不起来了）。 在读源码之前，我们还是先了解下IoSession的作用和一些基本概念。IoSession的主要作用有如下一些： l 管理连接。注意，这里的管理连接并不是直接去控制我们上次讲的最底层的连接 acceptor 和 connector 。如果 acceptor 和 connector 建立的一条管道，那 session 就是在管道内的管理者，他是没有办法将管道对半拆分开的，他只能从内部阻断两边的通信。管理连接还有部分就是可以配置缓冲区的大小，闲置时间等等。 l 存储信息。和 web 里的 session 一样，这里的 session 也有存储 attribute 的功能，不过一般来说，这里存储的都是和连接有关的东西，并不会像 web 开发一样存一些业务上的东西。 l 驱动读写操作。我不知道用驱动这个词是否合适，那个例子来说，

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 最近在做通信和传输的项目，大量的使用 NIO 和 Mina ，虽然之前一直对这部分比较关注，但是还没有好好的总结一下这方面的内容。今天想写点儿 NIO 里最基本的一个类 ByteBuffer 。至于 Mina 中的 IoBuffer ，我们可以先看 Mina API 中的描述： A byte buffer used by MINA applications. This is a replacement for ByteBuffer. Please refer to ByteBuffer documentation for preliminary usage 。 当然，接下去也有写到： MINA does not use NIO ByteBuffer directly for two reasons ，至于这 Two Reasons ，我们将在后面的比较中展开。 ByteBuffer 继承了 Buffer ，对 Buffer 的理解可以说是 NIO 的入门。在 Buffer 中有 4 个重要的 Attributes ： Capacity: the capacity is set when the buffer is created and can never be changed 。 Limit: the

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 接着上篇 《IoBuffer的封装》 . 其实在 mina 的源码中， IoService 可以总结成五部分 service 责任、 Processor 线程处理、 handler 处理器、接收器和连接器，分别对应着 IoService 、 IoProcessor 、 IoHandler 、 IoAcceptor 和 IoConnector 。在代码的中有如下包跟 IoService 关系密切： org.apache.mina.core.service org.apache.mina.transport.* org.apache.mina.core.polling 这个包主要是实现了轮询策略 其中 core.service 包中主要定义了上面五个部分的接口，以及 IoHandler 和 IoProcessor 的实现（ Handler 是一种常见的设计模式，具体的业务其实并没有多少，只是在结构上将层次划分的更清楚。 Processor 是 mina 内部定义的接口，一般不对外使用，用 mina 官方的话，主要performs actual I/O operations for IoSession. 这一部分我想放在IoSession中来讲）。而在 transport 包中实现了具体的连接方式，当然