TreeMap是唯一支持高效范围查询的有序Map，适用于日志归档、排行榜、前缀补全等场景；它强制排序、不支持null键、非线程安全，性能代价换来的是subMap等动态视图能力。
需要按键自动排序且频繁范围查询的场景
TreeMap 不是“能排序”的 Map，而是“必须排序”的 Map——它内部强制依赖键的顺序性来维持红黑树结构。所以如果你的业务逻辑天然需要按时间戳、分数、字典序等维度做 subMap、headMap 或 tailMap 查询，TreeMap 就不是“可选”，而是“唯一合理选择”。
- 日志系统按毫秒级时间戳归档：用
subMap(startTime, endTime)直接拿到某分钟内的所有日志条目，不用遍历全量数据 - 用户积分排行榜实时更新：插入新积分时自动落位，
firstKey()拿最高分，tailMap(threshold)快速筛选 VIP 用户（积分 ≥ 10000） - 前缀自动补全：存词典用
TreeMap，输入 "app" 时调用tailMap("app")，再遍历前 10 个即可返回 "apple"、"application" 等候选
不能用 HashMap 替代的排序需求
有人试图用 HashMap + 每次 new ArrayList(map.keySet()).sort(...) 来模拟有序，这在数据量稍大或写入频繁时会立刻暴露问题：排序是 O(n log n)，而 TreeMap 的单次插入/删除只是 O(log n)。更关键的是，这种手动排序无法支持原子级的范围视图。
- 错误做法：
Collections.sort(new ArrayList(map.keySet()))—— 每次都要重建列表、排序，且结果不可复用 - 正确做法：直接用
TreeMap，subMap返回的是原 map 的动态视图，增删 key 会实时反映在子视图中 - 注意：如果排序依据是对象字段（如
User.age），必须确保 key 类型实现Comparable，或显式传入Comparator.comparing(User::getAge)
null 键和线程安全是两个高频翻车点
TreeMap 对 null 键零容忍——哪怕 comparator 能处理 null，底层比较逻辑仍会在 compare(key, key) 自检时抛 NullPointerException；而线程不安全不是“偶尔出错”，是并发 put/remove 可能直接破坏红黑树结构，导致死循环或 ConcurrentModificationException。
- 避免
null键：插入前加Objects.requireNonNull(key)，或用 Optional 包装 key 类型 - 多线程下别自己加锁同步整个 map（性能差），改用
Collections.synchronizedSortedMap(new TreeMap())，但注意：它的subMap等视图方法**不自动同步**，需额外手动同步块包裹 - 若需高并发 + 排序，
ConcurrentSkipListMap是更优替代（同样 NavigableMap，线程安全，但基于跳表而非红黑树）
性能取舍：log n 不等于慢，但得清楚代价在哪
TreeMap 的 O(log n) 查找确实比 HashMap 的均摊 O(1) 慢，但这个“慢”只在单次操作上可测；真正影响系统的，往往是它带来的“能力溢价”：比如一次 subMap 节省了 99% 的扫描开销，或者避免了定时重建排序缓存的复杂度。
立即学习“Java免费学习笔记（深入）”；
- 小数据量（
- 大数据量 + 高频随机读：确认是否真需要排序——如果只是偶尔排序展示，用 HashMap + Stream.sorted() 更轻量
- 注意内存：TreeMap 每个节点含 left/right/parent/color 四个引用，比 HashMap Node 多约 24 字节，千万级数据时差几百 MB
