1. IO 流为什么是Java面试和实战的重灾区我在做技术评审和面试候选人的时候几乎每次都会碰到IO相关的讨论。很多候选人能把ArrayList和HashMap的源码讲得头头是道但一问到IO就露馅了——字节流和字符流的区别说不清楚NIO和BIO的应用场景答不上来项目里IO性能下降了也不知道从哪里开始排查。这不是个例而是普遍现象。Java的IO体系确实有它的特殊性。它不像synchronized或者volatile那样记住几个关键字就能应付面试也不像Spring那样会用注解就能干活。IO是一个完整的体系从最基础的FileInputStream到高并发的NIO从字节到字符再到对象序列化每一层都有自己独立的抽象和实现而且这些抽象之间还有复杂的装饰与被装饰的关系。更重要的是IO是实际项目中无论如何都绕不开的部分——日志要写文件接口要传数据服务之间要通信这些都建立在IO之上。所以这篇东西我打算把这套体系从头到尾捋一遍。不是为了写教科书而是以一个用了十几年Java的老开发的身份把我的理解、踩过的坑、还有实际项目里用得上的经验都放进来。不管你是刚学Java的应届生还是写了几年业务代码想补基础的开发或者是准备面试想系统过一遍IO知识点的求职者这篇都可以作为一份比较完整的参考。先说一个我自己的判断很多人在IO上栽跟头不是因为Java的IO难而是因为他们把IO当成了一堆零散的类去背而没有理解IO在整个Java技术栈中的定位。Java的IO不是一组API而是一套围绕“数据流动”设计的分层抽象体系。理解了这条主线所有细节都变得有迹可循。2. 从BIO到NIO再到AIO三条IO路线的本质差异2.1 传统的BIO到底慢在哪里BIO全称Blocking IO同步阻塞式IO。从JDK 1.0开始就有了也是大多数Java开发者最早接触的IO方式。BIO的工作模式用一句话概括线程发起IO操作后在该操作返回之前线程一直处于阻塞状态。你写一个socket.read()如果数据没到线程就挂在那里等。这种模型在早期的互联网时代没什么问题因为那个时候并发量低一台服务器同时服务几十个连接已经算不错了。但在高并发场景下BIO的缺陷就暴露了一个连接对应一个线程而线程是宝贵的资源。1000个并发连接就需要1000个线程每个线程默认栈大小1MB光是线程栈就要吃掉1GB内存再加上线程切换的开销系统很快就扛不住了。我自己在实际项目中曾经遇到过这样的情况一个老系统用的是BIO模式的Socket通信平时几十个连接的时候一切正常一旦搞活动流量上来连接数涨到几百个系统就开始频繁Full GC接口响应从几十毫秒暴涨到几秒。后来排查下来问题就出在大量线程阻塞在read()调用上线程状态一直停在WAITINGCPU虽然不高但内存和线程调度已经被拖垮了。BIO的核心问题本质上只有一个它在等待IO事件时白白占用了线程。而线程的创建和切换成本都很高所以BIO无法支撑大规模并发连接。2.2 NIO的IO多路复用一个线程盯着一堆连接NIONon-blocking IO从JDK 1.4开始引入。它和BIO最大的区别在于IO操作不再阻塞线程而是通过Selector选择器来管理多个Channel通道的事件。NIO的三个核心组件是Buffer缓冲区、Channel通道、Selector选择器。这三者的配合方式是数据从Channel读入Buffer或者从Buffer写入Channel。而Selector负责监控多个Channel的状态当某个Channel有数据可读或者可以写入时Selector会通知对应的线程去处理。打个比方可能更容易理解BIO就像你去银行办业务每个窗口配一个柜员你排在哪个窗口那个柜员就只服务你一个人你站着不动柜员也得等着你。而NIO就像一个大堂经理他同时盯着所有窗口哪个窗口的客户填完单子了他就叫对应的柜员过去处理一个柜员可以轮流服务所有窗口。IO多路复用带来的直接收益就是一个线程可以同时管理成千上万个连接。这在Netty、Tomcat的NIO模式下都得到了充分验证。我在生产环境维护过一个基于Netty的网关服务单机维持了大概两万个长连接线程数只开了几个worker线程CPU和内存都处于健康状态。这在BIO模型里是不可想象的。需要特别说明的是NIO的“非阻塞”指的是IO操作本身不阻塞调用线程而Selector的select()方法在没有事件时也会阻塞但这在一定意义上是一种“高效阻塞”——线程不是在空等某个连接的IO而是在等待“有哪些连接发生了IO事件”这个粒度完全不同。2.3 AIO异步IO的课代表但实际用的人不多AIOAsynchronous IOJDK 1.7引入。它的特点是真正的异步非阻塞发起IO操作后立即返回操作系统在后台完成数据拷贝完成后通过回调通知应用程序。从理论上讲AIO比NIO更先进因为它连“等待事件通知”这一步都省了。但在实际Java生态里AIO用得远不如NIO广泛。原因有几个一是很多操作系统对AIO的原生支持不够好特别是Windows和部分Linux版本的兼容性存在问题二是成熟的网络框架如Netty基于NIO已经做得足够好且NIO在Linux上可以通过epoll达到非常高的性能AIO的收益并不明显三是AIO的编程模型相对复杂回调地狱的问题对代码可维护性是个考验。所以我的建议是理解AIO的原理但项目选型时优先考虑基于NIO的框架Netty、Vert.x等这更符合当前Java社区的主流实践。2.4 三个层级的选型标准怎么定这里给一个比较实用的选型参考表场景推荐IO模型理由连接数少、逻辑简单如内部管理系统连接数据库BIO编码简单不需要引入额外的框架性能足够高并发网络服务如RPC框架、API网关、IM服务NIO最好基于Netty单线程管理大量连接资源占用低成熟方案多大量文件读写操作如日志收集、文件传输服务AIO或NIO零拷贝降低线程等待时间提升吞吐量低延迟、高频交互如交易系统NIO自定义协议可控性强便于针对业务做精细化调优我遇到过不少团队一上来就引入Netty结果业务逻辑其实只是简单的HTTP转发性能没有瓶颈却把系统的复杂度大大提高。IO选型的第一原则是匹配场景不是追求技术新。3. 字节流与字符流不止是编码问题那么简单3.1 为什么Java要分两套流体系字节流InputStream/OutputStream和字符流Reader/Writer是Java IO基础中的基础。很多初学者只记住了“字节流读字节字符流读字符”这句话但没有想过Java为什么要做这个区分。底层逻辑是这样的计算机存储和处理数据的最小单位是字节所以所有的IO操作最终都是字节操作。但人类阅读和编辑的数据是字符而字符和字节之间隔着一道编码的墙。同一个字符在UTF-8、GBK、ISO-8859-1这些编码下对应的字节数是不同的。如果直接用字节流去读取文本文件然后拼接成字符串你必须自己处理编码转换的细节非常容易出错而且代码会很难看。于是Java提供了字符流这个更高层的抽象。字符流内部持有编码器/解码器在读入字节流之后自动完成字节到字符的转换。这样业务代码只需要关心“我读到了一个字符串”而不需要关心底层字节是怎么排列的。3.2 桥接的关键角色InputStreamReader 和 OutputStreamWriter字符流和字节流之间不是割裂的而是通过InputStreamReader和OutputStreamWriter这两个“桥接类”连接起来的。这里有一个高频面试题“System.in是字节流还是字符流”System.in的本质是InputStream字节流。如果你要读取用户在控制台输入的字符串直接读System.in拿到的是一串字节需要自己做编码转换。正确的做法是用InputStreamReader包装System.in再包一层BufferedReader。我之前面试过不少候选人能答上来这一步的屈指可数。顺便提一个实际项目里的经验在做文件编码转换工具的时候我经常用InputStreamReader读和OutputStreamWriter写配合指定字符集完成转码。比如把GBK编码的文件转成UTF-8核心逻辑就是读取时指定GBK写入时指定UTF-8。如果不指定字符集程序会使用JVM默认字符集这在部署环境之间的差异会导致很难排查的乱码问题。所以我强烈建议代码里涉及字符流的地方显式指定Charset永远不要依赖默认值。3.3 装饰器模式在IO体系中的极致运用Java的IO类库是把装饰器模式用到极致的典范。BufferedInputStream和FileInputStream的关系本质上是“装饰者”和“被装饰者”的关系。装饰器模式的核心思想是通过一层一层地包装给基础组件动态增加功能。IO体系里的典型例子// 不带缓冲每次读一个字节都发生一次系统调用 FileInputStream fis new FileInputStream(test.txt); // 带缓冲内部维护8KB缓冲区批量读取减少系统调用次数 BufferedInputStream bis new BufferedInputStream(fis); // 再包装一层提供readLine能力 BufferedReader br new BufferedReader(new InputStreamReader(bis));每一层包装都只负责一件事FileInputStream负责从文件读取原始字节InputStreamReader负责把字节解码成字符BufferedReader负责在内存中缓冲数据减少实际IO次数。这种组合方式让Java的IO在使用上非常灵活也让代码“丑”得很有特色——那一串串嵌套的new确实是IO常见的画风。但这里有个巨大的坑流的关闭顺序和关闭方式直接关系到数据完整性。很多人写完代码只关最外层流这在大多数场景下没问题因为关闭外层流时内部会级联关闭内层流。但如果手动对流做了多次包装又分别在多个方法里持有不同层的引用关闭不当就会造成文件句柄泄漏。我的经验是永远只用try-with-resources语句并且在try块中只声明最外层流。JDK 7之后的try-with-resources会自动调用close()不仅代码更干净还能保证异常路径下流也能被正确关闭。try (BufferedReader br new BufferedReader(new InputStreamReader(new FileInputStream(test.txt), StandardCharsets.UTF_8))) { String line; while ((line br.readLine()) ! null) { System.out.println(line); } } catch (IOException e) { // 处理IOException }注意这里有个隐藏细节如果显式声明了两个资源内层流和外层流分别声明那么关闭顺序是逆序的——后声明的先关先声明的后关这在某些极端情况下比如内层流已经关闭外层流的close()又尝试操作内层流会抛出异常。所以只声明最外层流是最稳妥的方式。3.4 不要忽略flush和缓冲区的关系字符流、缓冲流底层都有缓冲区。当你调用write()时数据不一定会立刻写入磁盘或网络而是先写到缓冲区等缓冲区满了或者手动调用flush()时才真正写出。常见的FileWriter、BufferedWriter都有这个问题。我之前写一个数据导出功能时循环往文件里写十万行数据写完一时疏忽没有调用flush()就提前把程序结束了结果发现文件里最后几千行数据丢失了。原因是程序正常退出时缓冲数据没有来得及全部落到磁盘。所以凡是用了缓冲流逻辑处理完、流关闭前确认flush()被调用。try-with-resources会自动flush然后close但如果你的业务场景需要实时可见性比如写日志、写监控数据就要在关键节点手动flush()而不是等缓冲区满。4. NIO核心机制里的性能密码Buffer、Channel与Selector4.1 BufferNIO的数据容器和它的四个指针Buffer是NIO中最基础的组件本质上是一个内存数组但这个数组的读写机制有一套独特的状态管理方式。Buffer内部维护了四个核心指针position当前位置、limit可读写的上限、capacity容量、mark标记位。读写模式的切换需要通过flip()方法实现这可能是NIO入门者最容易理解错的地方。// 写入模式 ByteBuffer buffer ByteBuffer.allocate(1024); buffer.put(hello.getBytes()); // 切换为读模式limitpositionposition0 buffer.flip(); byte[] dst new byte[buffer.limit()]; buffer.get(dst); // 切换为写模式positionlimitlimitcapacity buffer.clear();flip()的本质是把limit设置为当前position标记有效数据的边界把position重置为0从开头开始读。这在IO开发里是高频操作很多线上Bug都是因为忘了调用flip()直接get()导致读到一堆空数据。还有一个常见的坑是Buffer的复用。在对ByteBuffer复用的时候用clear()会重置position和limit但不会清空数据用compact()则会把未读的数据移动到头部然后把position设为未读数据的末尾。在下一次写入的时候新数据会接在旧数据后面。如果你不理解clear()和compact()的区别在高性能场景下很容易出现数据错乱。4.2 Channel与零拷贝文件传输性能提升的关键Channel是NIO中另一个重要概念可以理解为连接IO设备的“管道”。和传统IO的Stream相比Channel是双向的既可以读也可以写而且支持一些非常实用的操作比如transferTo和transferFrom。这两个方法背后是操作系统级的“零拷贝”机制。传统的数据拷贝流程是磁盘 - 内核缓冲区 - 用户缓冲区 - 内核缓冲区 - Socket缓冲区 - 网络。中间经历了多次上下文切换和数据拷贝。而transferTo方法可以让数据直接从磁盘文件传输到网络Socket绕过用户空间由操作系统在内核态完成数据拷贝。实际写过文件下载服务的同学应该有体会如果用传统的InputStreamOutputStream去实现文件下载一个100MB的文件要经过反复的read和writeCPU开销和GC压力都不小。而用FileChannel.transferTo实现同等的功能代码量更少性能还能提升不少。我自己做过对比同样的文件大小传统方式CPU占用大约能到40%-60%的核transferTo方式能降到10%以下。try (FileChannel fileChannel FileChannel.open(Paths.get(bigfile.zip), StandardOpenOption.READ); SocketChannel socketChannel SocketChannel.open(new InetSocketAddress(127.0.0.1, 8080))) { fileChannel.transferTo(0, fileChannel.size(), socketChannel); }两句代码解决文件传输这就是零拷贝的威力。4.3 Selector处理高并发的关键点如何设计事件循环Selector配合Channel是NIO网络编程的核心模式Netty的底层也是围绕这套机制构建的。Selector的工作逻辑是向Selector注册感兴趣的IO事件OP_ACCEPT、OP_READ、OP_WRITE等然后调用select()等待事件发生一旦有事件到达通过selectedKeys()获取到对应的SelectionKey集合再逐个处理。这里有一个非常容易被忽视的性能问题处理完一个SelectionKey的事件后必须调用Iterator的remove()方法把它从selectedKeys中移除。如果不移除下一次select()返回时这个已经处理过的key还会继续存在导致重复处理。Netty在底层已经帮你处理了这些细节但如果你直接使用原生NIO这个Bug几乎是新手必踩。还有一点是关于注册OP_WRITE事件。很多人优化性能时习惯在channel可写的时候注册OP_WRITE事件然后处理完写操作后忘记取消注册。这样就导致了一个后果当channel一直可写时Selector会不断触发OP_WRITE事件造成忙轮询CPU占用率飙升。我见过一个真实案例某团队的网关服务CPU飙升到100%排查了半天最后发现就是OP_WRITE事件没有注销导致的死循环。正确的做法是写数据时直接调用write()方法只有在写不完write返回0或者部分写入时才注册OP_WRITE事件写完之后立刻取消注册。Selector还有一个细节是spurious wakeup虚假唤醒也就是select()在没有真实事件的情况下返回了。所以主循环里必须通过selectedKeys()来确认哪些key真正有事件不能拿了返回的int值就直接断言有事件。5. Java序列化把对象变成字节再把字节变回对象5.1 Serializable的工作原理以及为什么需要serialVersionUIDJava序列化是通过java.io.Serializable接口来支持的。这个接口里面没有任何方法纯粹是一个标记接口JVM看到类实现了这个接口就允许通过ObjectOutputStream/ObjectInputStream把对象转换成字节流或从字节流还原成对象。序列化过程中有一个极其重要的东西就是serialVersionUID。它相当于这个类的“版本指纹”。反序列化的时候JVM会拿当前类的serialVersionUID和字节流中记录的serialVersionUID做比较不一致就抛InvalidClassException。我在公司里处理过太多因为serialVersionUID不一致导致的线上故障了。典型场景是开发同学给某个类加了一个字段然后没有手动声明serialVersionUIDJVM根据类结构自动生成了一个和线上已有的序列化数据不匹配结果消费者反序列化的时候直接报错。解决方案从一开始就很简单所有实现Serializable的类都显式声明一个固定的serialVersionUID。加字段删字段都不会影响反序列化只要类型兼容就行。public class User implements Serializable { private static final long serialVersionUID 1L; private String name; private int age; }5.2 transient和敏感字段的处理方式序列化时如果某个字段不想被序列化比如密码、令牌等敏感信息或者某些可以在反序列化时重新计算得到的派生字段就把它标记为transient。不过要注意transient字段在反序列化后会保持Java默认值引用类型是null基本类型是0/false。如果你的业务逻辑依赖这些字段必须在反序列化后被正确初始化就需要在readObject()方法里做额外处理。我在一个用户服务里就踩过这个坑。当时把用户的session缓存标记成transient想着不需要序列化反序列化后再从数据库里重新加载。结果反序列化后忘了重新初始化代码里一用这个session就报错排查了很久才定位到是transient字段没有重新赋值。5.3 性能对比Java原生序列化 vs 手动序列化这里说个实际数据。我曾经测过一个Java原生序列化ObjectOutputStream写一个简单POJO的性能在大对象、高频调用的场景下原生序列化的吞吐量明显低于用ByteBuffer手动拼接的方案而且产生的字节流体积大不少。原因是Java原生序列化会把类的完整描述信息类名、字段名、字段类型等都写进去导致序列化结果很臃肿。所以现在RPC框架普遍不用Java原生序列化而是用Protobuf、Kryo、Hessian这些更高效的方案。但掌握Java原生序列化仍然是必要的因为很多基础组件如Redis客户端默认的JDK序列化、某些消息中间件的默认配置还在用它。理解原生序列化的原理能帮你判断什么时候该替换、什么时候可以继续用。5.4 为什么反序列化有安全风险Java反序列化有个著名的安全问题反序列化时会调用对象的readObject()方法而这个方法可能在内部执行各种操作。攻击者构造恶意的字节流可以触发一系列巧妙的调用链最终实现任意代码执行。这就是历史上多个重量级漏洞如Commons Collections链等的根本原因。日常项目中我的建议是反序列化时只处理自己信任的数据源。如果用了ObjectInputStream建议重写resolveClass()方法增加白名单校验只允许反序列化预期内的类。现代框架尽量避免直接用Java原生反序列化优先选择JSON、Protobuf这些基于明确定义格式的方案。6. 从“IO性能下降”说起一次完整的排查链路复盘我在这篇里专门把线上IO性能排查单独拉出来讲因为热搜词里反复出现“io性能明显下降了”“socket read timed out!”这简直是生产环境的两大常客。我复盘一个真实的排查过程完整展示从现象到根因的思路这个思路比具体问题更值钱。现象是这样的某服务在业务高峰期接口P99从80ms涨到1200ms观察监控大盘指标里有一个很显眼的“Socket read timeout”异常带有前缀java.sql.SQLException: IO Error。第一反应是查数据库。平台DBA先看数据库负载CPU没有明显瓶颈慢查询也没有新增连接池监控显示活跃连接一直在正常范围。所以数据库本身没病。再看应用日志发现报错的IP分布在多台机器上但都集中在某一个区域。继续深挖发现这些机器的出方向网络有大量TCP重传。联系网络团队确认机器之间的物理链路存在丢包丢包率在0.1%左右。这个数字听起来很小但在这个场景下是致命的——每一次重传都会增加几十到几百毫秒的延迟最终导致JDBC的socket read等待超时。根因清楚了应用层的SQL没问题数据库也没问题问题出在两台服务之间的网络传输层数据包在网络里反复重传IO等待被无限拉长。排查链路如果用一句话总结那是“先看连接资源连接池、线程再看目标端数据库状态最后查网络链路。”IO性能下降绝大多数都围绕这三层展开按顺序排查避免在错误的层级浪费大量时间。再补充一个IO排查的高频工具清单连接数ss -s、netstat句柄数lsof | wc -l文件句柄泄漏排查I/O等待iostat -x 1看util%util大于80%基本可以断定磁盘IO饱和GC日志确认GC是否频繁触发因为GC的STW也会间接导致IO线程阻塞在跑Java应用的时候我会特别关注一下JVM到操作系统之间的文件句柄上限。默认情况下Linux对单进程的文件句柄数有限制通常1024如果程序打开的文件、Socket超过这个数就会抛出“Too many open files”。排查IO问题时第一件事先看这个比看Java代码高效得多。7. 网络通信中的IO超时与连接管理细节决定稳定性7.1 Socket超时connect超时、read超时的正确设置原则Java网络编程中Socket有三个重要的超时参数需要区分参数设置方式作用connect超时new Socket()传入超时参数建立TCP连接最多等待多久read超时socket.setSoTimeout()读取数据时等待数据到达的时间上限写超时无专用参数由操作系统TCP缓冲区决定通常表现为阻塞很多开发者在写HTTP Client或者手动创建Socket时只设置了connect超时没有设置read超时。这样会导致一种情况连接建立得很顺利但对方迟迟不返回数据线程一直阻塞在read()上。我之前经历过一个事故底层的某个上游服务假死进程还在但不再响应我们的服务线程全部卡在read()上连接池被耗尽最终整个应用不可用。如果当时设置了合理的read超时最坏情况下也只是个别请求失败不会拖垮整个应用。生产环境的经验值是同一个网络链路里read超时一般设置为connect超时的2-3倍。connect超时常见设置3-5秒read超时设置在5-15秒区间。具体值要根据业务耗时来调整核心原则是“必须设置且不能过大”。7.2 连接池的IO优化视角很多人把连接池当成数据库专属概念其实IO密集型的网络通信都涉及连接池。道理很简单建立TCP连接需要三次握手销毁连接需要四次挥手这两个操作都会消耗时间和资源。连接池的作用就是把这些连接的创建和销毁从请求关键路径上剥离出去让请求直接复用已建立的连接。在连接池配置里和IO性能最相关的两个参数是最大连接数和空闲超时。最大连接数太小请求会排队等待太大数据库或下游服务可能被打挂。空闲超时决定了一个连接多久不用就回收设置过大会导致闲置连接占用资源设置过小会让连接频繁创建销毁。我比较推荐的做法是新建连接时主动做一次探活比如所有连接创建后都执行一次轻量级查询同时定期对空闲连接做有效性校验保证从池里拿出来的连接是“即拿即用”的。网络环境不稳定时这个策略能避免大量“拿到连接发现已经死了”的无效IO。7.3 长连接与心跳机制长连接在NIO和Netty的应用中是不可或缺的。但长连接有一个问题如果链路中间的网络设备比如负载均衡、防火墙认为连接空闲会在没有数据传输时回收该连接。而应用层并不知道连接已经被回收下次发送数据时会报“Connection reset”或“Broken pipe”。解决这个问题的标准做法是心跳。心跳的本质是应用层定期发送极小的协议包PING/PONG让网络设备认为连接还在活跃。心跳的间隔要合理太长会触发网络设备回收太短会浪费带宽。常见设置在30-60秒一次。我之前在某个物联网项目中写过心跳逻辑采集终端通过长连接上报数据中间经过运营商的NAT网关NAT表项的超时时间很短大概两分钟。如果不发心跳终端每隔几分钟就会被网关踢掉导致大量重连。加了心跳之后连接稳定率从不到90%提升到了99.9%以上。8. 键盘输入、文件读写与控制台那些“最小示例”里的大坑8.1 System.in为什么不能直接用回到前面提到的System.in。看一下它处理用户输入的标准姿势BufferedReader br new BufferedReader(new InputStreamReader(System.in, StandardCharsets.UTF_8)); String line br.readLine();不直接用System.in.read()的原因有三点编码不可控默认平台编码、没有缓冲、读取单位不对字节而非字符。控制台输入这种看似简单的功能在窗口环境下其编码在不同操作系统之间差异很大Windows的GBK和Linux的UTF-8就是最常见的坑。在Windows上如果System.in不指定编码读取中文时极大概率会出现乱码。因为Windows控制台的默认编码通常不是UTF-8。正确做法上面写了显式指定StandardCharsets.UTF_8或你确定控制台使用的编码。8.2 Scanner和BufferReader怎么选这是个很经典的对比。Scanner的优势是提供方便的APInextInt()、nextLine()直接解析数据类型。缺点是nextLine()和nextInt()混用时有“换行符残留”问题而且性能比BufferedReader差一些。BufferedReader的优势是性能好readLine()语义清晰但所有类型的解析都要自己完成字符串转int等。我的建议是算法竞赛或简单的控制台程序用BufferedReader手动解析业务代码里如果有复杂的格式化输入需求用Scanner但要注意换行符的问题。两者没有绝对的优劣看场景。8.3 文件内容读取一次性读完还是逐行处理这个选择很容易被忽略但直接影响内存和性能。文件很小几MB以内一次性读完没问题byte[] bytes Files.readAllBytes(Paths.get(config.json));文件较大几百MB甚至GB级别一次性读入内存会导致GC压力剧增甚至OOM。这种场景下必须改用流式处理逐行读取处理完一行丢弃一行try (StreamString lines Files.lines(Paths.get(huge_log.txt), StandardCharsets.UTF_8)) { lines.filter(line - line.contains(ERROR)).forEach(System.out::println); }Files.lines()底层其实用的就是BufferedReader但它把流式处理封装成了Stream API代码更简洁。注意用try-with-resources包裹否则底层文件句柄会泄漏。9. 向视频推拉流、远程IO接口等场景的延伸思考热搜词里出现了一些看似和Java IO不太直接相关但本质上依赖IO体系的知识点比如视频推拉流、RTSP拉流协议、远程io接口代码编辑、AI情感陪伴小工具流等。简单说一下背后的IO逻辑你会发现万变不离其宗。视频推拉流的核心是数据的持续传输。推流端把视频帧数据编码后通过RTMP或RTSP协议推给流媒体服务器拉流端从服务器拉取数据解码播放。这一过程的底层就是高并发、低延迟的IO。Java生态里做这类方案的并不多通常会用Netty实现RTMP/RTSP协议的自定义编解码层这是Netty的核心能力——自定义协议底层仍然是NIO的EventLoop驱动。远程io接口代码编辑这个关键词本质上是IDE或远程开发工具通过IO通道把本地的编辑操作实时同步到远端服务器类似SSH、WebSocket这些通道底层同样是Socket IO结合协议处理。这些场景的共性在于不管上层的协议多复杂、业务逻辑多花哨最终依赖的都是那几层IO抽象。Java IO学得好不好直接决定了你在这些领域能不能快速上手因为协议解析、数据流处理、连接管理这些地基全靠IO功底支撑。10. 我平时写IO代码的几条铁律和最后的补充最后分享几条我写IO代码时一直遵守的铁律这些不是书上写的是这些年从生产环境的坑里爬出来的总结。第一条永远显式指定字符编码。代码里不要出现new InputStreamReader(inputStream)这种不指定Charset的写法宁可多打几个字符也不要留下编码隐患。这一个习惯帮我排掉了至少几十次线上乱码问题。第二条流的生命周期管理必须严格使用try-with-resources。不要手动调用close()因为异常路径下很容易漏掉。try-with-resources能保证正常和异常路径都正确释放资源。第三条网络IO必须设置超时包括连接超时和读超时。没有超时的网络调用就是一颗定时炸弹你不知道它什么时候会拖垮整个线程池。第四条操作大文件时一定要时刻关注内存。能用流式处理就绝不用一次readAllBytes能用buffered stream就绝不用原始的每个字节都系统调用。第五条写IO相关代码时刻意思考一个问题“如果这条链路每次都会丢一个包/中断一次我的代码会怎么样”这种思维能帮你提前发现很多稳定性隐患。Java IO这套体系看起来知识点多而杂但只要抓住了“数据从哪里来、到哪里去、中间怎么转换、如何处理等待”这条主线整个体系就像一张图一样清晰地摊开在你面前。学IO不是为了背API而是为了在写代码的时候心里清楚数据的每一次流动在系统层面做了什么、代价是什么、怎么优化。理解了这些无论面试还是实战你都不会再怵IO。