要说开发里最被低估的技术点，IO绝对排得上号。很多人觉得IO不就是读读文件、写写日志、从socket里收发数据嘛，API零门槛，随手就能写出来。可到了线上，出问题的往往就是这几行看起来人畜无害的代码。我去年处理过一次线上事故，某个服务的接口平时30毫秒就能返回，某天突然涨到两三秒，CPU、内存、数据库、下游依赖全部排查过都正常，最后抓线程栈才发现，一堆线程卡在FileInputStream.readBytes这个native方法上——有人在读一个几十MB的文件时逐字节读，一次读取就把整个服务的线程池全部堵住了。这次之后我就特别留意输入输出相关的代码，这篇文章就当是这些年踩坑的一个梳理。下面内容以Java生态为主，但底层思路换到别的语言一样适用。
1. 一次线上事故：IO慢起来不是开玩笑的
1.1 事故表象与第一轮排查
那个接口本身逻辑不算复杂，从本地磁盘加载一个几十MB的配置词典文件，做一次简单的关键词匹配后返回。平时P99在30ms上下，那天中午毫无征兆地变成2.8s左右，并且持续了接近半小时。
第一轮排查我把CPU、内存、GC、数据库慢查询、下游接口RT全部拉出来看了一遍，全部正常。服务没有报错，没有大量Full GC，网络带宽也没打满，看起来完全是"没事"的状态。唯一可疑的是，监控面板上线程池活跃线程数接近最大值，HTTP请求大量排队。
于是抓了一份线程dump。大量线程的栈都长这样：
"http-nio-8080-exec-47" #47 daemon prio=5 os_prio=0 tid=0x00007f nid=0x4a21 runnable [0x00007f] java.lang.Thread.State: RUNNABLE at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:255) at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) at java.io.BufferedInputStream.read1(BufferedInputStream.java:286) at java.io.BufferedInputStream.read(BufferedInputStream.java:345) at java.io.FilterInputStream.read(FilterInputStream.java:83) at com.example.DictionaryService.loadDictionary(DictionaryService.java:84)线程状态是RUNNABLE，没有锁竞争，没有等待条件。所有线程都堵在同一个文件的读取上。看到这里，问题已经比较清晰了。
1.2 逐字节读取的本质：一亿次系统调用
继续往下查，loadDictionary打开文件后，用的是BufferedInputStream.read()逐字节读取，然后拼接成字符串。大家注意，虽然这里套了BufferedInputStream，但外层逻辑每调一次只取一个字节，底层的系统调用数量依然被压到了最低，问题不在Buffer，而在于整个IO链路被这种写法拖成了"一次读一个字节"的疯狂模式。
我把核心逻辑简写一下，很多人应该见过这种代码：
try (InputStream in = new BufferedInputStream(new FileInputStream(path))) { int b; while ((b = in.read()) != -1) { // 一个字节一个字节地处理 sb.append((char) b); } }表面上看，BufferedInputStream已经把内部缓冲做好了，read()只做一次内存复制，不触发系统调用。但问题在于：这种写法把处理逻辑钉死在了单字节粒度上，逻辑本身没有错，问题是buffer里的每个字节在进入业务处理循环之前，还要经过append、类型转换、可能的数组扩容等一连串操作。当文件有几十MB、上亿字节时，这个循环就是上亿次迭代，每次迭代都有一堆Java层面的方法调用和内存操作。
更关键的是，这种循环的CPU占用率其实不会低，但它完全不是"计算密集"，大量时间浪费在方法调用和对象构建上。所以第一轮排查时CPU虽然看起来正常，但进程内部的大量时间片已经耗在了这种无意义的一字节一调用的循环里。
1.3 为什么这类问题特别容易漏过测试
事后我和那位负责的同学聊了聊，他很不解地说，本地测试的时候文件不大，几十KB的数据读起来毫无感觉，所以一直以为没问题。
这才是重点。IO相关的问题有很强的"数据量放大效应"：文件小的时候，任何写法都快；文件一旦大起来，读写策略的差距立刻变成数量级。测试环境没有人专门拿几百MB的真实文件去压生产同款数据，所以这种问题往往等到上线才暴露。
这也是我想说的第一句话：IO代码的性能不是写出来的，是测出来的。上线之前请一定用接近生产的数据规模做一次读写验证。
2. 流的分类与选型：字节、字符与缓冲
2.1 一切IO最终都是字节流
IO体系里最底层的概念是字节。磁盘上的文件是字节，网络传输的报文是字节，键盘输入的按键最终也是字节。字符流（Reader/Writer）并不是另一套IO，它只是在字节流外面包了一层编码解码器。字符流里的char在Java里是UTF-16编码的，底层读写时需要通过Charset把char和byte互相转换。
理解这一点，就能避免一个常见的误解：我读文本文件，到底该用InputStreamReader还是FileReader？答案是你可能两个都不该直接用，更好的入口是Files.newBufferedReader(path, charset)。下面这个表列出了常用的流和它们最适合的场景。
| 类/接口 | 类型 | 适用场景 | 注意点 |
|---|---|---|---|
FileInputStream | 字节流 | 二进制文件、图片、压缩包 | 无缓冲，叠加BufferedInputStream |
FileOutputStream | 字节输出流 | 写二进制文件 | 同上 |
BufferedInputStream | 字节缓冲流 | 绝大多数字节读取场景 | 内部默认8KB，可自定义 |
BufferedOutputStream | 字节缓冲输出流 | 大批量写文件 | 记得flush/close |
InputStreamReader | 字节到字符 | 指定字符集读文本 | 必须显式指定charset |
OutputStreamWriter | 字符到字节 | 指定字符集写文本 | 同上 |
BufferedReader | 字符缓冲流 | 逐行读文本 | readLine很方便 |
Files.newBufferedReader | 工具入口 | JDK 7+推荐 | 直接传Path和Charset |
2.2 字符流：编码的边界问题从这一层开始
字符流帮你处理了一个非常重要的细节：多字节字符的边界切分。UTF-8里一个汉字占3个字节，如果直接在字节流上按单个字节去拼接，必然出现乱码。字符流内部会维护解码状态，读到一个不完整的字节序列时会先缓存，等后续字节凑齐再解码成完整的char。
2.3 实践中我的选型习惯
我自己的习惯非常简单：
- 读
文本、日志、配置文件，一律走Files.newBufferedReader(path, StandardCharsets.UTF_8)，需要按行处理就用readLine()。 - 写文本，用
Files.newBufferedWriter，字符集同样显式指定。 - 处理
图片、视频、压缩包等二进制，直接用BufferedInputStream配一个byte[]缓冲。 - 需要按固定格式读二进制协议，用
DataInputStream，它能帮你读出一个int、一个long、一个UTF字符串，注意它有历史包袱，跨平台时UTF处理有坑。 - 自定义序列化才用
ObjectInputStream，但这东西版本兼容性很差，服务演化频繁的项目尽量别碰。
选型的标准只有一个：先搞清楚你的数据是字节还是文本，然后就别在脑海里把两者混着用。
3. 缓冲区大小与读写策略：几十倍性能差距从哪里来
3.1 实测：不同策略的感官差异
我没法给你精确到毫秒的基准测试，因为IO性能受磁盘类型、文件系统、JDK版本影响很大，但在我的环境里，用三种方式拷贝一个200MB文件的直观感受是这样的：
| 读写方式 | 相对耗时（以最快方式为1） | 为什么慢 |
|---|---|---|
逐字节read()/write() | 大约15~30倍 | 每次write()也可能触发一次系统调用甚至多次 |
| 8KB缓冲手动读写 | 1.3倍左右 | 缓冲命中稳定，系统调用次数大幅减少 |
| 64KB缓冲手动读写 | 1.0倍 | 拷贝次数进一步减少，接近最优 |
逐字节写入之所以更夸张，是因为BufferedOutputStream在满8KB时才真正落盘，但如果外层循环是逐字节write(int)，每一次都会进入BufferedOutputStream的内部方法，最终可能触发缓冲区fill或flush。缓冲区满了以后一次write(byte[], off, len)会变成一个系统调用，也就是说8KB触发一次，一个200MB文件也要触发两万多次。而正确的做法是每次直接read(byte[])一个较大的块，一次性拿到数据，再一次性写出去。
3.2 为什么缓冲区不是越大越好
很多人一听到"缓冲能提速"，恨不得开一个256MB的数组。其实缓冲区大小不是线性收益。原因有三点：
- 分配大数组会带来内存开销，数组太大导致GC压力直线上升。
- 拷贝时，字节数组越大，
System.arraycopy单次耗时虽然增加不多，但总量固定时，大块拷贝的效率提升并不成正比。 - 操作系统底层有页缓存、磁盘块对齐等机制，通常4KB、8KB就已经能对齐大多数文件系统的块大小；再往上，收益会进入边际递减区。
经验值我一般用8KB到64KB之间。文件单个读写很频繁时，64KB是个不错的平衡点；并发很高、内存紧张的服务，8KB更稳妥。
3.3 手动buffer和BufferedInputStream的关系
有些同学会问：我自己写了byte[] buf = new byte[8192]循环，还要不要包BufferedInputStream？答案是要分情况。
如果每次read(buf)都是完整读一个大块，再用write(buf,0,n)写出大块，你其实不需要BufferedInputStream，因为你已经在做批量IO了。反过来，如果你确实需要"一次一个字节"地处理（比如做某种格式解析），那就必须靠BufferedInputStream把系统调用次数压住，否则性能直接崩。
这里有个容易混淆的点：BufferedInputStream并不是"把数据预先读出来放到用户空间"的唯一手段。它的价值在于把"多次小读"变成"一次大读"。如果你自己控制好byte[]大小、循环读取，效果是一样的，只是可读性差一些。我通常优先用Files.newInputStream配合自建byte[]，因为代码意图清晰：这个文件我要分批处理，而不是逐字节。
4. 资源泄漏与自动关闭：随手写的close真安全吗
4.1 try-with-resources真的万事大吉吗
JDK 7之后，try-with-resources让资源关闭变得简单：
try (BufferedReader reader = Files.newBufferedReader(path, StandardCharsets.UTF_8)) { return reader.readLine(); } catch (IOException e) { log.error("读取失败", e); }但这不代表你可以随意堆流。编译器在背后把它展开成了try/catch/finally，并且在finally里依次调用每个资源的close()。多个资源的关闭顺序和创建顺序相反：后创建的先关闭。这一点在流之间有依赖时非常关键。
比如这样写：
try (FileInputStream fis = new FileInputStream(path); BufferedInputStream bis = new BufferedInputStream(fis)) { // 用bis读数据 }编译器会先关bis，再关fis。因为bis内部持有fis，关闭bis时会顺手把底层的fis也关掉；如果倒过来先关fis，那bis再去读就会抛Stream Closed。所以记住一个原则：有依赖关系的流，只需要关闭最外层的一个。
4.2 共享流关闭引发的连锁反应
我自己踩过一个很经典的坑。某项目里写了一个工具方法，传入一个InputStream做解析。工具方法内部图省事，直接在finally里close()了传入的流。结果调用方读完一次之后还想再读同一份数据，发现流已经关了，直接抛IOException。
事后才明白：谁创建谁关闭，工具方法只负责使用，不应该关闭传入的资源，除非方法签名明确说明了会接管这个资源。这个约定不写进注释，光靠代码review很难发现。
另外还有一个非常容易被大家忽略的点：System.in也是一个InputStream，它被关闭之后当前进程的标准输入就再也无法恢复。有些命令行工具因为读了System.in又顺手关了它，导致二次调用时直接读到EOF。控制台程序里千万不要去关System.in。
4.3 flush和close：数据丢在缓冲区的那些日子
字符流和字节缓冲流在内部都维护了缓冲数组。你写进去的数据先堆积在缓冲区，只有当缓冲区满了或者显式调用flush()才会真正写到目标文件。这个过程是正常的，但如果你在写完数据之后没有关闭也没有刷新，程序异常退出时，那一批还在内存缓冲区的数据就彻底丢了。
close()本身会先flush()再做关闭，所以很多人依赖close来兜底。但有个边界情况：你在一个流上写完一批数据之后，还需要继续使用底层流（比如复用网络连接），这时候就不能close，必须显式flush()把当前批次的数据推出去。
我的建议是：凡是写完一批数据、逻辑上需要"落盘"的节点，就显式调用flush()。不要指望着close帮你收拾，写出明确的步骤代码，才是真正可控的状态。
5. 编码、BOM与换行：文本IO的三大隐形坑
5.1 平台默认字符集是个坑
我见过无数次这样的问题：开发同学在Windows上用FileReader读一个UTF-8文件，一切正常；代码部署到Linux服务器之后，同一段逻辑读出来的中文全是乱码。为什么？因为FileReader没有显式指定字符集，它用的是JVM的平台默认字符集。Windows上默认可能是GBK，Linux上默认是UTF-8。一旦你在Windows上写代码时默认"恰好是对的"，到了Linux就全乱套。
正确姿势只有一个：任何时候读写文本，都要显式指定字符集。
// 错误示范：依赖默认字符集 try (Reader reader = new FileReader("data.txt")) { // ... } // 正确示范：显式指定UTF-8 try (Reader reader = Files.newBufferedReader(Paths.get("data.txt"), StandardCharsets.UTF_8)) { // ... }5.2 UTF-8 BOM：看不见的第一个字符
BOM（Byte Order Mark）是很多编辑器在保存UTF-8文件时自动加的一个隐藏标记，对应字节EF BB BF。它本身是不可见字符，但程序读取时会把它当成一个合法的字符\uFEFF带进来。
你可能会遇到这种情况：解析一个JSON文件，明明在编辑器里看语法完全没问题，程序却报unexpected token；或者读CSV时第一行第一列字段名前面多了一个看不见的字符，导致按列名取数据全部取不到。
处理的方式很简单，读取文本文件时手动检查并跳过BOM：
try (InputStream in = Files.newInputStream(path)) { PushbackInputStream pushback = new PushbackInputStream(in, 3); byte[] bom = new byte[3]; int n = pushback.read(bom, 0, 3); if (n == 3 && (bom[0] & 0xFF) == 0xEF && (bom[1] & 0xFF) == 0xBB && (bom[2] & 0xFF) == 0xBF) { // 命中UTF-8 BOM，丢弃 } else if (n > 0) { // 没有BOM，把读出来的字节推回流里 pushback.unread(bom, 0, n); } Reader reader = new InputStreamReader(pushback, StandardCharsets.UTF_8); // 后续读到的第一个字符就是真正的内容 }如果你用的是Apache Commons IO或类似工具库，通常有现成方法处理BOM，比如BOMInputStream。但原理就是上面这段。
5.3 CRLF与LF：换行符的差别比想象中大
Linux和macOS文本文件默认换行符是LF（\n），Windows是CRLF（\r\n）。如果你在Windows上读取一个LF结尾的文件，用BufferedReader.readLine()没任何问题，它会自动去掉行终止符；但如果你用逐字符或正则去处理，就会看到每行末尾多了一个\r，正则匹配字符串$会失败。
写文件也一样。Java里如果直接写\n，在Windows记事本打开会不换行，一整段内容挤在一起。跨平台场景建议使用System.lineSeparator()或者显式写\r\n。我个人的习惯是：如果文件是给程序消费的，统一用\n没问题；如果是给人用记事本看的，就用\r\n。搞清楚文件的下游是谁，比你用什么默认值更重要。
6. 网络IO的阻塞与超时：读不到数据时程序在想什么
6.1 阻塞IO的本质：线程睡着了
讨论网络IO时，很多人会把"阻塞"理解为"卡住不动"，其实不太准确。阻塞IO的read()调用在数据未到达时会主动让出CPU，线程进入等待状态。它不消耗CPU，但它占着一个线程名额。
一旦某个服务的线程池大小有限，比如200，而200个线程都阻塞在等待慢客户端的响应上，新的请求就全部排队，服务整体表现为"假死"。这种情况经常发生在连接池未设置超时、客户端不读响应、服务端又傻傻等待的场景里。
6.2 三个超时分开设置
网络IO至少涉及三个不同阶段的等待时间：
| 阶段 | 含义 | 常用参数 |
|---|---|---|
| 连接超时 | TCP握手建立连接 | connectTimeout |
| 读超时 | 等待服务端返回数据 | readTimeout/soTimeout |
| 写超时 | TCP发送缓冲区满，等待可写 | writeTimeout |
Java原生Socket可以这样设置：
Socket socket = new Socket(); socket.connect(new InetSocketAddress("192.168.1.10", 8080), 3000); // 连接超时3秒 socket.setSoTimeout(5000); // 读超时5秒大多数基于HTTP的调用，HttpURLConnection也有对应的setConnectTimeout和setReadTimeout。一个常见的坑是很多人只设置了连接超时，忘了读超时。结果连接建立得很快，但服务端一直不返回，调用方永远卡在read上，线上线程慢慢被打满。
记住：连接超时解决的是"连不上"，读超时解决的是"连上了但不返回"。两个都要设，一个都不能少。
6.3 一次性read不一定读完，别想当然
TCP是一种流协议，没有消息边界。InputStream.read()返回的字节数，并不保证等于你请求的字节数。比如你请求读100个字节，但内核可能只返回了30个，剩下的70个还在路上。
很多初学网络编程的人写出来的代码是这样的：
byte[] buf = new byte[1024]; int n = in.read(buf); // 假设n一定是1024，拿buf里的数据去解析这样在局域网里测试可能一直正常，因为数据包基本不会拆散。但一旦放到公网、经过复杂的路由和拥塞控制，超时重传、TCP分段都会让read返回不完整的块。正确做法是循环读取，直到读够目标长度或到达EOF。
同样的道理也适用于写。write()也可能只写出一部分字节，需要循环写入剩余部分。这个细节在本地文件IO里几乎不可能出现，但在网络IO里是非写不可的健壮性代码。
6.4 IO密集型任务线程数怎么估
线程池大小不是拍脑袋定的。IO密集型与CPU密集型不同，线程大部分时间在等待，理论上可以开更多线程而不至于产生严重上下文切换。一个粗略的经验公式是：
最佳线程数 ≈ 核数 * (1 + 等待时间 / 计算时间)假设8核机器，一次业务处理IO等待占80ms，CPU计算占20ms，那么：
最佳线程数 ≈ 8 * (1 + 80 / 20) = 40注意这只是一个估算起点。如果IO等待占比更高，比如99%，公式给出来的数字会很大，但线程太多导致的上下文切换、内存占用又会反过来影响性能。实际工程中需要压测后调参，但至少别再把线程数无脑设成"核数*2"。
7. 高性能场景的IO优化：零拷贝与异步
7.1 传统文件发送为什么绕弯路
如果你实现一个文件下载功能，最直接的写法是从磁盘读取数据到程序内存，再写到Socket。这个过程在操作系统层面至少发生两次不必要的数据复制：
磁盘 -> 内核缓冲区 -> 用户缓冲区 -> 内核Socket缓冲区 -> 网卡磁盘数据先进内核页缓存，然后复制到用户空间，再由用户空间复制回内核的Socket发送队列，最后进入网卡。对于大文件，这两次复制非常浪费CPU和内存带宽。
Linux的sendfile系统调用可以让数据从内核缓冲区直接进入网卡，跳过用户空间这一圈，这就是"零拷贝"一词的来路。Java中对应的是FileChannel.transferTo：
try (FileChannel fileChannel = FileChannel.open(path, StandardOpenOption.READ); SocketChannel socketChannel = SocketChannel.open(remote)) { long position = 0; long count = fileChannel.size(); while (position < count) { long sent = fileChannel.transferTo(position, count - position, socketChannel); position += sent; } }7.2 什么时候值得上NIO或异步
NIO（非阻塞IO）解决的是"大量连接但活跃度不高"的问题。传统阻塞模型下一个线程只能服务一个连接，如果单机要撑几万长连接，线程根本不够用。NIO用选择器（Selector）在一个线程里监听大量连接的读写事件，连接不活跃时线程可以去做别的事。
但非阻塞带来的复杂度是实打实的：半包/粘包处理、缓冲管理、事件回调的状态维护、异常处理的时序问题，都在等你踩坑。所以我一直觉得，NIO是"连接数压到实现模型极限"时才值得上的方案。如果项目只是几十个连接、请求量也不大，老老实实用阻塞IO加超时控制，代码好维护得多。
异步IO进一步提升了吞吐上限，但也把问题从"好定位的阻塞"变成"难排查的异步回调"。对于大多数业务系统，先解决同步IO的正确性、缓冲策略和超时配置，收益比盲目拥抱异步大得多。
7.3 高性能IO方案选择清单
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| 小文件读取（几MB以内） | Files.readAllBytes | 简单直接，不需要手动缓冲 |
| 大文件逐行处理 | Files.newBufferedReader+ readLine | 内存可控，不需要一次加载 |
| 大文件二进制拷贝 | 自建byte[64KB]循环 | 批量化，性能稳定 |
| 大文件网络发送 | FileChannel.transferTo | 零拷贝，减少内存复制 |
| 高并发长连接 | NIO/Netty | 线程模型匹配海量连接场景 |
这个清单是我的"默认答案"。每次写IO代码之前，先找到自己在表里的位置，就不会乱选工具了。
我在实际项目里还有一个很朴素的习惯：凡是涉及IO，review代码时第一眼看缓冲区，第二眼看字符集，第三眼看close和超时。这三样只要没问题，IO代码大概率不会有大的幺蛾子。IO这个领域其实不复杂，但恰恰因为它看起来太简单，大家才容易在细节上翻车。希望这篇梳理能帮你在下次写出那几行"普通到不能再普通"的读写代码时，多留一个心眼。
