IO 与 NIO 基础：字节怎么进来，怎么出去

• 贵的不是字节，是“进内核”这一下：一次系统调用要切换到内核态再回来，搬 1 个字节和搬 8192 个字节，这部分成本差不多。
• BufferedInputStream 读的时候还是一次一个字节，但它背后一次向内核要 8 KB，于是系统调用从 200 万次降到两三百次。它比自己用数组慢（64 ms 对 2.4 ms），是因为 Java 这边仍然调了 200 万次方法。
• 缺的那一块：成块地搬（缓冲）；能让内核直接搬的，就别让数据进 JVM（Files.copy、transferTo 底下是 Linux 的 sendfile）。

不懂精华时的典型误用：给 FileReader 套了 BufferedReader，却没指定字符集。开发机是 UTF-8，部署到一台默认 GBK 的 Windows 服务器上，导出的对账文件全成了乱码（⑥ 坑 1）。

选择规则：操作文件先用 Files（读写全部、按行流式读、复制）；对接库就用流，记得包缓冲、写明字符集；网络服务器和大文件拷贝交给 NIO 的 Channel，这一层多半由 Tomcat、Netty、Kafka 替你写好了。

④-1流：一层层套起来的装饰器

④-2字符集：同样的字节，换个字典就是乱码

• 1“机械键盘”用 UTF-8 编码是 12 个字节（每个汉字 3 个）。实测 同一份对账文件的字节，用 UTF-8 读是 机械键盘，用 GBK 读是 鏈烘閿洏，用 ISO-8859-1 读是一串带重音的拉丁字母。字节一个没变，变的是“查哪本字典”。
• 2按字节切断会切坏字符：实测 只拿前 4 个字节解码，得到 机�，第二个字只剩 1/3，变成替换字符 �。所以“按 1024 字节分块读，每块各自 new String”是错的，解码必须交给 Reader（它会把半个字符留到下一块）。
• 3没写字符集时用“平台默认字符集”。JDK 17 及以前，它取决于操作系统和 locale（本机是 C.UTF-8，所以是 UTF-8；中文 Windows 默认是 GBK）；JDK 18 起默认一律 UTF-8（JEP 400）。靠默认值，代码换台机器就可能乱码。

④-3ByteBuffer：一块数组，加上三个指针

• 1写模式：position 是下一个要写的位置，limit = capacity。put 一次，position 往后挪。
• 2flip()：limit = position; position = 0，切到读模式：从头读，读到刚才写到的地方为止。忘了 flip，就会从写到的位置往后读，读到的是没写过的 0（实测 还剩 12 字节“可读”）。
• 3compact()：把没读完的字节挪到最前面，切回写模式，接着往后写。网络读写里“一条消息没收完整”时就用它，Tomcat 解析 HTTP 请求头时也会遇到这种半截数据。clear() 不清数据，只是把指针复位，旧数据会被覆盖。
• 4为什么一个 Buffer 读写共用、要手动 flip？因为它要直接交给 Channel 和内核：Channel 从 position 读到 limit、或者从 position 写到 limit，指针本身就是和内核交接的“这次搬多少”。代价是使用者必须自己记得切模式。

模拟和 ⑤ 的 JDK 17 实测一致（allocate(16) → put 5 字节 → flip → get 4 → compact，指针依次是 0/16、5/16、0/5、4/5、1/16），逻辑在 node 里跑过。

④-4Channel 和零拷贝：让内核自己在两个文件之间搬

• 1堆内缓冲 vs 直接缓冲：ByteBuffer.allocate 在 Java 堆上，背后是一个 byte[]（实测 hasArray=true）；allocateDirect 在堆外，没有 array（hasArray=false）。做系统调用时，内核要一块地址不会被 GC 挪动的内存，堆内缓冲会先被 JDK 拷进一块临时的直接缓冲再交给内核，所以网络框架（Netty、Tomcat）都自己管理直接缓冲。代价是分配和回收慢，大小受 -XX:MaxDirectMemorySize 限制，泄漏了也不在堆转储里（⑥ 坑 4）。
• 2为什么这样设计：java.io 的流是一个字节一个字节的抽象，好用但离操作系统远；NIO 把“一块内存 + 一个通道”直接摆出来，和操作系统的 read / write / sendfile 一一对应。业务代码不需要这么底层，所以 JDK 7 又在上面加了 Files 这一层“一行搞定”的工具，底下再按平台选最快的实现（比如 Linux 上用 sendfile）。

最少语法

Path p = Path.of("orders-20261109.csv");
try (BufferedWriter w = Files.newBufferedWriter(p, StandardCharsets.UTF_8)) { w.write(…); w.newLine(); }
List<String> all = Files.readAllLines(p, UTF_8);                    // 小文件
try (Stream<String> lines = Files.lines(p, UTF_8)) { … }             // 大文件：惰性，必须关
Files.copy(src, dst, StandardCopyOption.REPLACE_EXISTING);
try (InputStream in = new BufferedInputStream(req.getInputStream())) { … }   // 对接库
ByteBuffer b = ByteBuffer.allocate(8192);  ch.read(b);  b.flip();  … b.compact();
try (FileChannel in = FileChannel.open(src, READ); FileChannel out = FileChannel.open(dst, CREATE, WRITE)) {
    for (long pos = 0, n = in.size(); pos < n; ) pos += in.transferTo(pos, n - pos, out);
}

• Netty 的 ByteBuf：读写两个指针不用 flip，池化的直接内存，引用计数
• MappedByteBuffer 实战：用内存映射做一个追加写日志文件（对照 Kafka、RocketMQ）
• 大文件导出到浏览器：流式响应（StreamingResponseBody），边查库边写，不占内存
• 网络这一层继续往下：TCP 的发送缓冲区、Nagle、粘包拆包（J04）

自测