Java Collator 怎样用 CollationKey 加速重复排序

Java 做自然语言排序时，直接把字符串交给 String.compareTo 往往不够。Collator 能根据 Locale 和 strength 处理语言相关的顺序；如果同一批文本要反复排序或比较，应该先用同一个 Collator 生成 CollationKey，之后让排序器比较 key。这样会把“分析原字符串”的成本集中到生成阶段，重复比较只处理已经准备好的 key。

官方 API 地址：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/text/Collator.html

本文不把 CollationKey 说成所有排序都更快：只比较一次时，直接调用 Collator.compare 通常更合适；key 的生成成本要在多次比较中才能摊薄。

先确定 Locale 和排序强度

Collator 是面向 Locale 的比较器，可以用 Collator.getInstance(Locale) 获取。排序强度决定哪些差异参与顺序，例如 PRIMARY、SECONDARY、TERTIARY 和 IDENTICAL 的含义会随语言规则解释。业务先确定“大小写和重音是否视为同类”，再固定 Collator 的配置；不能生成 key 后再临时改变规则。

同一篇文章中的 key 必须来自同一个 Collator 实例，至少要保证 Locale、strength 和 decomposition 等规则一致。官方文档明确指出，不同 Collator 生成的 CollationKey 不能互相比较。

把字符串一次性转换成 CollationKey

CollationKey 代表某个字符串在特定 Collator 规则下的排序形式。它不能直接构造，只能通过 collator.getCollationKey(source) 获取。工程上通常保留一个小对象，同时保存原文和 key：排序依赖 key，最终展示仍取原文。

import java.text.CollationKey;
import java.text.Collator;
import java.util.ArrayList;
import java.util.Comparator;
import java.util.List;
import java.util.Locale;

public class CollationKeySortDemo {
    // 保留原文，避免排序完成后还要从 key 反查显示文本
    static final class RankedText {
        final String source;
        final CollationKey key;

        RankedText(String source, Collator collator) {
            this.source = source;
            // key 绑定创建它的 Collator，后续不要混用其他实例生成的 key
            this.key = collator.getCollationKey(source);
        }
    }

    public static void main(String[] args) {
        // 固定规则后再生成全部 key，排序过程中不要修改 collator 的配置
        Collator collator = Collator.getInstance(Locale.US);
        collator.setStrength(Collator.PRIMARY);

        List items = new ArrayList();
        for (String source : List.of("Résumé", "resume", "Zoo", "apple")) {
            // 每个字符串只生成一次 key，供后续多轮排序复用
            items.add(new RankedText(source, collator));
        }

        // 只比较同一个 collator 生成的 key，原文仍作为展示字段
        items.sort(Comparator.comparing(item -> item.key));

        for (RankedText item : items) {
            // 输出顺序由 CollationKey 决定，而不是 String 的 Unicode 码点顺序
            System.out.println(item.source);
        }
    }
}

这个例子把“生成 key”和“排序”分开了。若同一组 items 还要按筛选条件多次重排，key 可以继续复用；若某条原文被修改，就必须为新文本重新生成 key，不能把旧 key 留在缓存里。

重复排序时为什么能摊薄成本

直接调用 Collator.compare(a, b) 时，比较器会按需要检查两个字符串。排序算法会对元素进行多次比较，同一字符串可能参与很多次比较。getCollationKey 则先完整检查字符串并生成可比较的表示，后续 compareTo 可以在 key 之间完成。

因此，收益来自“同一批字符串会被比较很多次”，不是来自 key 本身永远比 compare 快。生成 key 需要内存和一次预处理；数据只比较一次、字符串很短，或排序不会重复发生时，预处理成本未必值得。

单次比较和重复排序应该怎样选

可以用下面的速查表做决定：

不要把 key 的字节数组当作业务主键，也不要把来自不同排序规则的 key 放进同一棵排序树。toByteArray() 可以用于表示 key，但文章中的排序仍应使用 CollationKey.compareTo，让 API 保留其规则语义。

缓存和并发边界要一起处理

如果 key 放进缓存，缓存键至少要包含原字符串和排序规则版本。Locale、strength 或 decomposition 改变后，旧 key 不能继续使用。若应用只对固定列表做一次排序，局部生成 key 会比建立长期缓存更简单。

并发服务还要注意 Collator 实例的共享方式。Oracle API 的实现说明提到，JDK 参考实现中的 RuleBasedCollator 在并发使用时可能出现明显线程竞争。更稳妥的做法是每个线程取得独立实例，或在应用层使用线程隔离的实例工厂；不要为了节省一个对象而把可变配置的 Collator 当成全局共享状态。

如果排序规则发生变化，应按“创建新 Collator、批量重建 key、切换索引”的顺序处理。不要在旧 key 仍被读取时直接修改原 Collator，因为读者看到的顺序可能在同一轮操作中失去一致性。

几个容易混淆的问题

CollationKey 是否一定比 Collator.compare 快？

不一定。它适合字符串会被重复比较的排序场景；单次比较或很少比较时，要把生成 key 的成本算进去，直接调用 compare 通常更直接。

可以把不同 Locale 生成的 key 放一起排序吗？

不可以。CollationKey 只能与创建它的同一个 Collator 产生的 key 比较。需要多种规则时，应分开维护数据和排序过程。

原字符串修改后只更新 source 字段可以吗？

不可以。key 仍然对应旧字符串，必须用当前规则重新生成 key，或者让不可变对象携带 source 与 key，避免出现两者不同步。

总结一下：先固定 Locale 和比较强度，再为真正需要重复排序的文本生成 CollationKey；排序时比较 key，展示时取原文。单次比较直接用 Collator.compare，规则或文本变化时重建 key，并为并发场景隔离 Collator 实例。