TreeMap通过红黑树实现键的有序性，插入时依据Comparable或Comparator比较键，确保无重复键并维持O(log n)操作效率，适用于需排序或范围查询场景，而HashMap则适合仅需快速存取的无序场景。
Java中TreeMap的排序，说到底，就是Java利用一种非常巧妙的数据结构——红黑树——来维护键的有序性。无论是基于键的自然顺序，还是我们自己定义的比较规则，核心都在于那棵自平衡的二叉查找树，它确保了键始终保持排序状态，并且能高效地进行插入、查找和删除操作。
解决方案
TreeMap的排序原理，其实是它内部红黑树数据结构运作方式的直接体现。红黑树是一种自平衡的二叉查找树，它在插入和删除节点时，通过特定的着色和旋转规则来保持树的平衡，从而确保了所有操作的时间复杂度都维持在O(log n)。
当一个键值对被插入TreeMap时，TreeMap会根据键的比较结果来决定这个新节点在树中的位置。如果键实现了
Comparable接口，TreeMap就会使用它的
compareTo()方法进行比较；如果创建TreeMap时提供了
Comparator对象，那么就会使用
Comparator的
compare()方法。
这个比较过程是这样的：新键会从红黑树的根节点开始比较。如果新键小于当前节点，它会尝试插入到当前节点的左子树；如果新键大于当前节点，则尝试插入到右子树。这个过程会一直重复，直到找到一个合适的位置。如果在这个过程中，新键被判定为与树中某个现有键“相等”（即
compareTo()或
compare()返回0），TreeMap就不会插入新键，而是会替换掉旧键对应的值（除非是
putIfAbsent等特殊方法）。
立即学习“Java免费学习笔记（深入）”；
这种基于比较的插入机制，结合红黑树的自平衡特性，使得TreeMap在任何时候都能保持键的有序性。你遍历TreeMap时，无论是使用迭代器还是其他方式，键都会按照它们被比较的顺序（升序）返回。这与HashMap那种无序、基于哈希的存储方式形成了鲜明对比。
TreeMap如何维护键的顺序并处理重复？
TreeMap的“规矩”很明确：它只认一个键。当你尝试插入一个与现有键在比较上被判定为“相等”的新键时（即
compareTo或
compare返回0），TreeMap不会新增一个条目。它会认为这是一个重复键，通常是替换掉旧键对应的值，而不是增加一个新节点。这种行为，正是它通过红黑树结构，在插入时就进行比较和定位的结果。
想象一下，你往一个大箱子里放书，但你希望这些书总是按作者名字的首字母排序。TreeMap就是这样一个智能箱子。每当你放一本新书（一个键值对）进去，它不是随便一扔，而是会根据书名（键）的字母顺序，找到一个合适的位置放进去。这个“找位置”和“放进去”的过程，背后就是红黑树在默默工作。它不仅保证了书的顺序，还确保了箱子里不会有两本完全一样的书（键）。如果来了本同名的书，它会认为是你更新了那本书的内容，而不是增加一本新书。
何时选择Comparable，何时选择Comparator？
这就像是给你的数据选择一套“默认着装”还是“定制礼服”。
Comparable是为你的类提供一个“自然”的排序方式，就像一个人默认的身高体重。一旦实现了，这个类就有了自己的排序标准。比如，
String类自然就实现了
Comparable，所以字符串可以按字典序排序。如果你希望你的自定义对象有一个“理所当然”的排序方式，那么就让它实现
Comparable接口，并重写
compareTo方法。
而
Comparator则更灵活，它像一个独立的裁判，可以在不修改原有类的情况下，定义各种各样的排序规则。比如，你可能想按年龄排序，又想按姓名排序，或者先按年龄再按姓名。这时候，
Comparator就是你的多功能工具。它特别适合以下场景：
-
为没有实现
Comparable
的类排序：你无法修改第三方库的类。 -
提供多种排序方式：比如，一个
Person
类，你可能需要按年龄排序，也可能需要按姓名排序。 - 排序规则是动态的或复杂的：例如，根据用户选择的字段进行排序。
举个例子，如果你有一个
Student类，想按分数降序排序：
public class Student {
String name;
int score;
public Student(String name, int score) {
this.name = name;
this.score = score;
}
// 省略getter/setter
}
// 使用Comparator进行分数降序排序
Comparator scoreComparator = (s1, s2) -> Integer.compare(s2.score, s1.score);
TreeMap studentMap = new TreeMap<>(scoreComparator);
studentMap.put(new Student("Alice", 90), "Class A");
studentMap.put(new Student("Bob", 95), "Class B");
studentMap.put(new Student("Charlie", 88), "Class C");
// 遍历时，Bob -> Alice -> Charlie TreeMap与HashMap，场景选择的考量
选择
TreeMap还是
HashMap，常常让开发者纠结。简单来说，如果你需要你的键值对总是保持有序，或者你需要进行范围查询（比如找出所有键在A到Z之间的条目），那么
TreeMap就是你的不二之选。它虽然在单次操作上比
HashMap稍慢（O(log n) vs O(1)平均），但它提供了有序的便利。在需要对数据进行排序、遍历或者进行“查找下一个/上一个”操作时，
TreeMap的优势就非常明显了。
而
HashMap，它就像一个高效的杂物柜，东西一放进去就忘了顺序，但你想找任何一件东西，它都能以极快的速度（平均O(1)）给你找出来。如果你只关心快速的存取，对顺序没有要求，那
HashMap无疑是更优的选择。它的内部实现基于哈希表，通过计算键的哈希值来快速定位存储位置，效率极高。
在我的开发经验里，很多时候，我们其实并不需要键的严格排序，这时盲目选择
TreeMap反而会引入不必要的性能开销。但当业务逻辑真的依赖于键的顺序时，
TreeMap的价值就凸显出来了，它能让你的代码逻辑清晰很多，避免了额外排序的步骤。选择哪一个，最终还是取决于你的具体需求和对性能的权衡。
