开场说明这是一场模拟 30 分钟 Java 大厂一面的高强度技术拷打目标候选人为 1-3 年经验的 Java 后端工程师或校招高阶候选人。面试官将以“八股结论 → 源码细节 → 边界场景 → 线上故障 → 技术取舍”为主线连续压问核心知识点覆盖 Java 并发、JVM、Spring、MySQL、Redis 与分布式系统设计。整场面试强调“连续追问感”和“拷打强度”避免泛泛而谈直击候选人知识盲区与落地能力。候选人画像熟悉 Spring Boot 开发有简单分布式项目经验但对底层原理、异常边界和线上问题缺乏系统认知。面试将从线程池配置切入逐步深入到分布式锁选型、缓存一致性、消息可靠性等真实业务场景考察其技术深度与工程判断力。主问题部分1. 你在项目里是怎么配置线程池的核心参数怎么定的参考回答我通常使用ThreadPoolTaskExecutor配置线程池核心参数包括 corePoolSize、maxPoolSize、queueCapacity、rejectionPolicy 和 threadNamePrefix。corePoolSize 我一般设为 CPU 核数的 1~2 倍maxPoolSize 设为 core 的 2~3 倍queueCapacity 根据任务类型调整——IO 密集型任务队列可以大一点CPU 密集型则小一点。拒绝策略默认用 CallerRunsPolicy避免任务丢失。追问点为什么不用 FixedThreadPool 或 CachedThreadPool你遇到过线程池满导致的问题吗2. 你说用 CallerRunsPolicy那如果主线程被阻塞了怎么办有没有更优的拒绝策略参考回答CallerRunsPolicy 确实可能阻塞调用线程尤其在 Web 请求中会导致接口超时。我后来在一些高并发场景改用 AbortPolicy 配合监控告警或者自定义拒绝策略将任务写入本地日志或消息队列异步重试。还有一种做法是结合 Hystrix 或 Resilience4j 做熔断降级。追问点自定义拒绝策略怎么写如何保证重试不丢任务3. 你提到消息队列重试那 Kafka 消费怎么保证幂等参考回答我一般通过业务唯一键 数据库唯一索引来实现幂等。比如订单支付消息用 orderId payType 做联合唯一键。另外也会在消费前查 Redis 缓存如果已处理过就跳过。对于金融类场景还会加对账补偿机制。追问点如果唯一键被绕过怎么办Redis 缓存和数据库不一致怎么处理4. 你说用 Redis 做幂等缓存那缓存过期时间设多久会不会有脏读参考回答我一般设 24~72 小时根据业务容忍度调整。比如支付消息设 24 小时活动发奖设 72 小时。脏读问题确实存在所以我会在写入数据库后再更新 Redis并且加分布式锁防止并发写。另外也会定期扫描数据库补全缓存。追问点分布式锁用 Redisson 还是 setnxRedLock 真的安全吗5. Redisson 的看门狗机制是怎么实现的如果主从切换会丢锁吗参考回答看门狗是通过后台线程定期续期锁的 TTL默认每 10 秒续一次续到 30 秒。但如果发生主从切换从节点没有锁信息确实可能丢锁。所以 RedLock 理论上更安全但性能差而且官方已不推荐。我现在更倾向于用 ZooKeeper 或 etcd 实现强一致锁或者接受最终一致性通过业务补偿兜底。追问点你说接受最终一致性那具体怎么设计补偿机制6. 你们项目里有对账系统吗怎么做的参考回答我们有定时对账任务每天凌晨跑对比消息队列的消费记录和数据库状态。比如支付消息会查 Kafka 的 offset 和订单表的支付状态。不一致的话会发告警人工介入或自动重试。关键是对账要支持幂等和断点续传。追问点对账任务怎么避免重复处理offset 怎么管理7. 你说 offset 管理那 Kafka 消费者组 rebalance 时 offset 会丢吗参考回答不会丢但可能重复消费。Kafka 的 offset 是提交到 __consumer_offsets 主题的rebalance 时会从最后提交的 offset 开始消费。所以必须保证消费逻辑幂等。我一般手动提交 offset配合业务处理成功后再 commit。追问点手动提交 offset 的时机怎么选异步提交有什么风险8. 你提到异步提交 offset那如果消费成功但 offset 没提交重启后会重复消费怎么解决参考回答这就是为什么我强调业务幂等。另外也可以把 offset 和业务状态一起存数据库用事务保证一致性。比如处理完消息后把 offset 和业务结果一起 update这样重启时可以从数据库读最新 offset。追问点这种方案性能怎么样有没有更好的 offset 管理方式追问部分重点压问链压问链一线程池拒绝策略 → 线上故障 → 技术取舍面试官你之前说用 CallerRunsPolicy但实际线上遇到过主线程阻塞导致接口超时吗候选人遇到过有一次大促期间线程池满了CallerRunsPolicy 让 Tomcat 工作线程执行任务导致请求堆积最终 502。面试官那你们怎么解决的候选人我们紧急切成了 AbortPolicy配合告警同时扩容线程池和机器。面试官扩容是临时方案长期怎么优化候选人我们后来做了任务分级核心任务走独立线程池非核心任务走公共池并且加了流量控制和降级策略。面试官任务分级怎么实现有没有考虑过协程或虚拟线程候选人我们用 Spring 的 Async 配合不同 Executor虚拟线程还在调研Java 21 的虚拟线程确实能提升 IO 密集型任务吞吐量但生态还不成熟。压问逻辑从策略选择 → 线上故障 → 架构优化 → 新技术评估体现候选人对技术选型的全局思考。压问链二分布式锁选型 → 一致性边界 → 业务兜底面试官你说 Redisson 可能丢锁那你们支付系统用 Redisson 做分布式锁安全吗候选人支付系统我们没用 Redisson用了数据库唯一索引 状态机锁只是辅助。面试官那如果并发扣款数据库唯一索引能防住吗候选人能我们用 orderId version 做乐观锁更新时带 version 条件失败就重试。面试官重试次数设多少无限重试会雪崩吗候选人最多重试 3 次每次加随机退避还加了熔断器失败率超阈值就降级。面试官降级后怎么保证最终一致候选人走对账系统每天跑不一致就人工干预或自动补偿。压问逻辑从锁选型 → 一致性保障 → 异常处理 → 兜底机制考察候选人对分布式事务的完整理解。压问链三Kafka 消费幂等 → offset 管理 → 对账补偿面试官你说用 Redis 做幂等缓存那 Redis 宕机了怎么办候选人我们会降级到数据库唯一索引虽然性能差一点但能保一致。面试官降级期间性能下降用户体验受影响有没有更好的方案候选人可以考虑本地缓存 Redis 多级缓存本地用 CaffeineRedis 做分布式同步但复杂度高。面试官多级缓存一致性怎么保证候选人用消息通知或短过期时间接受短暂不一致最终靠对账兜底。压问逻辑从单点方案 → 高可用设计 → 一致性权衡体现候选人对系统稳定性的把控。面试点评本场面试主要考察候选人在高并发、分布式场景下的技术深度与工程判断力。重点压问了线程池配置、拒绝策略、分布式锁选型、消息幂等、offset 管理与对账补偿等核心问题。候选人容易卡在以下几个点线程池参数调优缺乏量化依据仅凭经验设定未结合压测数据。分布式锁选型过于依赖 Redisson未深入理解其边界与风险。幂等设计停留在“加唯一键”层面未考虑缓存一致性、降级策略与补偿机制。对账系统实现简单缺乏断点续传、幂等控制与监控告警。整体来看候选人具备一定项目经验但对底层原理和线上问题缺乏系统思考需加强故障推演与技术选型论证能力。技术补丁包线程池核心参数调优 原理corePoolSize 应对常驻任务maxPoolSize 应对突发流量queueCapacity 缓冲任务。 设计动机平衡资源利用与响应速度避免 OOM 或任务丢失。 边界条件IO 密集型任务可增大 coreCPU 密集型则减小队列过大易导致延迟。 落地建议结合压测数据设定监控活跃线程数与队列堆积情况。线程池拒绝策略选型 原理AbortPolicy 抛异常CallerRunsPolicy 由调用线程执行DiscardPolicy 静默丢弃。 设计动机根据业务容忍度选择核心服务避免阻塞非核心可降级。 边界条件CallerRunsPolicy 可能阻塞 Tomcat 线程导致雪崩。 落地建议高并发场景用 AbortPolicy 告警或自定义策略写入死信队列。自定义拒绝策略实现 原理实现 RejectedExecutionHandler 接口在 rejectedExecution 方法中处理任务。 设计动机将拒绝的任务持久化后续重试或人工处理。 边界条件写入本地文件可能丢数据需配合消息队列。 落地建议结合 Kafka 或 RocketMQ 做异步重试保证最终处理。Kafka 消费幂等设计 原理通过业务唯一键 数据库唯一索引或 Redis 缓存去重。 设计动机避免重复消费导致数据错误如重复扣款、重复发奖。 边界条件唯一键可能被绕过缓存与数据库不一致。 落地建议关键业务用数据库唯一索引非关键用 Redis 短过期时间。Redis 幂等缓存一致性 原理先写数据库再更新 Redis或双写加锁。 设计动机保证缓存与数据库一致避免脏读。 边界条件网络分区或 Redis 宕机导致不一致。 落地建议接受短暂不一致最终靠对账补偿或使用 Canal 监听 binlog 同步。Redisson 分布式锁原理 原理基于 Redis setnx Lua 脚本实现看门狗线程自动续期。 设计动机提供可重入、自动续期、阻塞获取等高级特性。 边界条件主从切换可能丢锁RedLock 性能差且官方不推荐。 落地建议非强一致场景可用强一致场景用 ZooKeeper 或数据库乐观锁。RedLock 安全性争议 原理向多个独立 Redis 实例加锁多数成功才算成功。 设计动机避免单点故障提升锁的可靠性。 边界条件时钟漂移、网络分区仍可能导致锁失效。 落地建议谨慎使用优先考虑业务补偿而非强锁。分布式锁选型对比 原理Redis 性能好但弱一致ZooKeeper 强一致但性能差数据库锁简单但吞吐低。 设计动机根据业务一致性要求选择合适方案。 边界条件支付、金融类需强一致活动发奖可接受最终一致。 落地建议非核心用 Redis核心用数据库或 ZK配合补偿机制。对账系统设计要点 原理定时对比源系统与目标系统数据发现不一致并修复。 设计动机保障最终一致性弥补消息丢失或处理失败。 边界条件对账任务可能重复执行需支持幂等。 落地建议记录处理进度支持断点续传不一致时发告警人工或自动修复。Kafka offset 手动提交时机 原理在业务处理成功后调用 commitSync 或 commitAsync。 设计动机避免消息丢失或重复消费。 边界条件异步提交可能丢 offset同步提交影响性能。 落地建议关键业务用同步提交非关键用异步 幂等。Kafka rebalance 与 offset 管理 原理rebalance 时从最后提交的 offset 开始消费。 设计动机保证消费进度不丢失。 边界条件重复消费不可避免必须幂等。 落地建议结合业务状态管理 offset如存入数据库。数据库 offset 管理方案 原理将 Kafka offset 与业务处理结果一起存入数据库用事务保证一致性。 设计动机避免 offset 与业务状态不一致。 边界条件数据库成为性能瓶颈。 落地建议分库分表定期清理旧 offset。任务分级与独立线程池 原理按业务重要性划分线程池核心任务独立资源。 设计动机避免非核心任务影响核心链路。 边界条件配置复杂需动态调整。 落地建议结合 Spring Async 与自定义 Executor监控各池状态。虚拟线程Virtual Thread适用场景 原理Java 21 引入的轻量级线程由 JVM 调度适合 IO 密集型任务。 设计动机提升并发能力降低线程开销。 边界条件生态不成熟调试困难。 落地建议非核心服务可试点核心服务暂缓。乐观锁与版本号控制 原理更新时带 version 条件version 不匹配则失败。 设计动机避免并发更新导致数据覆盖。 边界条件重试次数需控制避免雪崩。 落地建议结合随机退避与熔断器失败走补偿。熔断器与降级策略 原理当失败率超阈值熔断器打开直接拒绝请求。 设计动机保护系统不被拖垮。 边界条件降级后需有兜底方案。 落地建议结合 Hystrix 或 Resilience4j监控熔断状态。多级缓存一致性保障 原理本地缓存 分布式缓存通过消息或短过期时间同步。 设计动机提升性能降低 Redis 压力。 边界条件短暂不一致不可避免。 落地建议接受最终一致关键数据走数据库。消息队列死信队列设计 原理消费失败的消息转入死信队列后续重试或人工处理。 设计动机避免消息丢失。 边界条件死信队列也可能消费失败。 落地建议设置最大重试次数最终转人工。分布式系统最终一致性模式 原理通过消息、对账、补偿等手段保证系统最终一致。 设计动机避免强一致带来的性能开销。 边界条件补偿机制必须可靠。 落地建议设计幂等接口记录操作日志支持反向操作。面试中技术选型论证方法 原理从业务需求、性能、一致性、可维护性等维度评估方案。 设计动机避免盲目跟风或过度设计。 边界条件需结合团队能力与运维成本。 落地建议写技术方案文档组织评审记录决策依据。