一句話總結：

JDK7中的Collections.Sort方法實現中，應用了比較運算的基本屬性：若A大於B，則B小於A，若A等於B，則B等於A。所以要求傳入compare方法在傳入引數交換時，返回值正負也需要交換，或恆為0，否則可能會在排序時拋錯。

現象：

昨晚偶然發現XX業務線上介面呼叫返回伺服器內部異常。而呼叫模擬環境介面返回正常。檢視日誌發現報錯如下：

2015-01-14 22:14:17 291 [WARN] ApiServletApiServlet process error! act:query_join_groups, PARAMS:{}

java.lang.IllegalArgumentException:Comparison method violates its general contract!

 at java.util.TimSort.mergeHi(TimSort.java:868)

  atjava.util.TimSort.mergeAt(TimSort.java:485)

  atjava.util.TimSort.mergeCollapse(TimSort.java:408)

at java.util.TimSort.sort(TimSort.java:214)

  atjava.util.TimSort.sort(TimSort.java:173)

  at java.util.Arrays.sort(Arrays.java:659)

  atjava.util.Collections.sort(Collections.java:217)

atcn.sina.groupchat.processor.QueryJoinGroupsProcessor.process(QueryJoinGroupsProcessor.java:54)

排查過程：

查看出錯的業務程式碼如下

      Collections.sort(infos, new Comparator<UserGroupInfo>() {

           @Override

           public int compare(UserGroupInfo info1, UserGroupInfo info2) {

               return info2.joinTime > info1.joinTime ? 1 : -1;

           }

       });

查看了具體報錯的位置，發現只有如下程式碼：

if (len2== 0) {

     throw new IllegalArgumentException("Comparison method violates its generalcontract!");

    }

Google了一下出錯，發現JDK6和JDK7的sort實現不同，對於JDK7才會有上述問題。解決的辦法是compare方法在傳入物件相等時必須返回0，但是沒有詳細描述出錯的原因。

查了一下JDK版本1.6到1.7的改動，Collections.Sort方法實現從普通歸併排序改成了TimSort排序。不太理解為什麼更換排序會導致相同輸入報錯，並且報錯的地方判斷邏輯很突兀。於是簡單的瞭解的了一下java timsort的實現，和大家分享一下。

TimSort排序是一種優化的歸併排序，對於降序和升降序片段混合的輸入有很大的效能提升。OpenJDK關於TimSort的實現如下：

1.      遍歷陣列，將陣列分為若干個升序或降序的片段，反轉降序的片段使其變為升序，每個片段成為一個Runtask

2.      將切分好的RunTask壓棧

3.      對棧中相鄰的RunTask做歸併，歸併過程相對普通的歸併排序做了一定的優化，主要有兩步

a)        設做歸併的兩段分別為A，B，A段的起點為base1，長度為len1，B段起點為base2，長度為len2。取B點的起點值B[base2]，在A段中進行二分查詢，將A段中小於等於B[base2]的段作為merge結果的起始部分；再取A段的終點值a[base1 + len1 - 1]，在B段中二分查詢，將B段中大於等於a[base1 + len1 - 1]值的段作為merge結果的結束部分。

b)        之後進行普通歸併，將兩段終點標為cursor1和cursor2，倒序歸併

這裡有一個優化，如果連續N（圖中假設為4）次某段的cursor指向的值都大於另一段，則可以預期該段的平均值大於另一段，仿照（a）中的方法，用cursor的值分別對另一段進行切割，提高歸併速度。如下圖中所示，cursor1指向的值（10,10,11,11）已經連續4次大於cursor2指向的值（8），觸發切割邏輯，用cursor2指向的值去切割1段，使cursor1左移，然後用cursor1切割2段，由於cursor1指向值（10）大於2段中所有的值，沒有進行實際切割。

最終，將2段的值arraycopy到1段0~3的位置，歸併結束。

程式碼如下：

// 普通歸併過程，count記錄連續大於的次數，到達一個閾值時，進行二分法切割，提高歸併速度

do {

                         // tmp為B段的複製

               if (c.compare(tmp[cursor2], a[cursor1]) < 0) {

                   a[dest--] = a[cursor1--];

                   count1++;

                   count2 = 0;

                   if (--len1 == 0)

                       break outer;

               } else {

                                              …

               }

            }while ((count1 | count2) < minGallop);

                           // 到達閾值後，用預期平均值較小的段的最大值去切割另一段，方法和（a）中類似

                  do {

               count1 = len1 - gallopRight(tmp[cursor2], a, base1, len1, len1 - 1, c);

               if (count1 != 0) {

                   dest -= count1;

                   cursor1 -= count1;

                   len1 -= count1;

                   System.arraycopy(a, cursor1 + 1, a, dest + 1, count1);

                  if (len1 == 0)

                       break outer;

               }

               a[dest--] = tmp[cursor2--];

               if (--len2 == 1)

                   break outer;

                                    // 出問題的地方，gallopLeft是在B段中查詢A[Cursor1]的位置，如有相等的情況，取最左的位置，如果B段全部大於A[Cursor1]，則返回0

               count2 = len2 - gallopLeft(a[cursor1], tmp, 0, len2, len2 - 1, c);

               if (count2 != 0) {

                                              …

                  len2-= count2;

                   …

                  }

                               …

            }while (count1 >= MIN_GALLOP | count2 >= MIN_GALLOP);

                           …

                           // 最終對len2進行合法檢測

                  if (len2 == 0) {

                      throw newIllegalArgumentException("Comparison method violates its generalcontract!");

            }

關於程式碼中最後的len2值檢測，是因為（a）中切割後，A中所有的值都大於B段的起點B[base2]。在之後的普通歸併中，如果出現count2>=minGallop的情況，進行加速歸併優化時，按照之前的推論，gallopLeft返回值大於等於1（cursor1必然大於B[base2]），從而推出len2 > 0。

當傳入的比較方法返回有問題時，會破壞以上推論，以出現問題的程式碼為例，當傳入兩個相等值時，返回-1（交換引數後還是返回-1，違背了之前的要求）。過程如下所示：

1.      歸併前的A段和B段

2.      用B段的起點和A段的終點互相切割之後，由於compare方法的問題，A段中的1和2位置的5被保留，破壞了A段中所有值都大於B[base2]的條件

3.      之後是普通的歸併過程

----à

4.      之後由於連續的A段大於B段，觸發了切割，B段的cursor2將A段切割到cursor1的位置；當用cursor1對B段進行切割時，由於compare方法的問題，gallopLeft會返回0，從而導致len2值等於0，引起報錯。

後續

1.      測試環境的JDK版本需要和線上環境保持一致

2.      排查程式碼，修復此類問題