Stack Overflow 最火的一段代碼竟然有 Bug...-有解無憂

某天，我忙中偷閑去Stack Overflow上賺聲望值，

于是，我看到了下面這個問題：怎樣將位元組數輸出成人類可讀的格式？也就是說，怎樣將123,456,789位元組輸出成123.5MB？

隱含的條件是，結果字串應當在1~999.9的范圍內，后面跟一個適當的表示單位的后綴，

這個問題已經有一個答案了，代碼是用回圈寫的，基本思路很簡單：嘗試所有尺度，從最大的EB（10^18位元組）開始直到最小的B（1位元組），然后選擇小于位元組數的第一個尺度，用偽代碼來表示的話大致如下：

suffixes   = [ "EB", "PB", "TB", "GB", "MB", "kB", "B" ]
magnitudes = [ 1018, 1015, 1012, 109, 106, 103, 100 ]
i = 0
while (i < magnitudes.length && magnitudes[i] > byteCount)
i++
printf("%.1f %s", byteCount / magnitudes[i], suffixes[i])

通常，如果一個問題已經有了正確答案，并且有人贊過，別的回答就很難趕超了，不過這個答案有一些問題，所以我依然有機會超過它，至少，回圈還有很大的清理空間，

1、這只是一個代數問題！

然后我就想到，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的組合的效率也不高，但我沒有使用回圈，而且沒有任何分支，看起來很干凈，

這段代碼的數學原理很簡單，位元組數表示為byteCount = 1000^s，其中s表示尺度，（對于二進制記法則使用1024為底，）求解s可得s = log_1000(byteCount)，

API并沒有提供log_1000，但我們可以用自然對數表示為s = log(byteCount) / log(1000)，然后對s向下取整（強制轉換為int），這樣對于大于1MB但不足1GB的都可以用MB來表示，

此時如果s=1，尺度就是kB，如果s=2，尺度就是MB，以此類推，然后將byteCount除以1000^s，并找出正確的后綴，

接下來，我就等著社區的反饋了，我并不知道這段代碼后來成了被復制粘貼最多的代碼，

2、對于貢獻的研究

到了2018年，一位名叫Sebastian Baltes的博士生在《Empirical Software Engineering》雜志上發表了一篇論文，題為《Usage and Attribution of Stack Overflow Code Snippets in GitHub Projects》，

該論文的主旨可以概括成一點：人們是否在遵守Stack Overflow的CC BY-SA 3.0授權？也就是說，當人們從Stack Overflow上復制粘貼時，會怎么注明來源？

作為分析的一部分，他們從Stack Overflow的資料轉出中提取了代碼片段，并與公開的GitHub代碼庫中的代碼進行匹配，論文摘要如是說：

We present results of a large-scale empirical study analyzing the usage and attribution of non-trivial Java code snippets from SO answers in public GitHub (GH) projects.

（本文對于在公開的GitHub專案中使用來自Stack Overflow上有價值的代碼片段的情況以及來源注明情況進行了大規模的經驗分析，并給出了結果，）（劇透：絕大多數人并不會注明來源，）

論文中有這樣一張表格：

id為3758880的答案正是我八年前貼出的答案，此時該答案已經被閱讀了幾十萬次，擁有上千個贊，

在GitHub上隨便搜索一下就能找到數千個humanReadableByteCount函式：

你可以用下面的命令看看自己有沒有無意中用到：

$ git grep humanReadableByteCount

3、問題

你肯定在想：這段代碼有什么問題：

再來看一次：

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（10^{18）之后是ZB（10}21），是不是因為kMGTPE字串的越界問題？

并不是，long的最大值為2^{63-1，大約是9.2x10}18，所以long絕對不會超過EB，

是不是SI和二進制的混合問題？不是，前一個版本的確有這個問題，不過很快就修復了，

是不是因為exp為0會導致charAt(exp-1)出錯？也不是，第一個if陳述句已經處理了該情況，exp值至少為1，

是不是一些奇怪的舍入問題？對了……

4、許多9

這段代碼在1MB之前都非常正確，但當輸入為999,999時，它（在SI模式下）會給出“1000.0 kB”，盡管999,999與1,000x1000^{1的距離比與999.9x1000}1的距離更小，但根據問題的定義，有效數字部分的1,000是不正確的，正確結果應為"1.0 MB"，

據我所知，原帖下的所有22個答案（包括一個使用Apache Commons和Android庫的答案）都有這個問題（或至少是類似的問題），

那么怎樣修復呢？首先，我們注意到指數（exp）應該在位元組數接近1x1,000^{2（1MB）時，將回傳結果從k改成M，而不是在位元組數接近999.9x1000}1（999.9k）時，這個點上的位元組數為999,950，類似地，在超過999,950,000時應該從M改成G，以此類推，

為了實作這一點，我們應該計算該閾值，并當bytes大于閾值時增加exp的結果，（對于二進制的情況，由于閾值不再是整數，因此需要使用ceil進行向上取整），

if (bytes >= Math.ceil(Math.pow(unit, exp) * (unit - 0.05)))exp++;

5、更多的9

但是，當輸入為999,949,999,999,999,999時，結果為1000.0 PB，而正確的結果為999.9 PB，從數學上來看這段代碼是正確的，那么問題除在何處？

此時我們已經達到了double型別的精度上限，

關于浮點數運算

根據IEEE 754的浮點數表示方法，接近0的數字非常稠密，而很大的數字非常稀疏，實際上，超過一半的值位于-1和1之間，而且像Long.MAX_VALUE如此大的數字對于雙精度來說沒有任何意義，用代碼來表示就是

double a = Double.MAX_VALUE;
double b = a - Long.MAX_VALUE;
System.err.println(a == b);  // prints true

有兩個計算是有問題的：

String.format引數中的觸發
對exp的結果加一時的閾值

當然，改成BigDecimal就行了，但這有什么意思呢？而且改成BigDecimal代碼也會變得更亂，因為標準API沒有BigDecimal的對數函式，

縮小中間值

對于第一個問題，我們可以將bytes值縮小到精度更好的范圍，并相應地調整exp，由于最終結果總要取整的，所以丟棄最低位有效數字也無所謂，

if (exp > 4) {
    bytes /= unit;
    exp--;
}

調整最低有效位元

對于第二個問題，我們需要關心最低有效位元（999,949,99...9和999,950,00...0等不同冪次的值），所以需要使用不同的方法解決，

首先注意到，閾值有12種不同的情況（每個模式下有六種），只有其中一種有問題，有問題的結果的十六進制表示的末尾為D00，如果出現這種情況，只需要調整至正確的值即可，

long th = (long) Math.ceil(Math.pow(unit, exp) * (unit - 0.05));
if (exp < 6 && bytes >= th - ((th & 0xFFF) == 0xD00 ? 51 : 0))
exp++;

由于需要依賴于浮點數結果中的特定位元模式，所以需要使用strictfp來保證它在任何硬體上都能運行正確，

6、負輸入

盡管還不清楚什么情況下會用到負的位元組數，但由于Java并沒有無符號的long，所以最好處理復數，現在，-10,000會產生-10000 B，

引入absBytes變數：

long absBytes = bytes == Long.MIN_VALUE ? Long.MAX_VALUE : Math.abs(bytes);

運算式如此復雜，是因為-Long.MIN_VLAUE == LONG.MIN_VALUE，以后有關exp的計算你都要使用absBytes來代替bytes，

7、最終版本

下面是最終版本的代碼：

// From: https://programming.guide/worlds-most-copied-so-snippet.html
public static strictfp String humanReadableByteCount(long bytes, boolean si) {
    int unit = si ? 1000 : 1024;
    long absBytes = bytes == Long.MIN_VALUE ? Long.MAX_VALUE : Math.abs(bytes);
    if (absBytes < unit) return bytes + " B";
    int exp = (int) (Math.log(absBytes) / Math.log(unit));
    long th = (long) Math.ceil(Math.pow(unit, exp) * (unit - 0.05));
    if (exp < 6 && absBytes >= th - ((th & 0xFFF) == 0xD00 ? 51 : 0)) exp++;
    String pre = (si ? "kMGTPE" : "KMGTPE").charAt(exp - 1) + (si ? "" : "i");
    if (exp > 4) {
        bytes /= unit;
        exp -= 1;
    }
    return String.format("%.1f %sB", bytes / Math.pow(unit, exp), pre);
}

這個答案最初只是為了避免回圈和過多的分支的，諷刺的是，考慮到各種邊界情況后，這段代碼比原答案還難懂了，我肯定不會在產品中使用這段代碼，

總結

Stack Overflow上的代碼就算有幾千個贊也可能有問題，
要測驗所有邊界情況，特別是對于從Stack Overflow上復制粘貼的代碼，
浮點數運算很難，
復制代碼時一定要注明來源，別人可以據此提醒你重要的事情，

原文鏈接：https://programming.guide/worlds-most-copied-so-snippet.html

作者：Andreas Lundblad

譯者：彎月，責編：歐陽姝黎

出品：CSDN（ID：CSDNnews）

近期熱文推薦：

1.1,000+ 道 Java面試題及答案整理(2021最新版)

2.終于靠開源專案弄到 IntelliJ IDEA 激活碼了，真香！

3.阿里 Mock 工具正式開源，干掉市面上所有 Mock 工具！

4.Spring Cloud 2020.0.0 正式發布，全新顛覆性版本！

5.《Java開發手冊（嵩山版）》最新發布，速速下載！

覺得不錯，別忘了隨手點贊+轉發哦！

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/291764.html

標籤：其他

上一篇：Java 必會的工具庫，讓你的代碼量減少 90%...

下一篇：阿里云RocketMQ定時/延遲訊息佇列實作