选 hashmap 适合快速插入和查询，平均时间复杂度 o(1)，适用于缓存、计数、去重；treemap 适用于按键排序、范围查询等场景，时间复杂度 o(log n)；需根据实际操作需求选择。
插入和查询快到飞起？选 HashMap 就对了
如果你只是想存键值对、快速查某个 key 对应的 value，或者做缓存、计数、去重这类操作，HashMap 几乎总是更优解。它平均时间复杂度是 O(1)，而 TreeMap 是稳定的 O(log n)——10 万条数据时，HashMap 插入通常在几毫秒内完成，TreeMap 可能要多花 3–5 倍时间。
常见错误现象：
• 把 TreeMap 当成“带排序的 HashMap”直接替换，结果接口响应慢了一大截；
• 没意识到 HashMap 的遍历顺序不保证（哪怕你看到是按插入顺序，那也只是当前 JDK 实现的巧合，不是契约）。
实操建议：
• 键类型必须重写 hashCode() 和 equals()，否则 put()/get() 会失效；
• 如果已知数据量，用 new HashMap(initialCapacity) 预设容量，避免多次扩容；
• 允许 null 键（仅一个）和任意数量 null 值，TreeMap 连 null 键都不让插，会抛 NullPointerException。
需要按键排序或范围查询？TreeMap 不是备选，是刚需
当业务逻辑依赖“升序遍历”“找大于某 key 的第一个元素”“取 [fromKey, toKey) 子映射”时，TreeMap 是唯一原生支持的 Map 实现。它背后是红黑树，天然有序，且提供 subMap()、headMap()、tailMap() 等方法，HashMap 做不到也不该硬套。
使用场景举例：
• 实时排行榜（按分数排序，取 topN）；
• 时间序列聚合（key 是 LocalDateTime，查某时间段内的所有记录）；
• 权限路由表（按路径前缀最长匹配，用 floorKey() 找最近祖先）。
实操建议：
• 键类必须实现 Comparable，或构造时传入 Comparator，否则运行时报 ClassCastException；
• 不要试图给 TreeMap 调优容量或负载因子——它没有这些参数，红黑树自己维持平衡；
• 注意：TreeMap 的 keySet() 返回的是 NavigableSet，支持 higher()、lower() 等导航操作，别只当普通 Set 用。
线程安全不是它们的义务，别指望自动加锁
HashMap 和 TreeMap 都是非线程安全的。多线程并发读写时，HashMap 可能无限循环（JDK 7）、扩容错乱（JDK 8+），TreeMap 则可能抛 ConcurrentModificationException 或返回不一致结果。
实操建议：
• 单纯读多写少：用 Collections.synchronizedMap(new HashMap()) 或 Collections.synchronizedSortedMap(new TreeMap())；
• 高并发读写：优先选 ConcurrentHashMap（但注意它不排序）；
• 既要并发又要有序：没有“开箱即用”的替代品，ConcurrentSkipListMap 是最接近的选项（基于跳表，支持排序与并发，但 API 略有差异）。
别被“有序”骗了：LinkedHashMap 有时才是真·平替
如果真正想要的是“插入顺序”或“访问顺序”，而不是“按键自然顺序”，TreeMap 是重锤砸蚊子。比如实现 LRU 缓存、保持配置项加载顺序、调试时希望遍历顺序可预测——这时 LinkedHashMap 更轻量、更快，还支持 accessOrder = true 自动维护最近访问顺序。
立即学习“Java免费学习笔记（深入）”；
容易踩的坑：
• 误以为 TreeMap 能保留插入顺序（它只按 key 排序，和插入无关）；
• 在不需要排序的场景下，为“看起来更规范”而强行用 TreeMap，结果拖慢性能又增加 null 安全风险。
实操建议：
• 检查需求文档里的“有序”到底指什么：是“按 key 大小排”？还是“按我 put 的顺序排”？前者选 TreeMap，后者选 LinkedHashMap；
• LinkedHashMap 构造函数第 3 个参数 accessOrder 默认 false，设为 true 才启用 LRU 行为。
真正难的不是记清两者的区别，而是每次写 Map 声明前，花三秒问一句：我接下来要对这个 map 做什么操作？只查、只改、只遍历，还是得按 key 排着来、切着用？答案一出来，选择就不再模糊。
