aio

Java网络通信中AIO使 用，既可以在并发情况下减少cpu对内存的占用(异步非阻塞的AIO某种程度可以替代多线程),又相对于传统NIO编程更容易上手。官方提供了两种方式实现AIO的 异 步通信代码风格，一种是回调方式，另种是future方式。本文针对后者提供一个聊天室的案例。因为全future模式相对于handler更加简单灵活。具体代码如下: 服务端代码如下: package com.itheima.SocketAioBroad; /* * aio聊天服务端代码，请先启动服务端的控制台，再启动客户端控制台， * Client,Client2,Client3均是客户端，模拟多人聊天室 */ import java.io.IOException; import java.net.InetSocketAddress; import java.nio.ByteBuffer; import java.nio.channels.AsynchronousServerSocketChannel; import java.nio.channels.AsynchronousSocketChannel; import java.nio.charset.Charset; import java.util.concurrent.CopyOnWriteArrayList; import java.util

BIO, NIO, AIO，本身的描述都是在Java语言的基础上的。 而描述IO，我们需要从三个层面： 编程语言 实现原理 底层基础 从编程语言层面 BIO, NIO, AIO以Java的角度理解： BIO，同步阻塞式IO，简单理解：一个连接一个线程 NIO，同步非阻塞IO，简单理解：一个请求一个线程 AIO，异步非阻塞IO，简单理解：一个有效请求一个线程 BIO 在JDK1.4之前，用Java编写网络请求，都是建立一个ServerSocket，然后，客户端建立Socket时就会询问是否有线程可以处理，如果没有，要么等待，要么被拒绝。即：一个连接，要求Server对应一个处理线程。 public class PlainEchoServer { public void serve(int port) throws IOException { final ServerSocket socket = new ServerSocket(port); //Bind server to port try { while (true) { //Block until new client connection is accepted final Socket clientSocket = socket.accept(); System.out.println("Accepted

先来个例子理解一下概念，以银行取款为例： 同步 ： 自己亲自出马持银行卡到银行取钱（使用同步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) ： 异步非阻塞

作者：公众号： 我是攻城师 前言 Java里面的IO模型种类较多，主要包括BIO，NIO和AIO，每个IO模型都有不一样的地方，那么这些IO模型是如何演变呢，底层的原理又是怎样的呢？ 本文我们就来聊聊。 BIO BIO全称是Blocking IO，是JDK1.4之前的传统IO模型，本身是同步阻塞模式，针对网络通信都是一请求一应答的方式，虽然简化了上层的应用开发，但在性能和可靠性方面存在着巨大瓶颈，试想一下如果每个请求都需要新建一个线程来专门处理，那么在高并发的场景下，机器资源很快就会被耗尽，当然，我们可以通过线程池来优化这种情况，但即使是这样，仍然改变不了阻塞IO的根本问题，就是在IO执行的两个阶段都被block了。拿一个read操作来举例子，在linux中，应用程序向linux发起read操作，会经历两个步骤： 第一个阶段linux内核首先会把需要读取的数据加载到操作系统内核的缓冲区中（Linux文件系统是缓存IO，也称标准IO） 第二个阶段应用程序拷贝内核里面的数据到自己的用户空间中 如果是socket操作，类似也会经历两个步骤： 第一个阶段：通常涉及等待网络上的数据分组包到达，然后被复制到内核的缓冲区 第二个阶段：把数据从内核缓冲区，从内核缓冲区拷贝到用户进程的内存空间里面 同步阻塞IO之所以效率低下，就是因为在这两个阶段，用户的线程或者进程都是阻塞的，期间虽然不占cpu资源

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

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