Java Map接口与HashMap使用详解

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

Map 接口不是类，不能 new

Java 中 Map 是接口，没有构造方法，直接写 new Map<>() 会编译报错：「Cannot instantiate the type Map」。必须用它的实现类，最常用的是 HashMap。

常见误写：

Map<String, Integer> map = new Map<>(); // ❌ 编译失败

正确写法（推荐使用接口类型声明 + 实现类实例化）：

Map<String, Integer> map = new HashMap<>(); // ✅

• 声明用 Map 是为了面向接口编程，方便后续替换为 LinkedHashMap 或 ConcurrentHashMap
• 构造时用 HashMap 表示具体行为：无序、非线程安全、允许 null 键/值
• JDK 7+ 支持菱形运算符 <>，避免重复写泛型

HashMap 的 key 必须重写 hashCode 和 equals

如果用自定义对象作 HashMap 的 key，但没重写 hashCode() 和 equals(Object)，会导致看似相同的对象无法命中已有 entry —— 因为默认继承自 Object，两个不同实例的 hashCode 值不同，equals 返回 false。

例如：

class Person {
    String name;
    int age;
    Person(String name, int age) { this.name = name; this.age = age; }
}

Map<Person, String> 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。这不是偶发，而是确定性风险。

错误场景示例：

Map<String, Integer> map = new HashMap<>(); // 多线程共享
// Thread A 和 Thread B 同时调用 map.put(...)

替代方案取决于需求：

• 读多写少 → 用 Collections.synchronizedMap(new HashMap<>())，但注意迭代仍需手动同步
• 高并发写 → 直接用 ConcurrentHashMap（JDK 8+ 使用 CAS + synchronized 分段锁，性能更好）
• 仅限单线程内部临时用 → 不必换，HashMap 本身足够快

别指望加个 synchronized(map) 就能安全遍历——ConcurrentHashMap 的迭代器是弱一致性的，这才是真正适合并发读写的选项。