TreeMap适用于需键有序、范围查询与导航操作的真实场景：实时排行榜、时间序列索引、字典补全、资源配额管理；其红黑树结构保障动态有序和O(log n)范围视图，避免遍历过滤开销。
TreeMap适合哪些真实业务场景
TreeMap不是“为了排序而排序”的玩具类，它在需要键有序 + 范围操作 + 导航能力的场景中不可替代。典型用例包括：
- 实时排行榜：按分数（
Integer键）升序/降序维护玩家排名，用lastEntry()拿最高分，subMap(low, high)查前100名 - 时间序列数据索引：以
Instant或Long（毫秒时间戳）为键存储日志、监控点，用tailMap(startAt)快速拉取某时刻之后所有记录 - 字典/自动补全后端：键为
String，自然排序下ceilingKey("abc")可找字典中第一个 ≥ "abc" 的词条 - 资源配额管理：键为用户ID（
String），值为已用额度，用headMap("user100")批量查某批次用户配额
注意：如果只是“插入后一次性排序再遍历”，用 HashMap + TreeSet 或 stream().sorted() 更轻量；TreeMap 的价值在于持续写入仍保持有序。
为什么必须用红黑树，而不是先存再排序
TreeMap 的底层是红黑树，这不是为了炫技，而是解决两个硬性需求：
-
动态有序性：每调用一次
put()，它自动完成插入+平衡（旋转+着色），保证任意时刻entrySet()遍历都严格按键升序——无需你手动Collections.sort() -
O(log n) 范围视图：
subMap(from, to)不是复制数据，而是返回一个“视图”（SubMap实例），底层共享原树结构，增删改会同步反映，内存和时间开销远低于每次新建TreeMap或过滤HashMap
反例：用 HashMap 存 10 万条记录，每次查“2025-01 到 2025-12”的数据，得遍历全部 + 时间判断 → O(n)；TreeMap 直接 subMap(startKey, endKey) → O(log n) + O(结果集大小)。
立即学习“Java免费学习笔记（深入）”；
常见踩坑：null 键、Comparator 写错、线程不安全
这三个问题几乎每个初用 TreeMap 的人都会撞上：
-
NullPointerException：TreeMap 明确禁止null键（value允许为null）。一旦put(null, "value")，立刻抛异常。修复方式：插入前判空，或统一用Optional包装键 - 自定义
Comparator返回 0 但键实际不等：例如写成(a, b) -> a.length() - b.length()，当两个不同字符串长度相同时，TreeMap 认为它们“相等”，后插入的会覆盖前一个。正确写法必须保证“相等性一致”：return Integer.compare(a.length(), b.length()) != 0 ? ... : a.compareTo(b) - 多线程并发修改：TreeMap 本身非线程安全。多个线程同时
put()可能导致ConcurrentModificationException或数据丢失。不要用Collections.synchronizedSortedMap()做简单包装——它只锁单个方法，subMap()返回的视图仍可能被并发修改。真要线程安全，请用ConcurrentSkipListMap（跳表实现，支持并发）
对比 HashMap：别为“看起来有序”选错结构
很多人看到 TreeMap 输出是排序的，就默认它“比 HashMap 好”。但代价很实在：
- 性能：
put()/get()是 O(log n)，HashMap 是 O(1) 平均。100 万数据，log₂(10⁶) ≈ 20，而哈希查找常数级 —— 差一个数量级 - 内存：红黑树每个节点含
left/right/parent/color字段，比 HashMap 的 Node 多存 3 个引用 + 1 个布尔值 - 限制：键必须可比较（实现
Comparable或传Comparator），HashMap 对键唯一要求是hashCode()和equals()
所以真正该问的不是“要不要排序”，而是“排序是否参与核心逻辑”。如果只是打印报表时想看整齐，用 new TreeMap(map) 临时转一下就行；如果业务逻辑依赖 floorKey() 或 tailMap()，那 TreeMap 就是刚需。
