题目重点：针对 Oracle VO 题目明确的多线程、大数据量 HashMap 追问，区分线程安全、扩容、碰撞及期望复杂度。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 讨论 get/put/remove 的普通 key→value 映射；不假设 TTL、事务或特定语言实现。
- 复杂度分开谈均匀哈希的期望值、极端碰撞最坏值和扩容瞬时成本；大数据量不等于碰撞必然恶化。
解题路线
- 先问并发语义：是否要求单次操作线性化、复合 read-modify-write 原子化、迭代时快照还是弱一致。普通 HashMap 未加同步时读写可能竞态，不能只把引用放进线程安全容器就保证多步事务。
- 一种基线是单锁保护所有操作，正确但高争用；若吞吐不够再考虑分段锁、每桶锁或成熟并发 map，扩容时需安全迁移并发布新表。
- 在负载因子受控且哈希分布良好时，get/put 期望 O(1)；扩容 O(N) 但按倍增摊还 O(1) 插入，极端碰撞取决于桶结构可到 O(N) 或更低。
- 大 N 还带来内存占用、缓存 miss、GC 和 rehash 峰值；用 p95/p99 延迟、碰撞分布及 resize 频次实测，再决定分片或外存索引。
手动走一遍
两线程同时读 counter=4 并各写 5，普通 get 再 put 会丢一次更新，即使两步分别使用并发 map 仍可能发生。应使用原子 compute/compare-and-set 或在同一锁内完成复合更新。若从 100 万键变成 1,000 万键而负载因子保持相近，查找期望仍是常数量级，但内存和实际延迟可能显著增加。
规模与取舍
均匀哈希与负载因子受控时，单次查找/插入期望 O(1)，空间 O(N)；扩容 O(N) 单次、倍增策略下插入摊还 O(1)。恶意碰撞的最坏界依具体实现，不能一概称 O(log N)。
易错点与追问
容易失分的边界
- 仅因数据量大就说所有 get/put 自动变 O(log N)。
- 把单次操作线程安全当作多步业务操作原子。
- 讲锁分段却不讨论跨桶扩容和迭代语义。
- 只谈渐近复杂度，不测内存局部性和 resize 停顿。
继续深挖
- 若 key 可由不可信用户控制，如何抵御碰撞攻击？
- 并发 resize 期间读线程如何找到旧/新表中的键？
- 什么时候数据库或分布式 KV 比进程内 map 更合适？
