科大讯飞线下面：HashMap 线程安全与项目细节拷打

《面试题目》

1. 自我介绍。
2. 追求项目细节：项目遇到的难点、实际的数据流设计、系统架构是怎么处理的？
3. 实习经历拷打。
4. HashMap 是线程安全的吗？
5. 如果在一个方法内部 new 一个 HashMap，其他线程调用这个方法，会不会有线程安全问题？
6. 反问环节。

《参考解析》

HashMap 线程不安全的具体表现要能分版本说清。 JDK 1.7 用头插法迁移链表，多线程同时扩容时可能出现环形链表，随后 get 变成死循环把 CPU 打满——这是最著名的事故。JDK 1.8 改成尾插并把链表超长时转红黑树，成环问题基本消失，但并发写入仍会出三类问题：两个线程同时 put 落到同一个桶，后写的覆盖先写的造成数据丢失；同时触发扩容时 size 统计不准（读的是 baseCount 与 CounterCell 的求和，不保证实时一致）；以及 put 过程中 get 可能读到中间态。另外迭代过程中被结构性修改会抛 ConcurrentModificationException，这是 fail-fast 的探测机制而不是线程安全保证。所以结论是：单线程用它没问题，多线程共享要么换 ConcurrentHashMap，要么在外部保证串行访问（如单线程事件循环或加锁）。

「方法内部 new 的 HashMap 有没有线程安全问题」这问的关键不是 HashMap，而是「对象有没有逸出」。 如果这个 map 是方法内的局部变量、只被当前线程的调用栈引用，那么别的线程根本拿不到它的引用（前提是没把它赋给静态字段、没放进共享集合、没作为返回值交出去、没被提交给线程池或异步回调），这种情况下讨论「线程安全」是没有意义的——因为不存在共享可变状态。面试官强调场景，很可能是在提醒你往这个方向想：判断依据是可见性与发布，而不是集合类的名字。反过来，只要对象被发布了（甚至是通过 static 或者传入另一个线程的任务里），哪怕它是局部 new 出来的，也一样会有并发问题；而如果所有访问都发生在同一个线程内（包括后续被别的线程通过安全发布方式拿到，且此后不再被原线程修改），也没有问题。稳妥的答法是先反问/先声明假设：「要看这个 map 有没有被发布到其他线程。如果只在方法内使用、随调用栈结束而回收，就不存在线程安全问题；如果它被返回、被缓存或被交给别的线程，就必须按共享对象处理。」把判断框架说清楚，比抢答「有」或「没有」更容易拿分，也不会像作者那样被一句追问打散节奏。

被追问时怎么稳住：把「结论」换成「条件 + 条件」。 这场面试的失分点不在知识，而在应对方式——面试官强调场景时，作者先动摇再沉默，最后自己也没想清。可行的做法是三步：先确认问题边界（「您说的其他线程调用，是指同一个 map 实例被多个线程访问，还是每个线程各自调这个方法？」），再给出条件化的答案，最后补一句边界（「如果按每个线程各有自己的实例理解，那就没有共享；如果同一个实例被共享，那就是不安全的，要换成 ConcurrentHashMap 或加锁」）。面试官允许你澄清，而且澄清本身就是工程能力的一部分；真正危险的是在没弄清场景前给出绝对结论。

项目细节拷打应该怎么准备。 面试官要的是「真实场景能复现」，所以准备时对每个项目都要能现场画出：整体架构（有哪些服务与中间件）、关键链路的数据流（一个请求从入口到落库经过了哪些处理、字段怎么变化）、数据模型（核心表与索引）、以及至少一个具体难点的定位过程（现象、假设、验证手段、最终原因、修复方式、验证结果）。数字要能张口就来：QPS 量级、数据量、接口耗时 P99、错误率、机器配置。业务侧还要准备「为什么这么设计」「有没有考虑过别的方案」「量再涨十倍哪里先崩」。答不上细节时给出思路并说明当时的真实边界，比含糊其词更容易被接受。

这类线下面与终局判断。 整场只有一道八股、其余全是项目，说明这个团队的评估重心在「你有没有真的做过复杂系统」。反过来说，只在八股上准备而项目讲不清，是最容易被判「简历掺水」的组合。面试结束时对方让回去等通知，通常意味着流程还没走完或需要横向比较，不必据此断定结果；但复盘时要记下两件事：卡住的那一问究竟卡在知识还是卡在应对（这场是后者），以及项目里哪一段自己讲得最虚（那就是下一轮前必须补上的部分）。把这两条落成具体的补课清单，比反复回想「我是不是挂了」有用得多。