Map接口本质是键值映射的抽象契约，只定义put、get等操作规范，不提供具体实现；其核心要求是键唯一、通过键快速查值，底层结构由HashMap（哈希表，O(1)）、TreeMap（红黑树，log n）等实现类决定。
Map接口本质是键值映射契约
Java里的Map接口不提供具体实现，只定义“用键找值”的行为规范。它强制实现类必须支持put(K, V)、get(Object)、containsKey(Object)等核心操作，但不关心底层是哈希表、红黑树还是链表。你调用map.get("id")时，实际执行逻辑完全取决于实例化的是HashMap、TreeMap还是LinkedHashMap。
为什么不能用List或数组替代Map
当需要根据唯一标识快速检索数据时，List只能靠遍历——时间复杂度O(n)，而合格的Map实现（如HashMap）平均是O(1)。常见误用场景包括：
- 用
List存用户，每次查ID都写stream().filter(u -> u.getId().equals(id)).findFirst() - 把配置项存在
String[]里，靠下标硬编码对应关系（比如config[0]是数据库URL，config[1]是端口）
这些做法让代码脆弱且难维护，Map或Map才是语义正确、性能合理的选型。
key必须遵守equals/hashCode契约
HashMap和HashSet依赖hashCode()定位桶、equals()确认相等性。如果自定义类作key却没重写这两个方法，会出现：
立即学习“Java免费学习笔记（深入）”；
-
put(new Person("Alice", 25), "engineer")后，get(new Person("Alice", 25))返回null - 同一个对象多次
put，却在Map里存了多份
解决方法只有两个：用不可变类（如String、Integer）作key；或者自己写的key类必须正确重写hashCode()和equals()。别试图绕过这点——所有基于哈希的Map实现都会栽在这里。
不同实现类的关键差异直接影响选型
选错实现类会导致性能骤降或功能缺失：
-
HashMap：无序、允许null键/值，最快，但多线程不安全 -
TreeMap：按键自然排序或按Comparator排序，log(n)查找，适合范围查询（如subMap(from, to)） -
LinkedHashMap：保留插入顺序或访问顺序（构造时传true），适合LRU缓存 -
ConcurrentHashMap：分段锁或CAS，高并发场景唯一推荐的线程安全Map
别在日志收集场景用TreeMap，也别在高频并发计数时用Collections.synchronizedMap(new HashMap())——后者锁整个Map，吞吐量远低于ConcurrentHashMap。
