说实话刚开始学Java那会儿我对BIO流是有点看不上的。FileInputStream、BufferedReader、ServerSocket这些类名透着一股“上古时代”的味道谁不想直接上手NIO、Netty呢。但这几年真刀真枪地做项目、排查线上问题之后我发现自己绕了一大圈又绕回了BIO流读配置文件是BIO输出日志是BIO客户端Socket收发消息还是BIO。甚至在面试实习生时候我把一个最基本的“用BIO复制文件”的代码摆在面前仍然有一大半人写不对。所以这一篇我想把Java BIO流一次性说透从类结构、阻塞原理、使用技巧到它和NIO/AIO的边界全都用实操案例讲明白。不管你是在啃Java基础还是准备面试或者正在维护一个老项目都能从这里找到对应的参考。1. 从一次文件复制事故说起BIO流的真实存在感1.1 那段“教科书级”的复制代码很多人学习BIO流时第一步就是写一个文件复制。代码看着特别简单但真正能一次写对的人不多。先看一个标准的写法这也是我在项目里最常用的模板Path source Paths.get(input.bin); Path target Paths.get(output.bin); try (InputStream in new FileInputStream(source.toFile()); OutputStream out new FileOutputStream(target.toFile())) { byte[] buffer new byte[8192]; int len; while ((len in.read(buffer)) ! -1) { out.write(buffer, 0, len); } }这段代码里有三个非常容易被忽略的细节。第一个细节read(byte[])返回的是实际读到的字节数不是缓冲区大小。返回-1才表示读到文件末尾。很多新手会写成while (in.read(buffer) ! -1)然后在循环体里直接out.write(buffer)。这会造成什么后果最后一次读取缓冲区往往没填满但write(buffer)会把整个byte[8192]都写进目标文件于是文件末尾出现大量残留的旧数据。为什么说是“残留”因为如果最后一次读到的长度小于缓冲区长度缓冲区的后半部分还是上一次循环留下的内容这些数据本来不属于源文件却被一起写出去了。典型症状就是复制出来的文件比源文件大而且大小恰好是8KB的整数倍多出来一截。第二个细节write(buffer, 0, len)必须带上长度。前面说的out.write(buffer)没有指定偏移和长度等于无条件写满整个缓冲区。正确写法是只写len个字节。第三个细节try-with-resources会自动关闭流不用在finally里手动写close()。Java 7开始推荐这种写法代码短、不容易漏关。如果还在用旧式写法记得关闭顺序要和打开顺序相反不过用try-with-resources就省心多了。我印象很深的一次事故就是团队里一个同学用while ((len in.read(buffer)) ! -1)配out.write(buffer)日志文件复制出来尾部全是乱码。我们排查了很久先用ls -l对比文件大小再用十六进制工具查看文件尾部才发现是多写了一段缓存里的旧内容。这种问题不深入理解BIO流的读取语义光靠IDE自动补全很难发现。1.2 别小看IO流它决定你代码的下限有人觉得BIO流太基础不屑一顾。但实际上Java生态里到处都是它的影子System.out.println底层是PrintStream日志框架的FileAppender底层是FileOutputStreamProperties.load底层是InputStreamReader。甚至很多序列化框架的兼容层也少不了对InputStream和OutputStream的操作。你写一个Spring Boot应用读取application.yml是IO把报表导出成Excel是IO调用第三方HTTP接口时响应体也是通过InputStream读到内存的。所以表面上看你在写业务实际都是在跟流打交道。BIO流还是理解整个IO模型的起点。只有先搞懂它为什么“阻塞”为什么“每连接一线程”才能理解NIO为什么引入Channel和SelectorAIO为什么走回调。这个基础不牢后面学Netty也会很飘。所以这篇讲BIO流不是怀旧而是打地基。2. BIO流的家底字节流、字符流与包装流2.1 输入输出方向是怎么确定的Java IO流的方向判断有一个很朴素的规则以应用程序为中心。数据从外部进到内存叫输入从内存写到外部叫输出。于是就有了四大家族类型输入流输出流最小数据单位字节流InputStreamOutputStreambyte字符流ReaderWriterchar字节流适合处理图片、音频、视频、压缩包等二进制数据。字符流适合处理文本文件因为文本涉及字符集编码Reader和Writer在处理过程中会做字节到字符的转换。但这里要特别注意字符流底层仍然是字节流。FileReader的继承链是InputStreamReader - Reader而InputStreamReader内部包装了一个InputStream。所以不存在“字符流完全脱离字节流”的说法只是它在字节流上多了一层解码编码逻辑。我在实际工作中最常用的判断标准是只要内容是给人看的文本就用Reader/Writer只要内容是机器数据就用InputStream/OutputStream。如果你非要用Reader去读一张图片读出来的结果是啥大部分字符无法映射到合法字符最后得到一串乱码而且读取过程会非常慢。反过来用字节流读文本也不是不行但你要自己处理字符集。比如一行文本用ByteArrayInputStream读出来后还得用new String(bytes, StandardCharsets.UTF_8)手动转换。有这个功夫不如直接上BufferedReader。2.2 装饰器模式让流可以“套娃”如果你翻开java.io包的源码会看到很多以Filter开头的类比如FilterInputStream、FilterOutputStream、FilterReader、FilterWriter。它们存在的意义就是实现装饰器模式让流可以一层套一层每套一层就增加一个新的能力。举个例子我要读取一个存放基本类型数据的文件可以这样套try (DataInputStream dis new DataInputStream( new BufferedInputStream( new FileInputStream(data.bin)))) { int code dis.readInt(); double price dis.readDouble(); boolean flag dis.readBoolean(); }最里层是FileInputStream负责从文件读字节中间套一个BufferedInputStream负责缓冲减少磁盘IO次数最外层是DataInputStream负责把字节解析成int、double这些Java基本类型。这种套法就是装饰器模式最典型的使用场景。为什么需要缓冲因为每调用一次read()操作系统通常都会执行一次底层读取。如果你一个字节一个字节地读磁盘IO次数就是文件字节数性能差到没法看。BufferedInputStream会预读8KB到内存之后你读字节时大部分请求都命中内存缓冲区只有缓冲区空了才再去底层读。这个8KB默认值在源码里是DEFAULT_BUFFER_SIZE 8192。类似的常用包装关系我也整理了一张表包装流作用典型用法BufferedInputStream/BufferedOutputStream提供缓冲减少IO次数包在文件流外面DataInputStream/DataOutputStream读写Java基本类型和UTF字符串包在缓冲流外面ObjectInputStream/ObjectOutputStream序列化/反序列化Java对象包在缓冲流外面InputStreamReader/OutputStreamWriter字节流与字符流之间的桥梁包在文件字节流外面BufferedReader/BufferedWriter提供字符缓冲支持readLine包在InputStreamReader外面使用套娃时关闭流也有讲究。我的经验是只需要关闭最外层流即可。因为BufferedInputStream.close()会调用底层InputStream.close()一层层传递下去。用try-with-resources声明多个流时JVM会按声明顺序的逆序自动关闭所以不会出现“内层关了外层还在写”的问题。但有一个例外System.in、System.out、System.err这三朵金花不要随便关闭。一旦关闭整个JVM进程的标准输入输出就被关了很多日志和调试信息会直接消失而且想重开都开不回来。2.3 字符编码BIO流里最隐形的坑提到字符流就绕不开编码。很多人用FileReader读文本文件平时本机运行好好的换到服务器上就乱码。原因就在于FileReader的构造方法没有指定字符集它用的是JVM默认字符集。在Windows中文系统上默认可能是GBK在Linux服务器上默认可能是UTF-8同样的代码在不同环境里跑出不同结果。正确的做法是绕过FileReader直接用InputStreamReader并显式指定字符集try (BufferedReader reader new BufferedReader( new InputStreamReader( new FileInputStream(config.txt), StandardCharsets.UTF_8))) { String line; while ((line reader.readLine()) ! null) { System.out.println(line); } }写文件也是一样不要用FileWriter用OutputStreamWriter指定字符集try (BufferedWriter writer new BufferedWriter( new OutputStreamWriter( new FileOutputStream(output.txt), StandardCharsets.UTF_8))) { writer.write(中文内容); }为什么这个坑这么隐蔽因为大多数情况下项目在开发和测试环境用的都是同样的操作系统默认字符集一致问题不会暴露。一旦部署到不同环境的机器上乱码就出现了。而且乱码往往不是立刻报错而是写入文件后内容变了后面别的系统再读这个文件时各种解析都跟着错。我的习惯是所有读写文本文件的地方一律显式指定StandardCharsets.UTF_8。宁可多写几行也不要依赖JVM环境。3. 阻塞是BIO的命门原理与一次真实阻塞事故3.1 阻塞到底阻塞在哪儿BIO最核心的特征就是阻塞但很多人说不清“阻塞在哪个方法”。以最常见的文件读取为例当你调用InputStream.read()时如果数据还没有完全到达线程就会进入等待状态。什么叫进入等待状态就是线程被操作系统挂起不占用CPU直到数据可用才被唤醒。这不是忙等是真正的让出CPU。网络编程里的阻塞更明显。先看一个最简单的ServerSocket服务端ServerSocket server new ServerSocket(8080); while (true) { Socket socket server.accept(); // 阻塞在这里直到有客户端连接 handle(socket); }accept()会一直等待客户端连接没有连接时当前线程就停在那里。如果有两个客户端几乎同时发起连接第一个连接被accept()接收后程序开始处理第一个连接的读写在读完第一个连接的数据之前第二个连接只能在操作系统的连接队列里排队因为单线程模型下accept()还没有被再次调用。再比如Socket.getInputStream().read()如果客户端迟迟不发送数据服务端就会一直阻塞在read()。如果你是单线程处理多个连接那一个不活跃的连接就能拖住所有后续连接的请求这就是传说中的“假死”。阻塞用生活场景解释就是你去银行柜台办业务取了号之后什么都不能干一直等到叫号你才能过去。银行柜台比作一个线程你比作一次IO请求排队等待的时间就是阻塞时间。如果只有一个柜台后面所有人就只能干瞪眼。既然阻塞这么不友好为什么BIO还能活到今天因为它简单。阻塞模式下你可以用一种很自然的同步思维方式写代码先做A再做B数据没到我就等。你不需要考虑数据分批到达、半包粘包的问题一切交给底层。3.2 我遇到的一次“假死”事故几年前我维护过一个内部设备上报系统设备通过Socket连上来不断发送心跳和业务数据。服务端用的是最朴素的BIO模型每来一个连接就开一个线程线程里循环读数据。看上去很稳妥直到某天生产环境突然出现一批“无响应”的连接。排查的时候我打开线程栈发现大量线程都停在SocketInputStream.read()上。第一反应是设备没发数据但奇怪的是这些连接是刚建立的按理说设备连接成功后应该立刻发登录报文。后来仔细看设备端的日志发现设备在等待服务端的响应。原来是服务端处理登录报文的流程里又调用了一次read()想继续读“后续数据”但设备这边根本没打算再发东西。两边都在等对方于是连接就僵住了。修复方案很简单给Socket读操作加超时时间同时把协议改成明确的消息边界。代码是这样改的socket.setSoTimeout(3000); try (InputStream in socket.getInputStream(); BufferedReader reader new BufferedReader(new InputStreamReader(in, StandardCharsets.UTF_8))) { String line; while ((line reader.readLine()) ! null) { if (LOGIN.equals(line)) { // 处理登录回写响应 writer.write(LOGIN_OK\n); writer.flush(); } } } catch (SocketTimeoutException e) { // 3秒没读到数据说明对方可能异常了 socket.close(); }这里面有几个关键点。第一setSoTimeout(3000)只影响读操作设置的是“读数据时最多等多久”单位是毫秒。如果超时read()会抛出SocketTimeoutException。注意区分connectTimeout那是建立连接时的超时不是读超时。第二readLine()必须读到换行符\n或\r\n才返回。如果设备端发送数据时没有以换行符结尾readLine()就会一直等下去。所以协议设计时必须约定好消息结束标志要么用换行要么用固定长度头要么用类似HTTP那样的空白行分隔。第三捕获SocketTimeoutException之后并不一定要关闭整个Socket。如果协议允许重发你可以继续循环读但如果超时频繁出现多半说明对方已经失联及时关掉连接释放线程资源才是更稳妥的做法。这次事故让我养成了一个习惯只要在BIO网络代码里看到read()脑子里马上就会跳出三个问题——有没有超时有没有消息边界有没有可能两边互等这三个问题不解决BIO的网络代码迟早出事。3.3 BIO为什么适合连接数少的场景既然BIO阻塞这么麻烦为什么传统上还要用“一个连接一个线程”的模型因为对于连接数很少的场景这是最简单的方案。每连接一线程的写法核心就是一个while循环加一个new ThreadServerSocket server new ServerSocket(8080); while (true) { Socket socket server.accept(); new Thread(() - handleRequest(socket)).start(); }每个连接都有自己独立的线程线程阻塞在read()上不会影响其他连接。代码逻辑完全是顺序式的出问题容易定位也容易维护。这种方式在小工具、内部服务、管理后台等场景下完全够用。但它的缺点也很突出线程是昂贵的资源。一个线程默认栈大小可能就有512KB或1MB创建1000个线程就占掉1GB内存更不用说大量线程阻塞时操作系统还要不停地做线程上下文切换。当连接数上到几千、几万这种模型就崩了。这就是所谓的C10K问题也是NIO出现的原因。我用一张表把BIO、NIO、AIO的大致差异列出来方便理解模型线程模型连接数规模开发复杂度典型场景BIO一个连接一个线程低几百左右低文件读写、低并发服务、脚本工具NIO一个线程管理多个连接多路复用高几千到十万中网关、IM、聊天室、代理服务AIO异步回调事件完成后再处理很高高高性能IO框架实际使用较少注意这张表不是绝对标准只是帮助判断。BIO并不是“落后”的代名词而是“简单可靠”的选择。在你确定连接数不会爆炸之前用BIO完全合理。4. 把BIO写出花来缓冲、编码和工具类使用技巧4.1 缓冲类别忽略一次读一行这个“大杀器”在BIO流里BufferedReader.readLine()可能是被用到最多的方法。它比手写read()循环要优雅得多尤其适合解析配置文件、日志文件和CSV。举个例子我需要读取一个形如keyvalue的配置文件Properties props new Properties(); try (BufferedReader reader new BufferedReader( new InputStreamReader( new FileInputStream(app.properties), StandardCharsets.UTF_8))) { String line; while ((line reader.readLine()) ! null) { if (line.startsWith(#) || line.trim().isEmpty()) { continue; } String[] kv line.split(, 2); if (kv.length 2) { props.put(kv[0].trim(), kv[1].trim()); } } }readLine()有几个重要语义要记住。第一它不包含换行符。也就是说读到的line里没有\n也没有\r\n。第二文件最后一行如果没有换行符一样能读出来。第三读到文件末尾时返回null循环条件就用! null判断。很多人踩过坑用readLine()读一个没有换行符的大文件最后一行不输出或者在line里试图用contains(\n)判断是否是同一行永远得不到预期结果。记住它已经帮你去掉换行符你就不会写出这种代码了。如果你要处理的数据不是按行分隔的readLine()就不适用了。比如读一个JSON文件JSON本身允许有换行但你可能是想要整个文件内容这时候应该一次性读取StringBuilder sb new StringBuilder(); try (Reader reader new InputStreamReader(new FileInputStream(data.json), StandardCharsets.UTF_8)) { char[] buffer new char[4096]; int len; while ((len reader.read(buffer)) ! -1) { sb.append(buffer, 0, len); } }注意这里的read(char[])返回的是读到的字符数同样要用len截取避免把上次填充的多余字符拼进去。这个坑和前面字节流复制是同一个道理只是从byte换成了char。4.2 流操作中的强制刷新与关闭策略接下来要说的是flush()。很多新手不理解为什么明明写了writer.write(...)但文件里就是没内容。十有八九是忘了flush()。BufferedWriter和PrintStream这类带缓冲的流会把要写的数据先暂存在内存缓冲区里等缓冲区满了或者流关闭时才真正落到磁盘/网络。如果你只调用write()不调用flush()数据可能一直堆在缓冲区里。尤其在网络编程中服务端写完响应后如果不flush()客户端就永远等不到响应。正确的习惯是在写完一个完整的逻辑块后立即flush()writer.write(HTTP/1.1 200 OK\r\n); writer.write(Content-Length: 0\r\n); writer.write(\r\n); writer.flush();这里还有一个细节close()会自动触发flush()。所以如果你马上要关闭流可以不显式调flush()。但如果你还需要保留流继续做后面的操作那就一定要flush()。有些人在一个会话里多次write()最后忘了flush()直到连接关闭才发送会导致业务逻辑出现“消息延迟发送”的假象。关闭策略上我的建议就是无脑用try-with-resources。它会在代码块结束时自动关闭声明过的流关闭顺序也处理好了。但要注意如果你在一个try块里同时声明BufferedWriter和它内部的FileOutputStream两个流都会被关闭内层被关闭两次也没问题。唯一要提醒的是System.in、System.out、System.err不要放在try-with-resources里声明。一旦try块结束标准输入输出就被关了整个进程的日志全没了后患无穷。4.3 对象流与Data流跨语言别乱用BIO流里还有两个“高级玩具”ObjectInputStream/ObjectOutputStream和DataInputStream/DataOutputStream。DataInputStream适合读写结构固定的二进制数据。比如一个协议头前面4字节表示数据长度后面跟着2字节的命令字就可以用readInt()和readShort()依次读出来。读写顺序必须一致先写什么后读什么不能乱。写法如下try (DataOutputStream dos new DataOutputStream( new BufferedOutputStream(new FileOutputStream(record.bin)))) { dos.writeInt(12345); dos.writeUTF(你好); dos.writeDouble(99.99); }对应的读取try (DataInputStream dis new DataInputStream( new BufferedInputStream(new FileInputStream(record.bin)))) { int id dis.readInt(); String name dis.readUTF(); double score dis.readDouble(); }ObjectOutputStream则可以直接把对象整体序列化成字节流省去手动拼字段的麻烦。但代价是三个条件缺一不可对象类要实现java.io.Serializable要留意serialVersionUID否则修改类结构后反序列化会报InvalidClassException序列化格式是Java私有协议不能指望其他语言能直接解析。另外有一个安全建议永远不要反序列化来自不可信来源的数据。ObjectInputStream在反序列化时会调用对象的readObject()如果数据被人恶意构造可能触发整条攻击链。这不是危言耸听现代Java安全指南里都明确警告过。如果你的系统必须接收外部传来的对象字节流尽量改用JSON或Protobuf这类文本/自描述格式。我在实际开发中很少用ObjectOutputStream做长期存储或跨系统传输因为一旦类结构调整旧数据就废了。反而是DataOutputStream在自定义协议里出现频率更高因为它可控性强字段顺序、字节长度、编码方式都由我决定。5. BIO、NIO、AIO怎么选面试和实战的判断标准5.1 面试官问BIO时到底想问什么Java面试中IO模型几乎是必考题。面试官问“讲讲BIO”一般不是真让你背类名而是想确认你是否理解同步、阻塞、线程模型这些基础概念。最常见的连环问题是BIO、NIO、AIO有什么区别BIO的阻塞体现在哪里为什么有了BIO还需要NIO你们项目里用的IO模型是什么为什么选它回答BIO和NIO的区别时不要只背“BIO是阻塞IONIO是非阻塞IO”这种一句话结论。你至少要能说出BIO中InputStream.read()和ServerSocket.accept()都是阻塞调用线程在数据到达前会被挂起NIO引入了Channel和Selector一个线程可以通过Selector.select()监听多个Channel当一个Channel的读事件就绪时才去处理这样少量线程就能管理大量连接。同时要能承认BIO的适用场景并发连接不高时BIO的代码更直观排错更容易没必要强行上NIO。面试官听到你能讲清边界反而会认为你有真实项目经验而不是背题。如果面试官再深挖可能会问NIO里的零拷贝、ByteBuffer、Selector实现Linux的epoll那就属于进阶话题了。但回答的前提仍然是先把BIO的阻塞原理说透。5.2 实战选型什么时候继续用BIO我见过太多团队一上来就选Netty结果业务量一天不到几万个请求最后系统复杂度上去了问题排查也难了。所以选型这件事最该考虑的是你的真实并发模型。以下几种情况BIO完全够用甚至更合适程序要读写本地文件比如日志、配置、导入导出这些本质上就是BIO流操作跟NIO没多大关系。内网低并发的接口服务比如管理后台、设备采集小工具连接数几十到几百用简单线程池接BIO Socket就够了。一次性脚本、离线任务处理完就退出根本不需要长时间驻留。标准输入输出交互比如命令行工具BIO就是不二选择。需要上NIO或Netty的场景通常有这些特征海量长连接、高吞吐、低延迟要求、需要同时处理几千甚至几万个连接。典型的如即时通讯、消息推送、API网关。AIO虽然概念华丽但实际项目里用得比较少因为复杂性高而且很多场景下NIO配合线程池已经能解决。还有一个折中方案用BIO Socket加业务线程池。主线程负责accept()把Socket丢给线程池处理。这样至少避免了“一个连接一个线程”的无限增长问题。线程池大小根据CPU核数和IO等待时间调整能支撑的并发量比纯BIO高出不少。我个人的经验是先画出你的连接数曲线再确定模型。如果预估峰值不到几百BIO加线程池足够如果峰值会到几千直接考虑Netty。不要为了简历上写一行“精通NIO”就过度设计。最后再分享一个小感受很多复杂的网络框架底层虽然是非阻塞的但你在业务代码里用到的很多API还是带有BIO的影子。把BIO流吃透再去看NIO和Netty会顺很多。连阻塞都没理解清楚谈非阻塞就是空中楼阁。这也是我建议每个Java开发者都回头认真看一遍BIO流的原因。