Map是接口不能直接实例化,必须用HashMap等实现类;自定义key需重写hashCode和equals;合理设置初始容量和负载因子可提升性能;多线程场景应使用ConcurrentHashMap。

Map 接口不是类,不能 new
Java 中 Map 是接口,没有构造方法,直接写 new Map() 会编译报错:「Cannot instantiate the type Map」。必须用它的实现类,最常用的是 HashMap。
常见误写:
Mapmap = new Map<>(); // ❌ 编译失败
正确写法(推荐使用接口类型声明 + 实现类实例化):
Mapmap = new HashMap<>(); // ✅
- 声明用
Map是为了面向接口编程,方便后续替换为LinkedHashMap或ConcurrentHashMap - 构造时用
HashMap表示具体行为:无序、非线程安全、允许 null 键/值 - JDK 7+ 支持菱形运算符
,避免重复写泛型
HashMap 的 key 必须重写 hashCode 和 equals
如果用自定义对象作 HashMap 的 key,但没重写 hashCode() 和 equals(Object),会导致看似相同的对象无法命中已有 entry —— 因为默认继承自 Object,两个不同实例的 hashCode 值不同,equals 返回 false。
立即学习“Java免费学习笔记(深入)”;
例如:
class Person {
String name;
int age;
Person(String name, int age) { this.name = name; this.age = age; }
}
Map map = new HashMap<>();
map.put(new Person("Alice", 30), "Engineer");
System.out.println(map.get(new Person("Alice", 30))); // null ❌
修复方式(IDE 通常可自动生成):
- 确保
hashCode()计算只依赖于参与equals比较的字段 -
equals要满足对称性、传递性、一致性;注意判空和类型检查 - Lombok 用户可加
@EqualsAndHashCode注解(但需确认字段是否真该参与)
HashMap 初始容量和负载因子影响性能
HashMap(int initialCapacity, float loadFactor) 构造函数常被忽略,但对性能有实际影响。默认初始容量是 16,负载因子 0.75,意味着第 13 个元素插入时就会触发扩容(rehash),而扩容涉及重建哈希表、重新计算每个 key 的位置,开销不小。
- 如果已知要存约 1000 个键值对,建议初始化为
new HashMap(1024)(向上取最近 2 的幂) - 负载因子设得太小(如 0.5)会浪费空间;太大(如 0.9)则链表/红黑树冲突概率上升,get 性能下降
- 注意:传入的
initialCapacity会被自动转成「大于等于该值的最小 2 的幂」,比如传 10 → 实际是 16
HashMap 在多线程下直接使用会出问题
HashMap 不是线程安全的。多个线程同时执行 put 可能导致死循环(JDK 7 的头插法扩容 bug)、数据丢失或 get 返回 null。这不是偶发,而是确定性风险。
错误场景示例:
Mapmap = new HashMap<>(); // 多线程共享 // Thread A 和 Thread B 同时调用 map.put(...)
替代方案取决于需求:
- 读多写少 → 用
Collections.synchronizedMap(new HashMap()),但注意迭代仍需手动同步 - 高并发写 → 直接用
ConcurrentHashMap(JDK 8+ 使用 CAS + synchronized 分段锁,性能更好) - 仅限单线程内部临时用 → 不必换,
HashMap本身足够快
别指望加个 synchronized(map) 就能安全遍历——ConcurrentHashMap 的迭代器是弱一致性的,这才是真正适合并发读写的选项。










