flink/spark 中不应手动使用 bufferedinputstream，因其底层输入源已内置缓冲机制，额外包装不仅无效，还可能破坏状态一致性、干扰 checkpoint 或引发线程安全问题。
BufferedInputStream 通常无效甚至有害。
核心原因在于：Flink/Spark 的输入源（如 FileInputFormat、SocketSource、TextInputFormat）底层已使用带缓冲的通道（FileChannel）、内存映射或自定义缓冲区，且数据流经序列化器（Serializer）、反序列化器（DeserializationSchema）和网络栈，再套一层 BufferedInputStream 不仅无法生效，还可能破坏状态一致性、干扰 checkpoint 或引发线程安全问题。
为什么不能简单 new BufferedInputStream(inputStream)
在 Flink 的 RichFlatMapFunction 或 Spark 的 mapPartitions 中，若从 HDFS/S3/本地文件读取原始字节流并尝试包装：
- Flink 的
FSDataInputStream（Hadoop 封装）本身已有 4KB~128KB 缓冲，默认启用；S3A 客户端内部也用BufferedInputStream或 NIO buffer - Spark 的
FSDataInputStream同样自带缓冲；若用sc.binaryRecords()或spark.read.format("binaryFile")，框架已按块预读 -
BufferedInputStream是阻塞式、非线程安全的，而算子常并发调用（如多 task 处理不同 split），共享流会导致竞态 - checkpoint 时需可序列化流对象，
BufferedInputStream包含底层系统资源（如 socket fd、file descriptor），无法跨 JVM 序列化
真正需要缓冲字节的场景及替代方案
当业务确需逐字节解析（如自定义二进制协议），应避开裸流操作，改用框架推荐方式：
-
Flink：用
InputFormat+ 自定义BinaryInputFormat—— 在open()中创建线程局部BufferedInputStream，每次nextRecord()前重置缓冲区，确保每个 split 独立实例 -
Spark：用
WholeTextFileInputFormat或BinaryFileInputFormat读取完整分片，再用ArrayInputStream或ByteBuffer.wrap()做内存内缓冲解析，避免频繁 IO -
统一建议：优先用
byte[]批量读取 —— 如 FlinkFSDataInputStream.read(byte[], offset, len)，SparkinputStream.read(buffer)，比单字节read()快 10x+，且不依赖BufferedInputStream
如果必须用 BufferedInputStream（极少数情况）
仅限本地调试或非分布式小文件处理，且需严格隔离生命周期：
- 在算子
open()或mapPartition内部按需构造，close()配对释放 - 缓冲区大小设为 8KB~64KB（
new BufferedInputStream(is, 65536)），避免过小（频繁 fill）或过大（内存浪费） - 禁止将
BufferedInputStream存为成员变量或跨 task 共享；不可放入广播变量或累加器 - 配合
mark()/reset()时注意：HDFS/S3 流通常不支持 mark（markSupported() == false），需先复制到ByteArrayInputStream
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
