绝大多数业务场景应优先选用HashMap，因其O(1)平均时间复杂度、支持null键值、灵活高效；需排序选TreeMap，需有序遍历选LinkedHashMap，切勿滥用TreeMap替代HashMap。
绝大多数业务场景下，直接选 HashMap 就对了。它快、灵活、支持 null 键值，而且“无序”反而是优势——多数逻辑根本不依赖遍历顺序。
需要快速查、增、删，且不关心顺序
比如用户会话缓存、配置项映射、ID 与对象的关联查找等。这些操作的核心诉求是 O(1) 平均时间复杂度，HashMap 完全满足。它的哈希表结构在键分布合理时性能稳定，JDK 8 后还通过链表转红黑树优化了冲突场景。
- 键为 String、Integer 等常用类型时，开箱即用
- 键是自定义类？必须重写 hashCode() 和 equals()
- 若需线程安全，别用 Collections.synchronizedMap 包装，改用 ConcurrentHashMap
需要按键自然排序或做范围查询
只有这时才考虑 TreeMap。它底层是红黑树，天然支持按 key 排序遍历，并提供 subMap、headMap、floorKey、ceilingKey 等有序操作。
- key 必须实现 Comparable，或构造时传入 Comparator
- 不接受 null 键（运行时抛 NullPointerException）
- 所有操作都是 O(log n)，数据量大时比 HashMap 慢，但稳定性高
- 别把它当“自动排序的 HashMap”用——插入顺序无关，只看比较结果
想保持插入或访问顺序，但不需要排序逻辑
比如实现 LRU 缓存、记录操作日志顺序、导出配置时希望字段顺序和代码中一致。这时 LinkedHashMap 更合适。
立即学习“Java免费学习笔记（深入）”；
- 构造时第三个参数设为 true 可启用访问顺序（LRU 模式）
- 内存开销比 TreeMap 小 20%～30%，put/get 仍是 O(1)
- 它不提供任何排序能力，哪怕你按数字大小插入，遍历也不会按数值序
- 序列化后顺序可保留，但反序列化时要注意 key 的 equals/hashCode 实现是否正确
容易踩的坑
把 TreeMap 用在本不需要排序的地方，比如存 HTTP 请求头（key 是字符串如 "Content-Type"）、系统开关配置（"enable.retry"、"timeout.ms"）。这些 key 本身无内在顺序，强行排序纯属浪费 CPU 和内存。
- 误以为 TreeMap 能保持插入顺序 → 实际只认比较结果
- 用 null 作 key 放进 TreeMap → 直接崩溃
- 在高并发下直接用未加锁的 TreeMap → 不是线程安全的
- 用 if (!map.containsKey(k)) map.put(k, v) 这种复合操作 → 即使是 ConcurrentHashMap 也不安全，该用 computeIfAbsent
