绝大多数场景应优先选用 HashMap，因其平均时间复杂度 O(1)、支持 null 键值且无序特性契合多数业务；仅当需 key 自然排序或范围查询时才用 TreeMap。
什么时候该用 HashMap，而不是 TreeMap
绝大多数场景下，HashMap 是首选。它平均时间复杂度为 O(1)，支持 null 键和值，且不保证顺序——这恰恰是多数业务逻辑需要的“快而无序”。TreeMap 只在你需要按 key 自然排序或范围查询（如 subMap、headMap）时才值得引入，但它底层是红黑树，所有操作都是 O(log n)，且不接受 null 键（会抛 NullPointerException）。
常见错误：为图省事把 TreeMap 当作“自动排序的 HashMap”来用，结果发现插入 10 万条数据慢了 3 倍，还因为 key 为 null 崩溃了。
- 如果只是遍历时想按插入顺序，改用
LinkedHashMap，不是TreeMap - 如果 key 是自定义类，
HashMap要重写hashCode()和equals()；TreeMap则要求实现Comparable或传入Comparator -
TreeMap的floorKey、ceilingKey等方法无法在HashMap中直接替代，别硬套
ConcurrentHashMap 真的线程安全，但不是万能锁
ConcurrentHashMap 支持高并发读写，但它只保证单个操作（如 put、get）原子性，不保证复合操作线程安全。比如 if (!map.containsKey(k)) map.put(k, v) 仍是竞态条件，必须用 computeIfAbsent 或显式加锁。
性能影响：JDK 8+ 的 ConcurrentHashMap 使用 CAS + synchronized 分段锁（实际是 Node 数组上的桶级锁），比 Hashtable 或 Collections.synchronizedMap 高效得多；但若写操作占比超过 20%，仍可能因扩容竞争拖慢整体吞吐。
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
立即学习“Java免费学习笔记（深入）”；
- 不要用
ConcurrentHashMap存放需要全局一致状态的对象（如计数器累加），优先考虑LongAdder或AtomicInteger -
size()返回的是近似值，高并发下可能不准；如需精确大小，用mappingCount() - 迭代器弱一致性：遍历时允许其他线程修改，不会抛
ConcurrentModificationException，但看不到修改后的新增元素
LinkedHashMap 的 accessOrder 模式容易被误用
LinkedHashMap 默认按插入顺序维护节点，设 accessOrder = true 后则按访问顺序（get、put 都算）排列。这个特性常被用于手写 LRU 缓存，但要注意：removeEldestEntry 回调只在每次 put 后触发，get 不会触发淘汰——这意味着单纯靠访问频次驱逐老数据，必须自己封装 get 方法并手动检查 size。
Map<String, String> cache = new LinkedHashMap<>(16, 0.75f, true) {
@Override
protected boolean removeEldestEntry(Map.Entry<String, String> eldest) {
return size() > 100; // 注意：这只对 put 生效
}
};
- 如果业务需要“访问即刷新 + 定长淘汰”，必须重写
get并调用put(eldest.getKey(), eldest.getValue())触发链表重排和淘汰判断 -
accessOrder = true下，keySet()迭代顺序反映的是最近访问顺序，不是插入顺序，别当成普通有序 Map 用 - 该模式下
get操作不再是 O(1)，而是 O(1) 查哈希表 + O(1) 链表调整，但总体仍可接受
Map 实现类的序列化与兼容性陷阱
HashMap、LinkedHashMap、TreeMap 都实现了 Serializable，但反序列化时若类结构变更（如字段删减、类型变更），极易失败。更隐蔽的问题是：ConcurrentHashMap 在 JDK 7 和 JDK 8+ 序列化格式不兼容——JDK 7 写出的流，JDK 8 无法正确读取，会抛 InvalidClassException。
另一个坑：EnumMap 和 IdentityHashMap 虽然也是 Map 实现，但它们不基于 hashCode/equals，而是依赖 == 或枚举 ordinal，跨进程或持久化时几乎无法通用，除非你明确控制两端运行环境。
- 跨服务传输 Map 数据，别直接序列化，统一转成
Map<String, Object>后走 JSON（如 Jackson） -
TreeMap反序列化时若 key 类型未实现Comparable或没传Comparator，会抛InvalidObjectException -
LinkedHashMap的序列化包含完整的双向链表结构，体积比HashMap大约多 20%，大数据量时需权衡
TreeMap，却没意识到前端或 SQL 层排序更合适；也有人一上并发就切 ConcurrentHashMap，却忘了读多写少时 Collections.synchronizedMap 更轻量。 
