Java 基础之 io 流

Question

IO 流

IO

Java 流操作有关的类或接口：

Java 流类图结构：

流的概念和作用

流是一组有顺序的，有起点和终点的字节集合，是对数据传输的总称或抽象。即数据在两设备间的传输称为流， 流的本质是数据传输，根据数据传输特性将流抽象为各种类，方便更直观的进行数据操作。

IO 流的分类

• 根据处理数据类型的不同分为：字符流和字节流
• 根据数据流向不同分为：输入流和输出流

字符流和字节流

字符流的由来： 因为数据编码的不同，而有了对字符进行高效操作的流对象。本质其实就是基于字节流读取时，去查了指定的码表。 字节流和字符流的区别：

• 读写单位不同：字节流以字节（8bit）为单位，字符流以字符为单位，根据码表映射字符，一次可能读多个字节。
• 处理对象不同：字节流能处理所有类型的数据（如图片、avi 等），而字符流只能处理字符类型的数据。

结论：只要是处理纯文本数据，就优先考虑使用字符流。 除此之外都使用字节流。

输入流和输出流

对输入流只能进行读操作，对输出流只能进行写操作，程序中需要根据待传输数据的不同特性而使用不同的流。

Java IO 流对象

1. 输入字节流 InputStream

IO 中输入字节流的继承图可见上图，可以看出：

1. InputStream 是所有的输入字节流的父类，它是一个抽象类。
2. ByteArrayInputStream、StringBufferInputStream、FileInputStream 是三种基本的介质流，它们分别从 Byte 数组、StringBuffer、和本地文件中读取数据。PipedInputStream 是从与其它线程共用的管道中读取数据，与 Piped 相关的知识后续单独介绍。
3. ObjectInputStream 和所有 FilterInputStream 的子类都是装饰流（装饰器模式的主角）。

2. 输出字节流 OutputStream

IO 中输出字节流的继承图可见上图，可以看出：

1. OutputStream 是所有的输出字节流的父类，它是一个抽象类。
2. ByteArrayOutputStream、FileOutputStream 是两种基本的介质流，它们分别向 Byte 数组、和本地文件中写入数据。PipedOutputStream 是向与其它线程共用的管道中写入数据，
3. ObjectOutputStream 和所有 FilterOutputStream 的子类都是装饰流。

3. 字节流的输入与输出的对应

图中蓝色的为主要的对应部分，红色的部分就是不对应部分。紫色的虚线部分代表这些流一般要搭配使用。从上面的图中可以看出 Java IO 中的字节流是极其对称的。“存在及合理”我们看看这些字节流中不太对称的几个类吧！

1. LineNumberInputStream 主要完成从流中读取数据时，会得到相应的行号，至于什么时候分行、在哪里分行是由改类主动确定的，并不是在原始中有这样一个行号。在输出部分没有对应的部分，我们完全可以自己建立一个 LineNumberOutputStream，在最初写入时会有一个基准的行号，以后每次遇到换行时会在下一行添加一个行号，看起来也是可以的。好像更不入流了。
2. PushbackInputStream 的功能是查看最后一个字节，不满意就放入缓冲区。主要用在编译器的语法、词法分析部分。输出部分的 BufferedOutputStream 几乎实现相近的功能。
3. StringBufferInputStream 已经被 Deprecated，本身就不应该出现在 InputStream 部分，主要因为 String 应该属于字符流的范围。已经被废弃了，当然输出部分也没有必要需要它了！还允许它存在只是为了保持版本的向下兼容而已。
4. SequenceInputStream 可以认为是一个工具类，将两个或者多个输入流当成一个输入流依次读取。完全可以从 IO 包中去除，还完全不影响 IO 包的结构，却让其更“纯洁”――纯洁的 Decorator 模式。
5. PrintStream 也可以认为是一个辅助工具。主要可以向其他输出流，或者 FileInputStream 写入数据，本身内部实现还是带缓冲的。本质上是对其它流的综合运用的一个工具而已。一样可以踢出 IO 包！System.out 和 System.out 就是 PrintStream 的实例！

4. 字符输入流 Reader

在上面的继承关系图中可以看出：

1. Reader 是所有的输入字符流的父类，它是一个抽象类。
2. CharReader、StringReader 是两种基本的介质流，它们分别将 Char 数组、String 中读取数据。PipedReader 是从与其它线程共用的管道中读取数据。
3. BufferedReader 很明显就是一个装饰器，它和其子类负责装饰其它 Reader 对象。
4. FilterReader 是所有自定义具体装饰流的父类，其子类 PushbackReader 对 Reader 对象进行装饰，会增加一个行号。
5. InputStreamReader 是一个连接字节流和字符流的桥梁，它将字节流转变为字符流。FileReader 可以说是一个达到此功能、常用的工具类，在其源代码中明显使用了将 FileInputStream 转变为 Reader 的方法。我们可以从这个类中得到一定的技巧。Reader 中各个类的用途和使用方法基本和 InputStream 中的类使用一致。后面会有 Reader 与 InputStream 的对应关系。

5. 字符输出流 Writer

在上面的关系图中可以看出：

1. Writer 是所有的输出字符流的父类，它是一个抽象类。
2. CharArrayWriter、StringWriter 是两种基本的介质流，它们分别向 Char 数组、String 中写入数据。PipedWriter 是向与其它线程共用的管道中写入数据，
3. BufferedWriter 是一个装饰器为 Writer 提供缓冲功能。
4. PrintWriter 和 PrintStream 极其类似，功能和使用也非常相似。
5. OutputStreamWriter 是 OutputStream 到 Writer 转换的桥梁，它的子类 FileWriter 其实就是一个实现此功能的具体类（具体可以研究一 SourceCode）。功能和使用和 OutputStream 极其类似，后面会有它们的对应图。

6. 字符流的输入与输出的对应

7.字符流与字节流转换

转换流的特点：

1. 其是字符流和字节流之间的桥梁
2. 可对读取到的字节数据经过指定编码转换成字符
3. 可对读取到的字符数据经过指定编码转换成字节

何时使用转换流？

1. 当字节和字符之间有转换动作时；
2. 流操作的数据需要编码或解码时。

具体的对象体现：

1. InputStreamReader:字节到字符的桥梁
2. OutputStreamWriter:字符到字节的桥梁

这两个流对象是字符体系中的成员，它们有转换作用，本身又是字符流，所以在构造的时候需要传入字节流对象进来。

8.File 类

File 类是对文件系统中文件以及文件夹进行封装的对象，可以通过对象的思想来操作文件和文件夹。 File 类保存文件或目录的各种元数据信息，包括文件名、文件长度、最后修改时间、是否可读、获取当前文件的路径名，判断指定文件是否存在、获得当前目录中的文件列表，创建、删除文件和目录等方法。

9.RandomAccessFile 类

该对象并不是流体系中的一员，其封装了字节流，同时还封装了一个缓冲区（字符数组），通过内部的指针来操作字符数组中的数据。 该对象特点：

1. 该对象只能操作文件，所以构造函数接收两种类型的参数：a.字符串文件路径；b.File 对象。
2. 该对象既可以对文件进行读操作，也能进行写操作，在进行对象实例化时可指定操作模式(r,rw)

注意：该对象在实例化时，如果要操作的文件不存在，会自动创建；如果文件存在，写数据未指定位置，会从头开始写，即覆盖原有的内容。 可以用于多线程下载或多个线程同时写数据到文件。

IO 方式

IO 分类

• 线程状态角度： 阻塞 IO 和 非阻塞 IO 这两个概念是程序级别的。主要描述的是程序请求操作系统 IO 操作后，如果 IO 资源没有准备好，那么程序该如何处理的问题：前者进入阻塞态等待 IO 完成；后者则继续执行下面的代码
• 代码执行角度： 同步 IO 和 异步 IO ，这两个概念是操作系统级别的。主要描述的是操作系统在收到程序请求 IO 操作后，如果 IO 资源没有准备好，该如何响应程序的问题：前者不响应，直到 IO 资源准备好以后；后者返回一个标记（好让程序和自己知道以后的数据往哪里通知），当 IO 资源准备好以后，再用事件机制返回给程序。（这里应该参考数电中的同步异步概念更好理解）。本质上就是依赖于 IO 操作的后续控制流与原控制流是否是”步调一致“的

网络 IO*

同步阻塞模式（Blocking IO）

原语伪代码如下

{
    // 阻塞，直到有数据
    read(socket_fd, buffer);
    process(buffer);
}

也就说若当前数据没有准备好则当前线程会阻塞在这里，即一个线程只能同时处理一次请求

非阻塞 IO（Non-Blocking IO）

伪代码实现

{
while(true){
for(Soket s: Sockets){
 if(s.isAccepted){
 accept();
 }
 id(s.readable){
 read();
 }
 ...
}
}
}

非阻塞 IO 的核心在于使用一个 Selector 来管理多个通道，可以是 SocketChannel，也可以是 ServerSocketChannel，将各个通道注册到 Selector 上，指定监听的事件。

之后可以只用一个线程来轮询这个 Selector，看看上面是否有通道是准备好的，当通道准备好可读或可写，然后才去开始真正的读写，这样速度就很快了。我们就完全没有必要给每个通道都起一个线程。

NIO 中 Selector 是对底层操作系统实现的一个抽象，管理通道状态其实都是底层系统实现的，这里简单介绍下在不同系统下的实现。

select ：上世纪 80 年代就实现了，它支持注册 FD_SETSIZE(1024) 个 socket，在那个年代肯定是够用的

1.6 上 windows 的实现就是这个

poll ：1997 年，出现了 poll 作为 select 的替代者，最大的区别就是，poll 不再限制 socket 数量。

select 和 poll 都有一个共同的问题，必须全遍历一遍才知道哪个准备好了

epoll ：2002 年随 Linux 内核 2.5.44 发布，epoll 能直接返回具体的准备好的通道，时间复杂度 O(1)

这个 e 就是 event 的意思，对应连接时间，读写事件都直接投递到队列中，只要遍历这个队列就行了，直接处理事件

异步 IO（Asynchronous IO）

简单来说就是直接交由内核处理，并且添加一个回调。

即提交任务后线程可以直接返回。

在 Unix/Linux 等系统中，JDK 使用了并发包中的线程池来管理任务 ，具体可以查看 AsynchronousChannelGroup 的源码。(linux 5.17 已经实装了 IO_Uring 方案和 IOCP 异曲同工，但是目前 jdk 没有使用这个接口，2022 年 4 月 22 日)，请参考 An Introduction to the io_uring Asynchronous I/O Framework | by Sergio | Oracle Developers | Medium

在 Windows 操作系统中，提供了一个叫做 I/O Completion Ports 的方案，通常简称为 IOCP ，操作系统负责管理线程池，其性能非常优异，所以 在 Windows 中 JDK 直接采用了 IOCP 的支持 ，使用系统支持，把更多的操作信息暴露给操作系统，也使得操作系统能够对我们的 IO 进行一定程度的优化。

而对于 Linux 平台，目前稳定版本上的 AIO 实现其实就是 NIO，这就是为什么要用 JUC 的线程池管理

网络 IO 进阶我会在 netty 部分和 java 协程详细讲述