理解Comparable与Comparator的差异
使用Collections.sort方法对列表排序时，最常见的报错是ClassCastException，提示元素无法转换为Comparable。这通常是因为列表中的元素类没有实现ja va.lang.Comparable接口。Comparable接口定义了对象的自然排序规则，其compareTo方法用于比较当前对象与指定对象的顺序。如果集合元素未实现此接口，排序方法就无法知晓如何比较它们的大小。
另一种情况是，即使元素类实现了Comparable接口，也可能在排序混合类型列表或使用自定义排序逻辑时遇到问题。此时，可以使用Comparator接口。Comparator是一个独立的比较器，它允许你定义与元素类自然排序不同的排序规则。通过向Collections.sort方法传入一个Comparator实例，可以灵活地指定排序逻辑，例如对字符串按长度而非字典序排序，或者对复杂对象按特定属性排序。
处理空值导致的NullPointerException
当待排序的列表中包含null元素时，调用Collections.sort可能会抛出NullPointerException。这是因为无论是Comparable的compareTo方法还是Comparator的compare方法，在尝试用null调用或与null比较时都可能引发空指针异常。处理这个问题需要根据业务逻辑来决定。
一种常见的处理方式是在自定义Comparator中显式处理null值。例如，可以约定将null值视为最小或最大，将其统一排在列表的开头或结尾。在compare方法中，先判断两个参数是否为null，并定义好null与非null值、以及两个null值之间的比较规则。这样可以确保排序过程的稳定性，避免运行时异常。
应对不可修改集合引发的异常
尝试对不可修改的集合进行排序时，会抛出钱nsupportedOperationException。这种情况常发生在使用Arrays.asList()方法返回的列表，或通过Collections.unmodifiableList()包装过的列表上。这些列表在结构上是固定或只读的，不支持像sort这样的修改操作。
解决方法是创建一个新的、可修改的列表副本，对这个副本进行排序。可以使用new ArrayList<>(originalList)来构造一个全新的ArrayList，然后对新列表调用Collections.sort。排序完成后，如果需要保持原集合的不可修改特性，可以再次使用Collections.unmodifiableList进行包装。这既满足了排序需求，又维护了数据封装的设计意图。
自定义Comparator的常见陷阱与修正
在实现Comparator时，必须确保比较逻辑满足自反性、对称性和传递性等契约，否则可能导致排序结果不可预测，或在某些情况下抛出IllegalArgumentException。一个典型错误是，比较器对于两个相等的对象（compare结果为0）和不相等的对象，其排序结果不一致，违反了契约。
另一个陷阱涉及在比较器中使用减法来比较整数值。对于极大或极小的整数，减法可能导致溢出，产生错误的比较结果。正确的做法是使用Integer.compare(a, b)方法，或对于基本类型，使用条件判断返回-1, 0, 1。此外，对于可能为null的对象属性进行比较时，也需在比较器内部做好空值防护，避免深层空指针异常。
并发修改与排序后列表的稳定性
如果在排序过程中，列表被其他线程结构性修改（如添加、删除元素），可能会引发ConcurrentModificationException。虽然Collections.sort本身不是线程安全的，但在单线程环境下，也需注意不要在排序时（例如在Comparator的逻辑中）意外修改原列表。
此外，需要了解Collections.sort使用的是稳定排序算法（在Ja va中，对于对象列表，通常是TimSort的变体）。这意味着相等元素的相对顺序在排序后会得到保留。这一特性在某些场景下很有用，例如先按姓氏排序，再按名字排序，可以保持同姓氏下的原始名字顺序。明确这一点有助于理解排序结果，并避免不必要的额外排序操作。
