要说开发里最被低估的技术点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 prio5 os_prio0 tid0x00007f nid0x4a21 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字节流二进制文件、图片、压缩包无缓冲叠加BufferedInputStreamFileOutputStream字节输出流写二进制文件同上BufferedInputStream字节缓冲流绝大多数字节读取场景内部默认8KB可自定义BufferedOutputStream字节缓冲输出流大批量写文件记得flush/closeInputStreamReader字节到字符指定字符集读文本必须显式指定charsetOutputStreamWriter字符到字节指定字符集写文本同上BufferedReader字符缓冲流逐行读文本readLine很方便Files.newBufferedReader工具入口JDK 7推荐直接传Path和Charset2.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上默认可能是GBKLinux上默认是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看不见的第一个字符BOMByte Order Mark是很多编辑器在保存UTF-8文件时自动加的一个隐藏标记对应字节EF BB BF。它本身是不可见字符但程序读取时会把它当成一个合法的字符\uFEFF带进来。你可能会遇到这种情况解析一个JSON文件明明在编辑器里看语法完全没问题程序却报unexpected token或者读CSV时第一行第一列字段名前面多了一个看不见的字符导致按列名取数据全部取不到。处理的方式很简单读取文本文件时手动检查并跳过BOMtry (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\nWindows是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发送缓冲区满等待可写writeTimeoutJava原生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等待占80msCPU计算占20ms那么最佳线程数 ≈ 8 * (1 80 / 20) 40注意这只是一个估算起点。如果IO等待占比更高比如99%公式给出来的数字会很大但线程太多导致的上下文切换、内存占用又会反过来影响性能。实际工程中需要压测后调参但至少别再把线程数无脑设成核数*2。7. 高性能场景的IO优化零拷贝与异步7.1 传统文件发送为什么绕弯路如果你实现一个文件下载功能最直接的写法是从磁盘读取数据到程序内存再写到Socket。这个过程在操作系统层面至少发生两次不必要的数据复制磁盘 - 内核缓冲区 - 用户缓冲区 - 内核Socket缓冲区 - 网卡磁盘数据先进内核页缓存然后复制到用户空间再由用户空间复制回内核的Socket发送队列最后进入网卡。对于大文件这两次复制非常浪费CPU和内存带宽。Linux的sendfile系统调用可以让数据从内核缓冲区直接进入网卡跳过用户空间这一圈这就是零拷贝一词的来路。Java中对应的是FileChannel.transferTotry (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代码之前先找到自己在表里的位置就不会乱选工具了。我在实际项目里还有一个很朴素的习惯凡是涉及IOreview代码时第一眼看缓冲区第二眼看字符集第三眼看close和超时。这三样只要没问题IO代码大概率不会有大的幺蛾子。IO这个领域其实不复杂但恰恰因为它看起来太简单大家才容易在细节上翻车。希望这篇梳理能帮你在下次写出那几行普通到不能再普通的读写代码时多留一个心眼。