Android 面试走到高阶环节，考察方式会从“问知识点”切换成“沿着知识点连续追问”。TreeMap 与排序就是常被选中的切入口：一层层问下去，知识的边界在哪里，候选人自己最清楚。这题的答案可以很短，也可以很长——能不能结合真实项目里的多字段排序讲出层次，正是分水岭。
先把结论放在前面：TreeMap 用红黑树（一种自平衡的二叉搜索树）承载键值，key 按键的顺序排列，增删查都是 O(log n)，并支持首/尾/上下界与范围查询（firstKey、lastKey、ceilingKey、subMap 等）。排序依赖 Comparable 自然序或外部 Comparator；它和 HashMap 的根本区别在于“有序”，代价是多出的树平衡开销与 key 必须可比较。 这题要答好，得把“怎么比、比错了会怎样、范围查询怎么用”讲透。
机制拆解
讲清排序的来源与树的平衡。每次 put 先按比较器在树里找到插入位置，再按红黑树规则做旋转与染色保持平衡，保证树高约 2·log(n+1)，从而使操作稳定在 O(log n)。比较逻辑来自两条路：key 实现 Comparable 走自然序，或构造时传入 Comparator 走外部序。 范围查询（如 subMap、tailMap）直接利用树的有序性裁剪出一段连续区间，比“先全遍历再 filter”高效得多。
这些坑的正确绕法
最常见的坑是 comparator 里用减法比较 int。例如 (a, b) -> a.score - b.score，当两者之差超过 int 范围时会整数溢出，排序结果错乱且极难复现。正确做法是 Integer.compare(a, b) 或 Comparator.comparingInt，把比较交给标准库。
其次是对不可比较的对象直接 put 抛 ClassCastException。TreeMap 要求 key 能比较，若 key 没实现 Comparable 且构造时没给 Comparator，插入第一个元素就会抛异常；很多人误以为和 HashMap 一样“什么都能放”，结果一上线就崩。
还有一个更隐蔽的坑：compareTo / compare 的结果没有和 equals 保持一致。按 TreeMap 的契约，视为“相等”的两个 key（比较返回 0）会被当成同一个键，即使 equals 为 false 也会覆盖；这会让“逻辑不同但比较相同”的对象悄悄丢掉，排查起来非常迷惑。
代码里见真章
看一段能直接跑的代码，把上面的机制落到具体写法上：
// TreeMap 与排序
TreeMap<Integer, String> m = new TreeMap<>();
m.put(3, "c");
m.put(1, "a");
System.out.println(m.firstKey() + ".." + m.ceilingKey(2)); // 有序 API
// 多字段排序：先按 x，再按 y
List<P> list = ...;
list.sort(Comparator.comparingInt(P::getX).thenComparing(P::getY));
// Comparable 自然序 vs Comparator 外部比较器
这段代码值得盯两处：第一处，TreeMap 的 firstKey / ceilingKey 等是有序结构才给得出的能力，HashMap 做不到；第二处，Comparator.comparingInt().thenComparing() 是安全的多字段排序写法，避免手写减法溢出。面试讲到这一层，基本就稳了。
这题在面试里怎么问、怎么答
“请简单介绍一下 TreeMap 与排序，它在 Android 开发中起什么作用？”一句话：按键有序的映射，擅长范围查询与排序输出。在 Android 里，区间筛选（如按时间戳取一段时间内的消息）、排行榜、字典序展示都用到它的有序性。如果要把约定沉淀成团队规范，建议加一条：比较一律用 Integer.compare / comparingInt，不推荐手写减法比较。
“TreeMap 的底层原理是什么？能不能详细说一下？”从红黑树的自平衡讲起，说明为什么增删查是 O(log n)，再讲 Comparable 与 Comparator 两条排序来源，最后落到范围查询如何利用有序性。机制别空讲，配核心代码最稳。
“在使用时遇到过什么问题？”客观地说实案例：某排行榜偶发顺序错乱，定位为 comparator 用 score1 - score2 在极端分数差下溢出；换成 comparingInt 后稳定。量化的修复效果最加分。
“和相关的替代方案相比，有什么优劣？”与 HashMap 比，TreeMap 多有序性但慢一档（O(log n) 对比近似 O(1)），且不接受任意 key；与 LinkedHashMap 比，TreeMap 按键比较排序、后者按访问序；与排序后的 List 比，TreeMap 支持动态增删仍保持有序。选型就按“要不要持续有序 + 要不要范围查询”来。 选型时要把“key 必须可比较、比较需与 equals 一致”这类代价摆到台面上，再决定是否引入。
再补一个工程上值得讲清的点：Comparator 的“链式组合”远不止两个字段。 比如联系人列表要先按部门、再按职级、再按入职时间，可以写成 comparing(P::dept).thenComparing(P::level).thenComparing(P::hireDate)，标准库会按顺序短路比较，既安全又可读；要反向就在某一段后接 .reversed()，但注意 reversed() 只反转紧邻的那一层，链式里位置摆错会得到反直觉的结果。 另一个常被追问的是 null 处理：默认 Comparator 遇到 null 会抛空指针，需要用 Comparator.nullsFirst / nullsLast 显式声明 null 的先后，这在从数据库或接口拿到的数据可能缺字段时尤其重要。理解了链式组合与 null 策略，多字段排序就不再靠手写一堆 if-else。
再补一个真实项目里常见的坑位：按多字段排序时，如果只把最后一个字段交给 TreeMap，而前一个字段的区分度不够，就会出现“看起来有序、实际乱序”的错觉。稳妥做法是构造一个专用的比较器，把所有参与排序的字段串成一条比较链，并在 equals 与 hashCode 里保持同样口径——因为同一组对象既要进 TreeMap 当键，又要进 HashMap 做索引时，两套契约不一致就会出问题。 另外补一个与排序相邻的考点：List.sort 用的是稳定排序（TimSort），如果排序字段有重复、却依赖原始顺序做二级排序，就必须显式把原始下标作为兜底比较项写进比较器，否则一次重构就可能让列表顺序抖动。面试里能从“排序稳定性”讲到“equals 一致性”，通常就说明真的在项目里踩过。
再补一个能体现深度的问题：为什么 TreeMap 选红黑树而不是平衡二叉搜索树（AVL）？红黑树对插入删除的调整更少，查找虽略多一次比较，但换来的是更新路径更短，在"读多写少"与"写多读少"之间取了折中；AVL 更严格平衡、查找路径更短，但每次更新可能触发更多旋转。面试能主动比较这两者，说明不是只记住了"红黑树"三个字。 同样地，ConcurrentSkipListMap 走的是跳表路线，优势是范围查询与并发友好、实现简单，但内存开销通常高于红黑树。把"红黑树 vs AVL vs 跳表"这条轴讲出来，选型题就有了横向视角。
给正在准备面试的你
把 TreeMap 画成“红黑树 + 有序 key”的结构，旁边列出 firstKey / subMap 等有序专属 API。面试中关于 TreeMap 与排序的问题，关键在于能够从原理、应用、踩坑三个层面给出有深度的回答。
再补工程案例与踩坑——应用落点是实现一个按多字段排序的联系人列表：先按部门、再按职级、最后按入职时间，并演示 null 字段的 nullsLast 处理。
复习时别孤立刷题：Iterator 与 fail-fast——相邻考点常被一起问，边界提前划清楚。
划两句重点：TreeMap 用红黑树保证按键有序、增删查 O(log n)，擅长首/尾/范围查询；比较要用标准库方法，避免减法溢出，且 compare 需与 equals 一致。
下一篇聊 Iterator 与 fail-fast：并发修改异常的根源——沿着今天这条主线继续往前走。
如果这篇文章对你有帮助，欢迎点赞、在看、转发三连。你的支持就是这个系列持续更新的动力。
「Android软件开发面试·从入门到精通」连载系列
上一篇：LinkedHashMap-与-LRU：图片缓存的原型
下一篇预告：Iterator-与-fail-fast：并发修改异常的根源
有任何问题欢迎在评论区留言交流。
