JDK不同版本的Collections.Sort方法实现

一句话总结：

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.      排查代码，修复此类问题