真实性能测试需统一文件大小（≥100MB）、读写方式、JVM预热控制、系统页缓存清理及资源关闭；字节流单字节读慢，缓冲流提升显著，MappedByteBuffer擅随机小块访问而非纯顺序大块读。
Java IO 性能测试要真实反映字节流、缓冲流与内存映射（MappedByteBuffer）的差异，关键在于控制变量、匹配场景、避免误判。三者不是简单“谁更快”，而是各自在不同读写模式、数据规模和系统资源下表现迥异。
明确测试目标与可控条件
性能对比失效，往往源于测试设计不合理。必须统一以下要素：
- 文件大小固定：建议至少 100MB 起步（如 100MB / 1GB），太小会受JVM预热、缓存干扰严重；
-
读写方式一致：都用批量读（如
read(byte[])）或都用单字节读（read()），否则缓冲流优势被人为放大； - 关闭JVM优化干扰：禁用JIT预热干扰（首次运行不计入）、多次循环取平均值（建议 ≥5 次）；
-
清空系统页缓存（Linux）：用
sync && echo 3 > /proc/sys/vm/drop_caches，避免磁盘缓存掩盖真实IO差异； - 使用 try-with-resources，确保流正确关闭，防止句柄泄漏影响后续轮次。
字节流 vs 缓冲流：重点看小粒度读写的收益
缓冲流（BufferedInputStream）的核心价值，在于把高频小IO合并为低频大IO。它对单字节读写提升巨大，但对批量读意义有限。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 测试单字节读（
while ((b = in.read()) != -1)）：FileInputStream 可能耗时 420ms，BufferedInputStream 降至约 180ms（提升 ~57%）； - 测试 8KB 批量读（
in.read(buf)）：两者差距缩小至 5–10%，因底层已接近一次系统调用； - 默认缓冲区为 8192 字节，可通过构造函数自定义（如
new BufferedInputStream(fis, 64 * 1024)），在超大文件顺序读中可进一步微调。
内存映射（MappedByteBuffer）：适合随机访问与极低延迟场景
MappedByteBuffer 不走传统流路径，而是将文件区域直接映射到虚拟内存，由操作系统按需分页加载。它不适用于所有场景：
立即学习“Java免费学习笔记（深入）”；
- 优势明显：小块随机读（如每次读 32B–4KB）、频繁跳转访问、低延迟要求（如日志检索、数据库索引）；
- 无明显优势：纯顺序大块读写（如 1MB/次），此时 FileChannel + ByteBuffer 和 BufferedInputStream 表现接近；
- 注意风险：映射过大文件可能引发
OutOfMemoryError: Map failed（受限于用户空间虚拟地址）；长时间映射未释放可能拖慢GC； - 写入后需显式调用
buffer.force()才能保证落盘（除非打开SYNC选项）。
推荐对比维度与结果解读方式
不要只看“总耗时”，应分层观察：
- CPU 时间占比：缓冲流降低系统调用，CPU 用户态时间下降；MappedByteBuffer 可能增加缺页中断，内核态时间略升；
- GC 压力：BufferedInputStream 内部缓冲区复用，对象分配少；而反复 new byte[] 批量读会产生短期对象；
- 吞吐量（MB/s）：更适合横向比较，例如 “1GB 文件，平均读速：FileInputStream=85 MB/s，BufferedInputStream=210 MB/s，MappedByteBuffer=235 MB/s（随机读 4KB 块）”；
-
适用性标注：表格中应注明每种方式的典型适用场景，而非仅列数字。例如：
Files.lines()快但内存占用高，BufferedReader平衡易用与效率，MappedByteBuffer强在随机性而非吞吐。
