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。
立即学习“Java免费学习笔记（深入）”；
例如：
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 的迭代器是弱一致性的，这才是真正适合并发读写的选项。
