hashmap 初始化应指定大于等于预估数据量的最小2的幂次容量（如1000条用1024），避免频繁resize；put/get依赖键的hashcode和equals正确重写；get返回null需用containskey区分key不存在与value为null；并发场景必须用concurrenthashmap等线程安全实现。
HashMap 初始化时要不要指定初始容量
不指定初始容量，HashMap 默认用 16，但扩容代价高——每次触发 resize() 都要重新哈希全部元素。如果预估数据量在 1000 条左右，直接初始化为 new HashMap(1024) 更稳。注意不是 1000，而是取大于等于该值的最小 2 的幂次，否则构造函数内部会自动向上对齐，白写。
常见错误：写成 new HashMap(1000)，实际容量变成 1024，没问题；但若写成 new HashMap(1001)，也会被拉到 2048，徒增内存开销。
put() 和 get() 背后真正依赖的是哪两个方法
put() 和 get() 的行为完全取决于键对象是否正确定义了 hashCode() 和 equals()。只要这两个方法没重写，哪怕逻辑上“应该相等”的两个对象，也会被当成不同键存两次，或查不到。
典型场景：用自定义类作 key 时忘记重写：
class User {
String name;
int age;
// 忘记重写 hashCode 和 equals → 后果：put 两次相同内容，size 变 2；get 时返回 null
}
必须同时满足：
-
hashCode()相同的对象，equals()必须返回true -
equals()返回true的对象，hashCode()必须相同
为什么有时 get() 返回 null，却不确定是 key 不存在还是 value 存的就是 null
HashMap 允许 value 为 null，所以 map.get(key) == null 无法区分“没这个 key”和“有这个 key 但值是 null”。这时候得用 containsKey() 额外判断。
更高效的做法（尤其在高频读场景）是避免 value 为 null，改用 Optional<v></v> 包装值，或约定用特殊哨兵对象（如 NULL_VALUE 常量）代替裸 null。
容易踩的坑：
- 在业务逻辑里直接用
if (map.get(k) != null)判定 key 是否存在 - 把
computeIfAbsent()和get()混用，误以为后者能反映计算是否发生
并发环境下直接用 HashMap 会出什么问题
多线程同时 put() 可能触发扩容时的链表循环，导致 get() 死循环卡住 CPU；或者数据丢失（一个线程的 put 被另一个覆盖）。这不是概率低的问题，是必现的竞态条件。
替代方案按场景选：
- 读多写少 → 用
Collections.synchronizedMap(new HashMap())，但整表锁粒度大 - 写也频繁 → 改用
ConcurrentHashMap，它分段锁 + CAS，get()无锁，put()冲突率低 - 需要强一致性或事务语义 → 别硬扛，上外部缓存（如 Redis）或数据库
别试图自己加 synchronized 包一层 HashMap，size()、isEmpty() 等方法仍可能返回过期结果，且容易漏锁迭代操作。
