bufferedinputstream 不是线程安全的，因其内部共享字段（buf、pos、count、markpos）无同步保护，多线程并发调用 read() 或 skip() 会导致数据错乱、越界或逻辑异常；javadoc 明确声明其设计契约为单线程独占使用，加锁无法保证 mark/reset 等复合操作的语义正确性，正确做法是每线程独立实例化或改用 nio 并发模型。
BufferedInputStream 本身不是线程安全的，多线程并发读取同一个实例会引发数据错乱、越界或逻辑异常，而非单纯的“锁竞争”问题。
核心问题：非线程安全的设计本质
BufferedInputStream 内部维护一个共享的字节数组缓冲区（buf）、当前位置（pos）、有效数据边界（count）和标记位置（markpos）。这些字段全部是普通实例变量，没有任何同步保护。当多个线程同时调用 read() 或 skip() 等方法时：
- 多个线程可能同时修改
pos，导致某次读取跳过字节或重复读取 -
fill()方法在缓冲区耗尽时会重置pos=0、count并触发底层流读取——若此时另一线程正基于旧count判断是否需填充，就会读到脏数据或抛出ArrayIndexOutOfBoundsException -
mark()/reset()在并发下完全不可靠，markpos可能被任意线程覆盖
为什么没有内置锁？不是性能妥协，而是契约明确
Java I/O 流的设计哲学是“单线程独占使用”。Javadoc 明确声明 BufferedInputStream 是“not safe for use by multiple threads”。它不提供同步，并非因为“加锁太慢”，而是因为：
- 同步粒度难以设计：方法级 synchronized 无法解决复合操作（如 mark+reset）的原子性
- 底层流（如 FileInputStream）本身也不保证线程安全，同步 BufferedInputStream 无法掩盖底层竞态
- 真正需要并发读的场景，通常应由上层控制——比如每个线程持有一个独立的流实例
正确应对并发读的实用方案
不要试图给 BufferedInputStream 加锁来“修复”并发访问。应根据实际场景选择合理方式：
-
每个线程独立打开并包装流：适用于文件等可随机访问的资源。例如：
new BufferedInputStream(new FileInputStream("data.bin"))每线程一份，彻底规避共享状态 -
用线程安全的替代抽象：如将数据预加载进
byte[]或ByteBuffer，再由多个线程无锁读取；或使用java.nio.channels.FileChannel配合ByteBuffer实现真正的并发读（需注意 position 的原子更新） -
外层串行化访问：仅当必须复用同一流对象时（如网络响应流），用
synchronized块包裹所有读操作，但会丧失并发性——本质上退化为单线程吞吐
误区提醒：别混淆“同步开销”与“正确性失效”
讨论“锁竞争与同步开销”隐含的前提是“加锁后能正常工作”，但 BufferedInputStream 加锁后仍无法保证 mark/reset、skip 等操作的语义正确性。更严重的是，即使手动加锁，也无法解决底层流（如 SocketInputStream）在多线程调用 read() 时的阻塞冲突或协议错乱。因此，这不是优化问题，而是模型误用。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
