字节输入流 (InputStream) 底层原理

1. 核心目标：读取原始字节 (Raw Bytes)

InputStream 是所有字节输入流的抽象基类。它的核心使命非常纯粹和底层：从数据源（文件、网络连接、内存数组等）中，一次一个地读取原始的字节数据。

它是什么：一个通向数据源的单向“管道”，数据只能从源头流向你的程序。
它读什么：原始的字节（byte），即0到255之间的整数。
它的“无知”：InputStream 对数据的内容 一无所知。它不理解什么是字符、文本、图片或视频。在它眼中，所有数据都只是连续的字节序列。这使得它成为处理任何类型二进制数据的基础。

我们以最常用、最基础的 FileInputStream 为例来展开。

① 抽象基类：InputStream
- 职责：定义了所有字节输入流都必须遵守的“合同”，其中最核心的方法是 public abstract int read() throws IOException;。
- read() 方法解读：
  - 它从流中读取 一个字节。
  - 返回值是一个 int 类型。如果成功读取，这个 int 的值在 0 到 255 之间。
  - 如果到达流的末尾（End of Stream/File），它会返回 1。这是判断读取是否结束的关键标志。
② 文件实现：FileInputStream
- 职责：这是连接 Java程序 和 本地文件系统 的直接桥梁。
- 工作原理：
  1. 打开文件：当你执行 new FileInputStream("file.txt") 时，JVM会通过 JNI (Java Native Interface) 调用操作系统的底层函数（如 open()）来打开指定的文件。
  2. 获取句柄：操作系统会验证权限、找到文件，并返回一个 文件描述符（File Descriptor） 给JVM。这是一个代表了已打开文件的整数“句柄”。FileInputStream 内部会保存这个句柄。
  3. 读取字节：当你调用 fileInputStream.read() 时，会再次通过JNI调用操作系统的 read() 函数，并传入文件描述符。操作系统会从硬盘驱动器读取数据，先放入内核缓冲区，再复制到你的Java程序内存中。

直接调用 fileInputStream.read() 从文件中一个字节一个字节地读取，效率 极其低下。

原因：每一次 read() 调用，都会触发一次从Java程序（用户态）到操作系统内核（内核态）的切换，这被称为 “系统调用（System Call）”。系统调用涉及上下文切换，有相当大的性能开销。想象一下，为了读取1MB的文件，你需要进行超过一百万次这样昂贵的系统调用！

为了解决上述瓶颈，Java I/O 采用了经典的设计模式——装饰器模式（Decorator Pattern），BufferedInputStream 就是为此而生的。

结构：BufferedInputStream 包装（“装饰”）了另一个 InputStream（如 FileInputStream）。

// 推荐的用法
InputStream in = new BufferedInputStream(new FileInputStream("file.txt"));

工作流程（核心！）：

[创建与初始化]
- new BufferedInputStream(...) 会在内部创建一个 默认大小为 8192 字节（8KB）的字节数组 作为其私有的内部 缓冲区（buffer）。
- private byte buf[]; // 内部的字节数组缓冲区
[第一次调用 read()]
- 你的代码调用 in.read()。
- BufferedInputStream 检查自己的内部缓冲区，发现是空的。
- 于是，它不会只向 FileInputStream 请求1个字节，而是调用 fileInputStream.read(buf, 0, 8192)，尝试 一次性从文件中读取 8KB 的数据，填满自己的整个内部缓冲区。
- 这次“批发”式的读取只会发生 一次系统调用！
- 数据填满缓冲区后，BufferedInputStream 从缓冲区的第一个位置 (buf[0]) 取出1个字节，返回给你的代码。
[后续调用 read()]
- 你的代码再次调用 in.read()。
- BufferedInputStream 再次检查内部缓冲区，发现里面还有 8191 个字节。
- 它 不再需要访问 FileInputStream，更不需要麻烦操作系统和硬盘。它只是简单地从内部的 byte[] 数组的下一个位置 (buf[1], buf[2], ...) 取出一个字节并返回。
- 这是一个 纯内存操作，速度极快！