Java 大厂一面模拟：从线程池拒绝策略到分布式锁选型的连环压问

开场说明

这是一场模拟 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 还是 setnx？RedLock 真的安全吗？

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 多级缓存，本地用 Caffeine，Redis 做分布式同步，但复杂度高。
面试官： 多级缓存一致性怎么保证？
候选人： 用消息通知或短过期时间，接受短暂不一致，最终靠对账兜底。

压问逻辑： 从单点方案 → 高可用设计 → 一致性权衡，体现候选人对系统稳定性的把控。

面试点评

本场面试主要考察候选人在高并发、分布式场景下的技术深度与工程判断力。重点压问了线程池配置、拒绝策略、分布式锁选型、消息幂等、offset 管理与对账补偿等核心问题。候选人容易卡在以下几个点：

线程池参数调优缺乏量化依据，仅凭经验设定，未结合压测数据。
分布式锁选型过于依赖 Redisson，未深入理解其边界与风险。
幂等设计停留在"加唯一键"层面，未考虑缓存一致性、降级策略与补偿机制。
对账系统实现简单，缺乏断点续传、幂等控制与监控告警。

整体来看，候选人具备一定项目经验，但对底层原理和线上问题缺乏系统思考，需加强故障推演与技术选型论证能力。

技术补丁包

线程池核心参数调优原理：corePoolSize 应对常驻任务，maxPoolSize 应对突发流量，queueCapacity 缓冲任务。设计动机：平衡资源利用与响应速度，避免 OOM 或任务丢失。边界条件：IO 密集型任务可增大 core，CPU 密集型则减小；队列过大易导致延迟。落地建议：结合压测数据设定，监控活跃线程数与队列堆积情况。
线程池拒绝策略选型原理：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 压力。边界条件：短暂不一致不可避免。落地建议：接受最终一致，关键数据走数据库。
消息队列死信队列设计原理：消费失败的消息转入死信队列，后续重试或人工处理。设计动机：避免消息丢失。边界条件：死信队列也可能消费失败。落地建议：设置最大重试次数，最终转人工。
分布式系统最终一致性模式原理：通过消息、对账、补偿等手段，保证系统最终一致。设计动机：避免强一致带来的性能开销。边界条件：补偿机制必须可靠。落地建议：设计幂等接口，记录操作日志，支持反向操作。
面试中技术选型论证方法原理：从业务需求、性能、一致性、可维护性等维度评估方案。设计动机：避免盲目跟风或过度设计。边界条件：需结合团队能力与运维成本。落地建议：写技术方案文档，组织评审，记录决策依据。