数据校验流 CheckedInputStream：解析如何利用 Checksum 在读取流的过程中同步计算 CRC32

先来看一个常见的场景：我们需要对一个文件计算 CRC32 校验值，最直接的做法是读完整个文件后再手动遍历字节，一遍遍调用 update()。但 Ja va 早就想得更周全——CheckedInputStream 让你在读取数据流的过程中，就能同步完成 CRC32 的校验计算，不需要额外折腾缓冲区或手动计数。

这个类本质上是一个装饰器，它包裹住底层的 InputStream，内部挂载一个实现了 Checksum 接口的对象（比如 CRC32）。每次调用 read() 时，它先把字节从原始流中读出来，再自动传递给内部的 checksum 实例更新——整个过程对调用方完全透明。简单说，不是“读完再算”，而是“边读边算”，不改变原始流的读取行为，只悄悄增加一个校验的副作用。

CheckedInputStream 的正确使用方式

使用它有一个前提：必须完整读取整个文件，否则 checksum 只反映已读部分的校验值。常见的写法有以下几种：

• 用 while (cis.read() != -1) 单字节读取——简单直观，但性能较差，适合小文件或教学演示；
• 用带缓冲区的 cis.read(byte[] b) 循环读取——推荐做法，兼顾效率与可控性；
• 务必确保流被正确关闭（try-with-resources 是最省心的方式），否则可能遗漏最后一批数据，尤其是缓冲区没填满时；
• 读取结束后，通过 cis.getChecksum().getValue() 拿到最终的 CRC32 值，返回的是 long 类型。

格式化输出：别被负数吓到

这里有个容易被坑的地方：CRC32.getValue() 返回的是 Ja va 的有符号 long，但 CRC32 标准本身是 32 位无符号整数。直接打印可能看到负数——这不是错误，而是 Ja va 二进制表示的自然结果。

要得到标准的 8 位大写十六进制字符串（比如 ABCD1234），推荐这么写：

String.format("%08X", crc32.getValue() & 0xFFFFFFFFL)

用 & 0xFFFFFFFFL 把高位符号位清除，%08X 确保总长度为 8 位、大写、前面补零。也有人用 Long.toHexString(x).toUpperCase() 再手动截取前 8 位，但容易在高位被截断时出问题，相比之下 String.format 更稳妥。

和手动 update 的对比

有些人习惯用 BufferedInputStream 配合手动 crc.update(bytes, 0, cnt)——这种方式更灵活，比如可以跳过某些段、实现断点续校验，或者更精细地控制异常处理粒度。而 CheckedInputStream 胜在简洁、不易出错，代码量更少。

性能上两者相差不大，实际差异主要来自缓冲区大小和 JVM 的优化策略。无论选哪种，都建议使用 8KB 或更大的缓冲区，避免单字节 read() 带来的系统调用开销。