深入理解BIO、NIO、AIO

    技术2022-07-10  123

    一、IO 介绍

    我们通常所说的 BIO 是相对于 NIO 来说的,BIO 也就是 Java 开始之初推出的 IO 操作模块,BIO 是 BlockingIO 的缩写,顾名思义就是阻塞 IO 的意思。AIO 是 NIO 的升级版本,提供了异步非堵塞的 IO 操作方式。

    1.1 BIO、NIO、AIO的区别

    BIO 就是传统的 java.io 包,它是基于流模型实现的,交互的方式是同步、阻塞方式,也就是说在读入输入流或者输出流时,在读写动作完成之前,线程会一直阻塞在那里,它们之间的调用时可靠的线性顺序。它的有点就是代码比较简单、直观;缺点就是 IO 的效率和扩展性很低,容易成为应用性能瓶颈。

    NIO 是 Java 1.4 引入的 java.nio 包,提供了 Channel、Selector、Buffer 等新的抽象,可以构建多路复用的、同步非阻塞 IO 程序,同时提供了更接近操作系统底层高性能的数据操作方式。

    AIO 是 Java 1.7 之后引入的包,是 NIO 的升级版本,提供了异步非堵塞的 IO 操作方式,所以人们叫它 AIO(Asynchronous IO),异步 IO 是基于事件和回调机制实现的,也就是应用操作之后会直接返回,不会堵塞在那里,当后台处理完成,操作系统会通知相应的线程进行后续的操作。

    1.2 全面认识 IO

    传统的 IO 大致可以分为4种类型:

    InputStream、OutputStream 基于字节操作的 IOWriter、Reader 基于字符操作的 IOFile 基于磁盘操作的 IOSocket 基于网络操作的 IO

    java.net 下提供的 Scoket 很多时候人们也把它归为 同步阻塞 IO ,因为网络通讯同样是 IO 行为。

    java.io 下的类和接口很多,但大体都是 InputStream、OutputStream、Writer、Reader 的子集,所有掌握这4个类和File的使用,是用好 IO 的关键。

    1.3 IO 使用

    接下来看 InputStream、OutputStream、Writer、Reader 的继承关系图和使用示例。

    1.3.1 InputStream 使用

    继承关系图和类方法,如下图:

    InputStream 使用示例:

    InputStream inputStream = new FileInputStream("D:\\log.txt"); byte[] bytes = new byte[inputStream.available()]; inputStream.read(bytes); String str = new String(bytes, "utf-8"); System.out.println(str); inputStream.close();
    1.3.2 OutputStream 使用

    OutputStream outputStream = new FileOutputStream("D:\\log.txt",true); // 参数二,表示是否追加,true=追加 outputStream.write("你好,老王".getBytes("utf-8")); outputStream.close();
    1.3.3 Writer 使用

    Writer writer = new FileWriter("D:\\log.txt",true); // 参数二,是否追加文件,true=追加 writer.append("老王,你好"); writer.close();
    1.3.4 Reader 使用

    Reader reader = new FileReader(filePath); BufferedReader bufferedReader = new BufferedReader(reader); StringBuffer bf = new StringBuffer(); String str; while ((str = bufferedReader.readLine()) != null) { bf.append(str + "\n"); } bufferedReader.close(); reader.close(); System.out.println(bf.toString());

    二、同步、异步、阻塞、非阻塞

    2.1 同步与异步

    同步就是一个任务的完成需要依赖另外一个任务时,只有等待被依赖的任务完成后,依赖的任务才能算完成,这是一种可靠的任务序列。要么成功都成功,失败都失败,两个任务的状态可以保持一致。而异步是不需要等待被依赖的任务完成,只是通知被依赖的任务要完成什么工作,依赖的任务也立即执行,只要自己完成了整个任务就算完成了。至于被依赖的任务最终是否真正完成,依赖它的任务无法确定,所以它是不可靠的任务序列。我们可以用打电话和发短信来很好的比喻同步与异步操作。

    2.2 阻塞与非阻塞

    阻塞与非阻塞主要是从 CPU 的消耗上来说的,阻塞就是 CPU 停下来等待一个慢的操作完成 CPU 才接着完成其它的事。非阻塞就是在这个慢的操作在执行时 CPU 去干其它别的事,等这个慢的操作完成时,CPU 再接着完成后续的操作。虽然表面上看非阻塞的方式可以明显的提高 CPU 的利用率,但是也带了另外一种后果就是系统的线程切换增加。增加的 CPU 使用时间能不能补偿系统的切换成本需要好好评估。

    2.3 同/异、阻/非堵塞 组合

    同/异、阻/非堵塞的组合,有四种类型,如下表:

    组合方式性能分析同步阻塞最常用的一种用法,使用也是最简单的,但是 I/O 性能一般很差,CPU 大部分在空闲状态。同步非阻塞提升 I/O 性能的常用手段,就是将 I/O 的阻塞改成非阻塞方式,尤其在网络 I/O 是长连接,同时传输数据也不是很多的情况下,提升性能非常有效。 这种方式通常能提升 I/O 性能,但是会增加CPU 消耗,要考虑增加的 I/O 性能能不能补偿 CPU 的消耗,也就是系统的瓶颈是在 I/O 还是在 CPU 上。异步阻塞这种方式在分布式数据库中经常用到,例如在网一个分布式数据库中写一条记录,通常会有一份是同步阻塞的记录,而还有两至三份是备份记录会写到其它机器上,这些备份记录通常都是采用异步阻塞的方式写 I/O。异步阻塞对网络 I/O 能够提升效率,尤其像上面这种同时写多份相同数据的情况。异步非阻塞这种组合方式用起来比较复杂,只有在一些非常复杂的分布式情况下使用,像集群之间的消息同步机制一般用这种 I/O 组合方式。如 Cassandra 的 Gossip 通信机制就是采用异步非阻塞的方式。它适合同时要传多份相同的数据到集群中不同的机器,同时数据的传输量虽然不大,但是却非常频繁。这种网络 I/O 用这个方式性能能达到最高。

    三、优雅的文件读写

    Java 7 之前文件的读取是这样的:

    // 添加文件 FileWriter fileWriter = new FileWriter(filePath, true); fileWriter.write(Content); fileWriter.close(); // 读取文件 FileReader fileReader = new FileReader(filePath); BufferedReader bufferedReader = new BufferedReader(fileReader); StringBuffer bf = new StringBuffer(); String str; while ((str = bufferedReader.readLine()) != null) { bf.append(str + "\n"); } bufferedReader.close(); fileReader.close(); System.out.println(bf.toString());

    Java 7 引入了Files(java.nio包下)的,大大简化了文件的读写,如下

    // 写入文件(追加方式:StandardOpenOption.APPEND) Files.write(Paths.get(filePath), Content.getBytes(StandardCharsets.UTF_8), StandardOpenOption.APPEND); // 读取文件 byte[] data = Files.readAllBytes(Paths.get(filePath)); System.out.println(new String(data, StandardCharsets.UTF_8));

    Files 下还有很多有用的方法,比如创建多层文件夹,写法上也简单了:

    // 创建多(单)层目录(如果不存在创建,存在不会报错) new File("D://a//b").mkdirs();

    五、总结

    以上基本就是 IO 从 1.0 到目前版本(本文的版本)JDK 8 的核心使用操作了,可以看出来 IO 作为比较常用的基础功能,发展变化的改动也很大,而且使用起来也越来越简单了,IO 的操作也是比较好理解的,一个输入一个输出,掌握好了输入输出也就掌握好了 IO。

    Processed: 0.032, SQL: 9