如何在 Java 中利用 Files.readAllBytes() 高效读取小型的二进制文件到内存

聊点实际经验。在 Ja va 里处理小型二进制文件时，Files.readAllBytes() 确实是个顺手的方法——代码简洁，一行调用就能把整个文件塞进 byte[]，不用操心流的关闭。但前提是，你得清楚这个文件“确实很小”。一旦文件体积超出预期，或者调用频率上去了，GC 压力甚至 OutOfMemoryError 就会找上门来。

所以，真正适合用它的是哪些场景？

只有当你对文件体积有十足的把握，并且后续需要随机访问全部字节时，才是它的用武之地。比如读取配置图标、加密密钥、小尺寸的序列化数据（像 Protocol Buffer 的小消息），或者测试用的 fixture 文件。这些场景下，Files.readAllBytes() 既直接又高效。

反过来，日志文件、图片或视频的原始流、网络响应体、用户上传的任意文件——这些必须老老实实走流式读取，用 InputStream 配合缓冲。否则，生产环境里突然爆个 OOM，哭都来不及。

• 文件路径必须真实存在且可读，否则会抛出 IOException（比如 NoSuchFileException）。
• 调用前，强烈建议先用 Files.size(path) 做个体积校验。比如限制不超过 5MB，避免意外加载大文件。
• JDK 版本也得留意：JDK 7+ 就支持了，但 JDK 11+ 对某些文件系统（比如 Windows 的符号链接）行为更加稳定。

常见错误：忽略异常和资源泄漏风险

Files.readAllBytes() 是静态方法，不涉及手动关闭资源，所以没有传统意义上的“资源泄漏”——但这不是你掉以轻心的理由。现实中有不少开发者，因为误以为它能安全读取任意大小的文件，结果生产环境里突然遇到 OOM，才知道问题严重。

举个例子，错误写法是这样：byte[] data = Files.readAllBytes(Paths.get("user-uploaded.bin"));——没做大小检查，也没有任何兜底处理。

正确的做法是包裹在 try-catch 里，并且读取前加上体积断言。下面是一个更稳妥的做法：

long size = Files.size(path);
if (size > 5_000_000) {
    throw new IllegalArgumentException("File too large: " + size);
}
byte[] data = Files.readAllBytes(path);

务必要明确处理 IOException 和 SecurityException（尤其在安全管理器启用时），别图省事直接捕获 Exception。

替代方案：比 readAllBytes() 更可控的读法

如果“小型”这个边界比较模糊，或者你希望复用缓冲区、精确控制内存峰值，那 Files.newInputStream() 配合 ByteArrayOutputStream 是更好的选择。

• 优势很明显：可以设置固定缓冲区（比如 8KB），内存占用恒定；还能中途取消或限制速度。
• 劣势是代码稍微长一点，需要手动 close（或者用 try-with-resources）。

下面是一个 JDK 9+ 的示例，利用了 transferTo() 方法：

try (InputStream is = Files.newInputStream(path)) {
    ByteArrayOutputStream baos = new ByteArrayOutputStream();
    is.transferTo(baos); // JDK 9+，等效于循环 read/write
    byte[] data = baos.toByteArray();
}

如果是 JDK 8，就得用 IOUtils.copy()（来自 Apache Commons）或者手写读取循环。

话说回来，真正关键的不是某个函数怎么写，而是你有没有想清楚——“这个文件为什么确定是小的？”是靠文档约定？上游校验？还是运行时用 Files.size() 检查？这个意识没建立起来，再简单的 API 都可能翻车。