文件句柄不具备线程安全性，多个线程并发读写同一句柄会导致偏移量竞争、内容覆盖或交错；虽FileInputStream引用为局部变量，但底层fd共享内核file结构体，offset、缓冲区等状态全局可见；安全做法包括分片独占打开、预加载内存处理或通过BlockingQueue解耦读写。
因为文件句柄是操作系统级资源，本身不具备线程安全性，多个线程直接并发读写同一个文件句柄会导致数据错乱、丢失或不可预知的 I/O 行为。
文件句柄本质是共享内核对象
Linux 中每个打开的文件（包括本地数据文件）会由内核分配一个唯一的文件描述符（fd），它指向内核中的 file 结构体。该结构体包含当前读写位置（offset）、访问标志、引用计数等状态信息。多个线程共用同一 fd 时，它们操作的是同一个内核 file 对象——偏移量共享、缓冲区共享、状态共享，而非各自独立副本。
- 线程 A 调用
read()后，文件 offset 向前移动；线程 B 紧接着read()，会从新位置开始读，而非起始处——这破坏了清洗逻辑的确定性； - 若两线程同时
write()到同一文件（尤其未加锁的追加模式），可能因 offset 竞态导致内容覆盖或交错（如“abc”和“xyz”写成“abxyzc”）； - 调用
lseek()或close()等操作也会影响所有持有该 fd 的线程，引发意外中断或 Invalid argument 错误。
局部变量不能解决句柄共享问题
有人误以为“在方法里定义 FileInputStream fis = new FileInputStream(file) 就是线程安全的”，这是错误认知。虽然 fis 引用是局部变量，但它底层封装的 fd 是内核全局资源。多个线程各自 new 出的 FileInputStream，若指向同一物理文件且未指定独占标志（如 O_EXCL），仍可能打开同一个内核 file 对象（取决于打开方式与文件系统行为）。
- 普通
open(path, O_RDONLY)多次调用 → 返回不同 fd，但都指向同一内核 file 对象（共享 offset）； - 使用
O_APPEND时，内核保证 write 原子追加，但 read 仍受共享 offset 影响； - 真正隔离需显式打开独立实例（如每个线程 open 一次），或改用内存映射（mmap）、分片读取等无共享设计。
安全做法：切断共享路径
清洗任务应避免多线程争抢单个句柄，转而采用天然隔离或同步协作模式：
-
每个线程独占打开：按数据分片（如按行号、字节范围、文件名哈希），各线程分别
open()对应子集，互不干扰； - 预加载到内存再处理：小文件可一次性读入 byte[] 或 List<String>，后续清洗纯内存操作，完全规避 I/O 共享；
-
用线程安全通道中转：主线程顺序读取，通过
BlockingQueue<Record>分发给工作线程，读写职责分离； -
必要时加文件级锁：对必须串行访问的场景，用
flock()或FileLock控制临界区，但会牺牲并发度。
不复杂但容易忽略：句柄不是普通变量，它的“共享”藏在内核里，看不见却最危险。
