fileinputstream本身线程不安全，因多线程共享同一实例时，其read()操作非原子，共用文件描述符与内部状态，导致文件指针竞争、数据错乱、重复读或字节跳过。
FileInputStream 本身不是线程安全的，多个线程并发调用同一个 FileInputStream 实例的 read() 方法时，**存在文件指针（file pointer）竞争风险，可能导致数据错乱、重复读取或跳过字节**。
为什么 FileInputStream 的指针操作不安全？
FileInputStream 底层依赖操作系统级别的文件描述符（file descriptor），其读取行为由内核维护的当前偏移量（offset）控制。但 Java 层的 FileInputStream 实例在多次 read() 调用间会缓存并更新自身维护的“逻辑读取位置”（尤其在带缓冲的装饰器如 BufferedInputStream 中更明显）。关键点在于：
- Java 层的
read()方法不是原子操作：它通常包含“检查是否到 EOF → 从内核读一批字节 → 更新内部状态 → 返回长度”等多个步骤； - 多个线程共享同一 FileInputStream 实例时，它们共用同一个文件描述符和同一套 Java 对象状态（如
fd、channel、缓冲区等）； - 没有内置同步机制，线程 A 正在执行
read()的中间状态时，线程 B 可能同时触发另一次read()，导致内核 offset 被反复移动，Java 层状态错位。
典型冲突表现
以下情况极易暴露问题：
-
重复读取相同内容：线程 A 读了前 100 字节后被调度挂起，线程 B 也调用
read()，从同一位置开始读，结果两线程拿到重叠数据； - 字节丢失或跳过：A 读了 50 字节并更新了内部计数，但尚未刷新状态；B 紧接着读，误以为从 50 处继续，实际内核 offset 已被 A 推进，B 从 50+ 处读起，中间部分被跳过；
- read() 返回 -1（EOF）过早：某线程读到末尾后未及时同步状态，另一线程仍尝试读，可能因状态不一致直接返回 -1，而实际还有数据未读完。
安全做法：不共享流实例
根本原则是：**每个线程应持有独立的 FileInputStream 实例**。因为每个实例对应独立的文件描述符（即使指向同一文件路径），内核为每个 fd 维护独立的 offset。
- ✅ 正确：每个线程 new 一个 FileInputStream（或用 try-with-resources 自动关闭）；
- ❌ 错误：将单个 FileInputStream 对象传给多个线程 Runnable 或提交到线程池复用；
- ⚠️ 注意：即使使用 RandomAccessFile，若多线程共享同一实例，seek + read 组合同样不安全——seek 是非原子的，且与后续 read 之间无锁保护。
补充说明：FileChannel 的差异
FileChannel 支持多线程并发 read(ByteBuffer)，因为它要求显式指定 position 和 buffer，每次调用都可视为“位置无关”的原子读（底层通过系统调用 pread() 实现）。但注意：
- 这仅适用于
read(ByteBuffer, long position)形式； - 若调用无参
read(ByteBuffer)，仍依赖 channel 内部 position，此时多线程共享 channel 仍不安全； - FileChannel 本身不是线程安全的，其状态（如 position、mode）需由调用方保证互斥访问。
