复制粘贴一时爽：传播最广的一段 Java 代码曝出 Bug

复制粘贴一时爽，频出 bug 火葬场。对开发者而言，Stack Overflow 和 GitHub 是最为熟悉不过的两大平台，这些平台充斥着大量开源项目信息和解决各类问题的代码片段。最近，一位叫做 Aioobe 的开发者在一项调查中发现了一段自己十年前写的代码，这段代码成为了 Stack Overflow 上复制次数最多、传播范围最广的答案，GitHub 的众多项目中也存在这段代码。然而，这位开发者表示这段代码其实是有 bug 的，并于近日更新了答案并作出说明。

这段代码是干啥的？

2010 年的时候，我整天泡在 Stack Overflow 上回答问题，希望可以提高自己的知名度。当时，有一个问题吸引了我的注意：如何以人类可读的格式输出字节数？举个例子，将“123456789 字节”转换为“123.5 MB”的格式输出。

这是现在的截图，但问题确实是这个

这里的隐含范式在于所得到的字符串值应该在 1 到 999.9 之间，后面再跟上一个大小合适的单位。当时已经有人给了一条回应。答案中的代码以循环为基础，基本思路非常简单：尝试所有单位，从最大（EB，即 1018 字节）到最小（B，即 1 字节），而后使用一种显示数量小于实际字节数量的单位。用伪代码写出来，基本是这么个意思：

复制代码

suffixes = [ “EB”, “PB”, “TB”, “GB”, “MB”, “kB”, “B” ]magnitudes = [ 1018, 1015, 1012, 109, 106, 103, 100 ]i = 0while (i < magnitudes.length && magnitudes[i] > byteCount) i++printf("%.1f %s", byteCount / magnitudes[i], suffixes[i])一般来说，如果发布的正确答案已经获得了正分数，那后发者很难追上。在 Stack Overflow 上，这就叫“拔枪最快的赢”。不过，我认为这个答案有缺陷，所以准备重新改改。我意识到，无论是 KB、MB 还是 GB，所有单位的本质实际都是 1000 的幂（当然，按 IEC 标准来讲是 1024），意味着应该可以使用对数而非循环来计算正确的量级单位。

基于以上思路，我发布了下列内容：

复制代码

public static String humanReadableByteCount(long bytes, boolean si) { int unit = si ? 1000 : 1024; if (bytes < unit) return bytes + " B"; int exp = (int) (Math.log(bytes) / Math.log(unit)); String pre = (si ? “kMGTPE” : “KMGTPE”).charAt(exp-1) + (si ? “” : “i”); return String.format("%.1f %sB", bytes / Math.pow(unit, exp), pre);}当然，这段代码可读性不高，而且 log/pow 也可能在一定程度上影响执行效率，但至少这里没有循环，几乎不涉及分支，我觉得还是比较整洁的。

这里面使用的数学方法非常简单。字节计数表示为 byeCount=1000s , 其中的 s 代表小数点后的位数（以二进制表示，则使用 1024 为基数），求解 s，即可得出 s=log1000(byteCount)。

API 里没有现成的 log1000 可以直接使用，但我们不妨用自然对数来表示，即 s=log(byteCount)/log(1000)。接下来，我们取 s 的底（即取整数），因为假如我们得出的结果超过 1 MB（但不足 1 GB），则希望继续使用 MB 作为表示单位。

此时，如果 s=1，则单位为 KB；如果 s=2，则单位为 MB；依此类推，我们将 byteCount 值除以 1000s ，然后取对应的单位。

接下来，我能做的就是等待，看看社区是否喜欢这个答案。那时候的我，绝对想不到它会成为 Stack Overflow 上复制最多的代码片段。

BUG 在哪？

估计不少人看到这儿肯定在想，这段代码里到底有什么 bug？

再来看一遍代码：

复制代码

public static String humanReadableByteCount(long bytes, boolean si) { int unit = si ? 1000 : 1024; if (bytes < unit) return bytes + " B"; int exp = (int) (Math.log(bytes) / Math.log(unit)); String pre = (si ? “kMGTPE” : “KMGTPE”).charAt(exp-1) + (si ? “” : “i”); return String.format("%.1f %sB", bytes / Math.pow(unit, exp), pre);}在 EB，即 1018 之后，接下来的单位应该是 ZB，即 1021。难道是输入量过大导致“kMGTPE”字符串的索引超出范围？不是的，long 的最大值是 263-1≈9.2×1018，因此任何 long 值都不会超出 EB 范围。

那么，是 SI 与二进制之间存在混杂吗？也不是。答案的早期版本中确实有这个问题，但很快就得到了修复。

那么，是不是 exp 可以为 0 会导致 charAt(exp-1) 发生错误？不是的。第一个 if 语句也涵盖了这种情况，因此 exp 值将始终至少为 1。

那就只剩最后一种情况了，输出结果中是否存在某些奇怪的舍入错误？这正是我们接下来要讨论的部分……

太多个 9

这套解决方案一直运作良好，直到字节数量达到 1 MB。假定输入为 999999 字节，那么结果（在 SI 模式下）将为“1000.0 kB”。尽管 999999 比 999.9 x 10001 更接近于 1000 x 10001，但根据规范，1000 的“有效位数”超出了范围。正确的结果应该是“1.0 MB”。

无论如何，在这个帖子的所有 22 个答案中（包括使用 Apache Commons 以及 Android 库的答案）截至本文撰稿之时都存在这个错误（或者其变体）。那么，我们该如何解决？

首先，我们会注意到，一旦字节数比 999.9 x 10001（999.9 k）更接近于 1 x 10002（1 MB），则指数（exp）就应由“k”变更为“M”。例如，9999950 就符合这种情况。同样的，当我们输入 999950000 时，我们应该从“M”切换为“G”，依此类推。为了达成这一目标，我们会计算该阈值，一旦字节数超过阈值，则增加 exp：

复制代码

if (bytes >= Math.pow(unit, exp) * (unit - 0.05)) exp++;调整之后，代码即可正常工作，直到字节数接近 1 EB。以输入为 999,949,999,999,999,999 为例，其目前的结果为 1000.0 PB，但正确结果应该是 999.9 PB。但从数学上讲，代码结果又是准确的，这又是怎么回事？这里，我们就遇到了 double（双）精度机制的局限性。

浮点运算基础知识

由于采用 IEEE 754 表示方式，因此近零浮点值会非常密集，但大值则非常稀疏。实际上，所有浮点值中的一半都位于 -1 与 1 之间；而在谈到大双精度浮点数时，像 Long.MAX_VALUE 那么大的值已经没有任何意义了。