TreeMap 默认按键的自然顺序排序，要求键实现Comparable接口，否则需传入Comparator；底层为红黑树，支持O(log n)增删查及NavigableMap范围查询功能。
TreeMap 是怎么排序的？
TreeMap 的键默认按自然顺序排序，前提是键类型实现了 Comparable 接口（比如 Integer、String）。如果你传入自定义类作 key，没实现 Comparable，或者想换排序逻辑，就得显式传 Comparator 构造器。
常见错误现象：ClassCastException: java.lang.String cannot be cast to java.lang.Comparable——这通常是因为你用了 null key，或 key 类型本身不可比较且没配 Comparator。
- 不支持
null作为 key（会抛NullPointerException），但 value 可以是null -
TreeMap底层是红黑树，所以get/put/remove时间复杂度都是 O(log n)，比HashMap慢一点，但换来的是有序 - 如果只是临时排序，别为了“看起来有序”硬上
TreeMap；纯查改多、不关心顺序，HashMap更合适
如何用好 NavigableMap 提供的范围查找功能？
TreeMap 实现了 NavigableMap，这才是它真正区别于 HashMap 的价值所在：能快速找“比某个 key 小的最大键”、“大于等于某 key 的第一个条目”这类操作。
使用场景：分段统计、时间窗口查询、排行榜截取前 N 名、配置项按版本号匹配最近生效项。
立即学习“Java免费学习笔记（深入）”；
-
floorEntry(key)返回 ≤ key 的最大键值对，key 不存在时返回 floor 键对应的 entry -
higherEntry(key)返回 > key 的最小键值对，比ceilingEntry更严格（不包含等于） - 注意
subMap(fromKey, toKey)是半开区间：包含fromKey，不包含toKey；想包含两端，得用subMap(fromKey, true, toKey, true) - 所有导航方法返回
null表示无匹配项，不是异常，别直接解包
TreeMap 和 HashMap 在迭代顺序上有什么实际差异？
HashMap 迭代顺序不确定（Java 8 后是插入顺序 + 哈希扰动，但不保证）；TreeMap 迭代一定是按键升序。这点在日志打印、配置 dump、生成可预测 JSON 时很关键。
容易踩的坑：把 TreeMap 当成“自动去重+自动排序”的万能容器，结果发现 value 是对象引用，修改 value 内容后，TreeMap 不会重新排序——排序只依赖 key，和 value 完全无关。
- 遍历时用
entrySet()而不是keySet()再 get，避免额外 log n 查找 - 如果需要降序遍历，别手动反转 list，用
descendingMap()，它返回一个视图，O(1) 开销 - 并发环境下不能直接用
TreeMap，ConcurrentSkipListMap是线程安全替代品，但不继承TreeMap
什么时候不该用 TreeMap？
当你的 key 是 double 或 float，或者用浮点数做范围查询时，要格外小心。浮点精度问题会让 floorKey(0.3) 找不到明明 put 过的 0.1 + 0.2 对应的 entry——因为 0.1 + 0.2 != 0.3 在二进制浮点下成立。
其他典型误用：
- 只用一次排序（比如构建完就转成 list），却用
TreeMap插入 N 次，总成本 O(N log N)，不如ArrayList+Collections.sort()的 O(N log N) 且常数更小 - key 是带毫秒时间戳的
Long，但业务上只要“分钟级精度”，结果因毫秒差异导致大量“看似相同”的 key 被当成不同键处理 - 频繁调用
size()——虽然TreeMap维护了 size 字段，但某些老 JDK 版本（如 Java 6）里它是遍历计数，O(n)；不过现代 JDK 都是 O(1)
红黑树的平衡逻辑藏在每次增删里，看不见，但会影响性能拐点。键比较越慢（比如长字符串、深嵌套对象），TreeMap 的代价就越明显——这时候该考虑是否真需要实时有序，还是可以接受定时重建索引。
