源码重点：state 状态，FIFO 队列人性化管理阻塞/唤醒，CAS 保证并发安全。业务建议：可自定义同步器，避免过度锁竞争，提升可扩展性。风险提示：错误使用可能导致死锁，关注线程阻塞粒度。

如果让你设计一个支持千万级并发的清算系统，你会怎么分层？

凌晨 2:17，订单履约系统的告警突然炸响。监控大屏上，MySQL 的 QPS 从平时的 800 飙升至 12000，CPU 使用率突破 95%，大量订单状态更新请求超时。与此同时，Redis 集群的某个分片内存使用率在 30 秒内从 45% 暴涨到 98%，紧接着触发了 OOM 强制淘汰策略，缓存命中率从 99.6% 骤降至 18%。我们以为是缓存击穿，结果排查后发现，这是一场典型的“热点 Ke

在团队最近的一次技术评审会上，关于是否应该在配置类中滥用@Component注解引发了激烈争论。一方认为“只要加了@Component，Spring 就能自动管理，省事又高效”；另一方则坚持“配置类就该用，否则可能引发 Bean 创建顺序错乱”。这场争论最终促使我们深入 Spring Boot 的自动装配源码，重新审视注解背后的设计逻辑与实际影响。本文将通过一次真实的配置误用案例，逐步拆解 Spr

在团队最近一次架构评审会上，关于 Spring 循环依赖的处理方式爆发了一场激烈争论。“直接用 @Lazy 不就行了？” 小李拍着桌子说，“我上个月在订单服务里就这么干的，上线一点问题没有。“@Lazy 只是绕开问题，不是解决问题。” 架构师老张摇头，“如果两个核心 Bean 互相依赖，延迟加载会导致首次请求超时，用户体验直接崩掉。“那用 setter 注入？” 小王插话，“我看官方文档说构造器注

上周团队在优化一个高并发配置中心时，针对缓存选型爆发了一场激烈争论。一方主张：“直接用 ConcurrentHashMap，线程安全，性能好，JDK 自带，不用白不用。另一方反驳：“你们真的了解它的扩容机制吗？在高并发写入场景下，多个线程同时触发扩容，会不会导致 CPU 飙升甚至死循环？起初大家都认为这是“标准写法”，直到压测时发现：在 32 核机器上，随着线程数增加到 64，CPU 使用率从 3

订单明明已经支付成功了，为什么用户端还是显示待付款？2026年3月底，我们电商平台的客服系统突然涌入大量投诉，集中在“支付成功但订单状态未更新”。起初我们以为是前端缓存问题，但排查后发现：支付回调已正常写入数据库，订单状态字段也确实被更新为“已支付”，可用户在APP刷新后仍看到旧状态。更诡异的是，这种现象只出现在部分用户身上，且集中在高峰时段。我们立刻拉起了紧急故障群，开启了线上故障复盘流程。

一级是成品 Bean，二级是早期暴露的 Bean，三级是 ObjectFactory。：看门狗会续期，但如果业务线程阻塞（比如 Full GC），看门狗可能无法续期，锁会过期，其他客户端可能获取到锁。：Spring 在依赖注入时，会从三级缓存中获取早期暴露的对象，如果该对象需要代理，会提前创建代理并放入缓存。：我们也有数据库兜底，比如订单状态变更表有唯一键，重复消费会抛异常，我们捕获后直接返回成功

追问风格贴近真实大厂节奏：先问用法，再挖原理，接着压边界场景，最后落到项目取舍。如果先写 MySQL 成功，再写 Redis 失败，就会不一致。我们通常先写 MySQL，再写 Redis，并配合重试或补偿机制。自动修复应基于“最终一致性”原则，采用“增量修复 + 版本号控制”，修复期间新行为仍正常处理，修复完成后再次校验。用户完成下单或签到等行为后，后端接收事件，先查用户当前积分，然后加锁更新积分

遇到过一致性问题：某次 DB 更新后，Redis 删除成功，但本地缓存因消息丢失未清理，导致读到旧数据。之前 Full GC 频繁，后来发现是缓存对象太多，调整了 Caffeine 的 maximumSize，并加了堆外内存监控。面试时长约 30 分钟，节奏紧凑，问题层层递进，重点考察从“知道”到“会用”再到“能兜底”的完整链路。我们遇到过，后来优化了缓存对象结构，避免大对象。如果只更新 JSON