bufferedinputstream 不能直接协同读取 mappedbytebuffer 背后的 directbytebuffer，因其设计目标不匹配：前者依赖 inputstream 的 read(byte[]) 方法，而后者是不实现 inputstream 的堆外内存视图，强行包装会导致冗余拷贝、丢失偏移控制且丧失零拷贝优势。
BufferedInputStream 不能直接协同读取内存映射文件（MappedByteBuffer）背后的 DirectByteBuffer。
BufferedInputStream 的设计目标不匹配 DirectByteBuffer
BufferedInputStream 是为装饰普通 InputStream（如 FileInputStream、ByteArrayInputStream）而设计的，它内部维护一个 byte[] 缓冲区，通过调用底层 InputStream 的 read(byte[]) 方法填充缓冲区。而 MappedByteBuffer 是 NIO 的堆外内存视图，本身不实现 InputStream 接口，也没有 read() 方法供 BufferedInputStream 调用。
试图把 MappedByteBuffer 包装成 InputStream 再套 BufferedInputStream，不仅绕远路，还会触发不必要的拷贝和额外开销：
- 必须先将 DirectByteBuffer 中的数据复制到堆内 byte[]（如通过 get(byte[])），失去零拷贝优势
- BufferedInputStream 的二次缓冲变成冗余——DirectByteBuffer 本身已可随机访问、批量读取
- 无法利用 MappedByteBuffer 的 position/limit 等状态，BufferedInputStream 会丢失原始偏移控制能力
更合理的方式：直接操作 MappedByteBuffer
既然文件已映射为 DirectByteBuffer，应直接使用其提供的高效读取方法，无需引入 BufferedInputStream：
- 用 get(byte[] dst, int offset, int length) 批量读取数据到目标数组（避免单字节 get()）
- 配合 position() 和 limit() 控制读取范围，实现类似“缓冲区滑动”的效果
- 若需缓冲语义（如预读、回退），可自行封装一个基于 ByteBuffer 的 BufferReader 类，复用其 mark/reset、slice 等能力
例如：
MappedByteBuffer bb = fileChannel.map(READ_ONLY, 0, fileSize);byte[] buf = new byte[8192];
bb.get(buf); // 直接读入，无中间拷贝
如果非要走 InputStream 路线，应选 ByteChannel + Channels
若因接口约束必须提供 InputStream，推荐用标准桥接方式：
- 用 Channels.newInputStream(ReadableByteChannel) 将 FileChannel（或自定义的 ByteBufferBackedChannel）转为 InputStream
- 再包装 BufferedInputStream —— 此时缓冲发生在 Channel.read(ByteBuffer) 层，仍可受益于堆外内存和系统调用优化
- 避免手动将 MappedByteBuffer 转成 ByteArrayInputStream 或自定义 InputStream（易出错且性能差）
关键结论：不要强行组合，按场景选工具
BufferedInputStream 和 DirectByteBuffer 分属不同抽象层次：前者是流式、阻塞、面向 byte[] 的传统 IO 工具；后者是面向块、支持随机访问、零拷贝的 NIO 原语。混用不仅没协同，反而掩盖了各自优势。真正需要缓冲时，优先考虑 ByteBuffer 的 compact/flip、或者用 Memory-Mapped File 配合自定义缓冲逻辑。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
