java - CompareToBuilder 的这种使用是否被认为效率低下？

Question

在同行评审期间，一位开发人员似乎对实现我选择按 3 个属性排序的compareToBuilder 解决方案的想法感到震惊。他的印象是，我的类中的compareTo 方法会为每个单独的比较创建过多数量的比较器，并且应用程序会对性能造成巨大影响。他建议我使用 BeanComparator 和 ComparatorUtils 来链接比较器。

这是我的课:

public class EmployeeComparator implements Comparator<Employee> {

@Override
public int compare(Employee o1, Employee o2) {
    return new CompareToBuilder()
            .append(o1.getJobTitle(), o2.getJobTitle())
            .append(o1.getAge(), o2.getAge())
            .append(o1.getSalary(), o2.getSalary()).toComparison();
}

这是我的实现:

Collections.sort(outputRecordList, Comparator.nullsLast(new EmployeeComparator()));

但是，我实际上不知道这是不是真的。我找不到任何迹象表明这会比使用链式比较器对性能造成重大影响。我仔细研究了 apache 文档，发现这是该类的标准实现( https://commons.apache.org/proper/commons-lang/javadocs/api-3.1/org/apache/commons/lang3/builder/CompareToBuilder.html )。我唯一担心的是，通过添加“Comparator.nullsLast”，我创建了一个怪物。

我在此站点上找到了 CompareToBulder 实现:

http://www.codejava.net/java-core/collections/sorting-a-list-by-multiple-attributes-example

任何解释为什么这是不好的做法或解释 CompareToBuilder 到底在做什么的帮助将不胜感激。

Answer 1

CompareToBuilder 对于您的使用来说似乎相当有效(从查看其源代码来看)。与硬编码的比较相比，它涉及一个额外的实例创建(仅包含一个 int 字段)以及append() 调用(可能由 HotSpot 编译器内联)。即使第一次比较已经决定了结果，它也必须经历所有尾部比较。

以这种方式实现它，然后对系统进行分析。如果 EmployeeComparator 花费大量时间，请再想一想:但我想更快的compareTo() 实现不会有太大帮助。