为什么使用Collections.sort的该程序仅对大小为32或更大的列表失败？

为什么使用Collections.sort的该程序仅对大小为32或更大的列表失败？

它取决于实现，但是在openjdk
8
中，将根据MIN_MERGE（等于32）检查数组的大小。这避免了对

mergeLo

/
的调用，

mergeHi

后者会引发异常。

从JDK / jdk / openjdk / 7u40-b43 8-b132 7-b147-8-b132 /
java.util.TimSort
：

static <T> void sort(T[] a, int lo, int hi, Comparator<? super T> c,          T[] work, int workbase, int workLen) {    assert c != null && a != null && lo >= 0 && lo <= hi && hi <=

a.length;

    int nRemaining  = hi - lo;    if (nRemaining < 2)        return;  // Arrays of size 0 and 1 are always sorted    // If array is small, do a "mini-TimSort" with no merges    if (nRemaining < MIN_MERGE) {        int initRunLen = countRunAndMakeAscending(a, lo, hi, c);        binarySort(a, lo, hi, lo + initRunLen, c);        return;    }        TimSort<T> ts = new TimSort<>(a, c, work, workbase, workLen);    int minRun = minRunLength(nRemaining);    do {        // Identify next run        int runLen = countRunAndMakeAscending(a, lo, hi, c);        // If run is short, extend to min(minRun, nRemaining)        if (runLen < minRun) { int force = nRemaining <= minRun ? nRemaining : minRun; binarySort(a, lo, lo + force, lo + runLen, c); runLen = force;        }        // Push run onto pending-run stack, and maybe merge        ts.pushRun(lo, runLen);        ts.mergeCollapse();        // Advance to find next run        lo += runLen;        nRemaining -= runLen;    } while (nRemaining != 0);    // Merge all remaining runs to complete sort    assert lo == hi;    ts.mergeForceCollapse();    assert ts.stackSize == 1;}