Java流读写分Stream API和NIO ByteBuffer两类：前者防NPE、禁复用、避peek副作用、慎用并行；后者须严格遵循write→flip→read→clear/compact流程，注意容量预估与状态切换。
Java 中“流读写”通常指两类场景：一是 Stream API（集合处理流），二是 NIO 的 ByteBuffer/Channel 流式 I/O。两者都叫“流”，但机制、陷阱和规避方式完全不同。下面分两块说清楚，不混谈、不绕弯。
Stream API 常见读写类陷阱与规避
这里“读写”不是物理 I/O，而是对集合数据的“读取处理 + 写入结果”。常见问题集中在空值、复用、副作用和性能上：
-
空集合 vs 空引用不分：list 为 null 时调用 list.stream() 直接抛 NPE；而空集合（如 new ArrayList<>()）调用 stream() 完全安全。建议统一用 Optional 防御：
List<String> safe = Optional.ofNullable(list).orElseGet(ArrayList::new); - 流只能消费一次：同一个 Stream 对象重复 forEach 或 collect 会触发 IllegalStateException。需要多次遍历时，要么重新创建流（data.stream()），要么先 collect 到 List 再反复用。
- peek 乱改状态：在 peek 里修改对象字段（如 user.setName(...)）破坏函数式原则，并行流下极易出错。应改用 map 构造新对象，或把逻辑移到业务层。
- 误用并行流写共享集合：parallelStream().forEach(list::add) 是危险操作——ArrayList 非线程安全。要收集结果，必须用线程安全容器（如 Collections.synchronizedList）或改用 collect(Collectors.toList())，它内部已做并发保护。
ByteBuffer 读写模式切换陷阱与规避
NIO 中 ByteBuffer 的“读写”是状态驱动的，核心在 position、limit、capacity 三者关系。最典型问题是 flip/clear 用错导致数据覆盖或丢失：
- flip 后未读完就 clear：flip 把 limit 设为当前 position，position 归零，准备读；若只读了部分数据，接着调 clear（position=0, limit=capacity），下次 channel.read() 会从头覆盖未读数据。正确做法是读完再 clear，或用 compact() 保留未读内容并前移。
- 写入后忘记 flip 就读：buffer.put(data) 后 position 已移动，不 flip 就 get()，读到的是 position 之后的脏数据或抛 BufferUnderflowException。务必 write → flip → read → clear/compact 流程闭环。
- allocate 大小预估不足：ByteBuffer.allocate(256) 写入超长数据会抛 BufferOverflowException。对不确定长度的数据（如 HTTP body），优先用 ByteBuffer.wrap(bytes) 或配合扩容逻辑（如 ByteArrayOutputStream + toByteArray）。
通用原则：别让流替你背锅
很多“流读写问题”其实源于选型不当：
立即学习“Java免费学习笔记（深入）”；
- 数据量小（< 1000）、逻辑简单（如单次过滤+转换），直接 for 循环比 Stream 更快、更直观、更易调试。
- 涉及真实 I/O（文件读写、网络收发），优先用 try-with-resources 包裹 Channel 或 InputStream，确保 close；别依赖 Stream 的自动关闭（它不关底层资源）。
- 调试流逻辑困难？临时拆成两步：先 collect 到 List，再用传统方式验证中间结果。等逻辑稳了再合并回链式调用。
