面试官要的是能串联CPU缓存、JVM对象头、线程调度与业务瓶颈，并用真实场景解释并发问题本质及技术选型逻辑的工程思维。
面试官想听的不是“synchronized能加锁”这种表面答案，而是你能不能把CPU缓存、JVM对象头、线程调度、业务瓶颈这几层串起来，再落到一个真实场景里讲清楚。关键不在背原理，而在用原理解释问题、指导选型、复盘结果。
从硬件到JVM，说清“为什么会有并发问题”
高并发问题不是凭空出现的，它根植于底层执行环境：
- CPU多核缓存不一致 → 导致可见性问题：volatile写会触发MESI协议中的缓存行失效，读操作强制从主存加载；
- JVM线程私有栈 + 共享堆 → 局部变量天然线程安全，但对象字段可能被多线程同时修改；
- 对象头Mark Word里存锁状态 → 偏向锁靠CAS记录线程ID，轻量级锁靠自旋抢锁，重量级锁才真正挂起线程；
- 线程切换开销（Context Switch）在QPS破万时会显著吃掉CPU资源，所以不能无限制new Thread，必须用线程池控流。
用项目场景带出技术选型逻辑，而不是罗列组件
别只说“我用了Redis+MQ”，要讲清楚每个决策背后的并发矛盾：
- 秒杀库存扣减：先用Redis原子命令decr预减，避免数据库行锁争抢；失败则快速返回，不进事务；
- 下单链路异步化：订单创建成功后，只发MQ消息，后续发券、更新推荐、写日志全部解耦；接口RT从800ms压到120ms；
- 查询聚合优化：商品详情页不做实时JOIN，而是把SKU信息、营销标签、库存状态冗余到一张宽表，查一次搞定；
- 线程池定制：支付回调处理用FixedThreadPool配合理解超时，而报表导出用CachedThreadPool防突发大文件堆积。
直面踩坑点，体现真实落地能力
面试官最看重你是否真在线上扛过流量，所以主动提1–2个典型翻车点，并说明怎么定位和修复：
立即学习“Java免费学习笔记（深入）”；
- “上线后发现ConcurrentHashMap put性能陡降” → 用jstack发现大量线程卡在transfer扩容阶段 → 查出key分布不均导致单个桶链表过长 → 改用更均匀的hash算法或预估初始容量；
- “分布式锁续期失败导致超卖” → Redis锁过期时间设为30s，但业务逻辑偶发卡顿超40s → 改用Redisson的看门狗机制自动续期；
- “FullGC频繁拖慢响应” → jstat确认老年代增长快 → 发现日志框架中误用String.format拼接大JSON → 改为StringBuilder或延迟格式化。
结尾收在“权衡”上，展现架构思维
高并发没有银弹。比如用最终一致性换性能，用本地缓存换延迟，用限流熔断换可用性——每次取舍都要说清代价。你不是在堆技术，是在做工程判断。
