Java 大厂一面模拟：从类加载器到热点Key治理的连续压问

开场说明这是一场面向 1-3 年 Java 后端候选人的大厂一面模拟时长约 30 分钟。面试官风格贴近真实大厂节奏先问结论再追源码先看广度再挖边界最后落到线上场景与取舍。候选人需具备扎实的 Java 基础、对主流框架和中间件有实际使用经验并能结合项目回答设计权衡。本文将完整还原面试过程包含 8 个主问题、4 条重点追问链覆盖 JVM、Spring、MySQL、Redis、MQ 五大模块强调“原理 → 边界 → 故障 → 取舍”的递进逻辑。主问题部分1. 你能说说 JVM 类加载机制吗双亲委派模型是做什么的参考回答类加载分为加载、验证、准备、解析、初始化五个阶段。双亲委派模型是指类加载器在收到加载请求时先委托父类加载器尝试加载只有当父类无法完成时才由自己加载。这样可以保证核心类如 java.lang.Object只被 Bootstrap ClassLoader 加载一次避免用户自定义同名类覆盖 JDK 类。追问点如果我要打破双亲委派怎么做Tomcat 是怎么做的2. Spring 中 Bean 的生命周期是怎样的AOP 代理是在哪个阶段创建的参考回答Bean 生命周期包括实例化 → 属性赋值 → 初始化前BeanPostProcessor→ 初始化InitializingBean / PostConstruct→ 初始化后AOP 代理生成→ 使用 → 销毁。AOP 代理通常在初始化后的 BeanPostProcessor 中通过 AbstractAutoProxyCreator 创建基于 JDK 动态代理或 CGLIB。追问点为什么默认情况下同类内部方法调用不走 AOP如何解决3. MySQL 的 InnoDB 是如何实现事务隔离的可重复读下怎么解决幻读参考回答InnoDB 通过 MVCC多版本并发控制和锁机制实现隔离级别。在可重复读RR下通过间隙锁Gap Lock防止其他事务插入新记录从而避免幻读。读操作使用快照读一致性非锁定读写操作加行锁 间隙锁。追问点间隙锁在什么情况下会升级为临键锁会不会导致死锁4. Redis 做缓存时如何避免缓存雪崩你项目里是怎么做的参考回答缓存雪崩是大量 key 同时过期导致请求打到数据库。我们采用三种策略过期时间加随机值如 300s ± 60s多级缓存本地 Caffeine Redis热点 key 永不过期通过后台任务异步刷新追问点如果热点 key 突然失效大量请求并发重建缓存怎么处理5. Kafka 如何保证消息不丢失生产者、Broker、消费者各需要注意什么参考回答生产者设置 acksall启用重试配合 idempotence 防重复Brokermin.insync.replicas ≥ 2避免单副本写入消费者手动提交 offset处理完业务再提交避免自动提交导致丢消息追问点如果消费者处理消息时崩溃offset 已提交但业务未落库怎么办6. 你用过 ThreadLocal 吗它有什么内存泄漏风险怎么规避参考回答ThreadLocal 通过 ThreadLocalMap 存储数据key 是弱引用value 是强引用。如果线程长期存活如线程池value 无法被 GC导致内存泄漏。规避方式使用后调用 remove()或避免在线程池中滥用。追问点为什么 key 设计成弱引用而不是强引用7. 项目中遇到过 OOM 吗怎么排查的参考回答曾遇到一次 Young GC 频繁导致卡顿。通过 jstat 观察 GC 日志发现 Eden 区增长过快再用 jmap 生成堆转储MAT 分析发现是某个缓存未设上限不断累积大对象。最终加上 LRU 淘汰策略和大小限制解决。追问点如果是 Metaspace OOM可能是什么原因怎么调优8. 设计一个高并发抢红包系统你会怎么考虑缓存和一致性参考回答红包总额预加载到 Redis原子扣减DECRBY用户领取记录写入 MySQL通过唯一索引防重异步消息通知账务系统保证最终一致本地缓存用户当日领取次数减少 DB 查询追问点如果 Redis 扣减成功但 DB 写入失败怎么回滚追问部分追问链 1类加载器与热部署面试官你说 Tomcat 打破了双亲委派具体是怎么实现的候选人Tomcat 为每个 WebApp 创建 WebAppClassLoader它优先自己加载 WEB-INF/classes 和 lib 下的类只有找不到时才委托父加载器。这样不同应用可以加载同名不同版本的 jar。面试官那如果两个应用依赖同一个库的不同版本会不会冲突候选人不会因为每个 WebAppClassLoader 独立类加载隔离。但共享库如 JDBC 驱动仍由 CommonClassLoader 加载需谨慎管理。面试官线上曾出现类冲突导致 NoSuchMethodError你怎么定位候选人用 -verbose:class 看加载路径或用 arthas 的 classloader 命令查看类来源确认是否被错误版本覆盖。追问链 2AOP 自调用问题面试官你说同类内部调用不走 AOP为什么候选人因为 Spring AOP 基于代理内部调用 this.method() 直接走目标对象不经过代理。面试官那怎么解决候选人三种方式通过 ApplicationContext 获取代理 Bean 再调用使用 AspectJ 编译期织入LTW重构代码将需要切面的方法抽到新类面试官你们项目选了哪种为什么候选人选了第三种因为 AspectJ 配置复杂且重构后职责更清晰符合 Clean Architecture。追问链 3Redis 热点 Key 重建竞争面试官你说热点 key 失效后并发重建有问题具体怎么解决候选人可以用分布式锁Redisson控制只有一个线程重建其他线程等待或返回旧值。面试官但加锁本身有性能开销有没有无锁方案候选人可以用“缓存空对象”或“永不过期 异步刷新”key 不过期后台定时任务提前刷新前台读始终命中。面试官如果异步刷新失败呢候选人那就降级为同步重建但加本地锁synchronized限制单机并发避免雪崩。追问链 4Kafka 消费幂等与对账面试官你说消费者要手动提交 offset那如何保证业务幂等候选人在业务表中加唯一键如消息 ID 业务类型插入前判断是否已处理。面试官如果消息重复但业务逻辑复杂唯一键不好设计呢候选人可以用 Redis 记录已处理消息 ID设置合理过期时间或引入对账系统定时扫描未确认消息重新处理。面试官对账系统怎么设计候选人每天定时任务拉取 Kafka 消息轨迹和 DB 状态对比差异触发补偿。关键是要有消息唯一 ID 和全链路追踪。面试点评本场面试重点考察候选人对核心机制的理解深度和线上问题应对能力。易卡点 1双亲委派的打破场景不熟悉多数候选人只知 Tomcat不知 Jetty 或 OSGi 也有类似机制。易卡点 2AOP 自调用问题常出现在事务失效场景候选人容易忽略代理本质。易卡点 3缓存重建策略停留在“加锁”层面缺乏无锁或降级方案思考。易卡点 4消息幂等设计过于依赖数据库唯一键未考虑对账补偿等最终一致手段。整体来看候选人需加强“边界条件”和“故障兜底”思维避免只答理想路径。技术补丁包双亲委派模型原理类加载请求优先委托父加载器防止核心类被替换。 设计动机安全性与类唯一性保障。 边界条件自定义类加载器可打破但需谨慎处理类冲突。 落地建议Tomcat 通过 WebAppClassLoader 实现应用隔离共享库由 CommonClassLoader 加载。Spring AOP 代理机制原理基于 JDK 动态代理或 CGLIB 生成代理对象在方法前后插入切面逻辑。 设计动机解耦横切关注点如日志、事务。 边界条件同类内部调用不走代理需通过外部调用或重构解决。 落地建议复杂切面考虑使用 AspectJ简单场景优先代码重构。InnoDB 间隙锁原理在可重复读隔离级别下对索引范围加锁防止幻读。 设计动机保证事务内多次读取结果一致。 边界条件间隙锁可能引发死锁需合理设计索引和事务粒度。 落地建议避免长事务尽量使用覆盖索引减少锁范围。Redis 缓存雪崩防护原理通过随机过期、多级缓存、热点永不过期等手段分散失效风险。 设计动机避免瞬时 DB 压力激增。 边界条件热点 key 重建可能引发并发竞争。 落地建议结合本地缓存 异步刷新 降级策略构建多层防护。Kafka 消息可靠性保障原理生产者 ackall、Broker 多副本、消费者手动提交 offset。 设计动机端到端消息不丢失。 边界条件消费者崩溃可能导致业务未处理但 offset 已提交。 落地建议业务层实现幂等 对账补偿机制。ThreadLocal 内存泄漏原理ThreadLocalMap 的 value 是强引用线程池中长期存活导致无法 GC。 设计动机线程内数据隔离。 边界条件不调用 remove() 极易泄漏。 落地建议始终在 finally 块中调用 remove()避免在线程池中使用。OOM 排查流程原理通过 GC 日志、堆转储、内存分析工具定位泄漏点。 设计动机快速恢复服务并根因分析。 边界条件Metaspace OOM 常因动态生成类过多如 CGLIB、反射。 落地建议开启 -XX:HeapDumpOnOutOfMemoryError配合 MAT 分析支配树。分布式锁选型原理基于 RedisRedisson或 ZooKeeper 实现互斥访问。 设计动机控制共享资源并发访问。 边界条件Redis 锁需处理过期时间、续约、脑裂问题。 落地建议优先使用 Redisson 的看门狗机制自动续约避免业务超时锁失效。消息幂等设计原理通过唯一标识判断消息是否已处理。 设计动机防止重复消费导致数据错误。 边界条件唯一键难设计时需引入外部状态存储。 落地建议结合 Redis 去重 数据库唯一约束 对账补偿三重保障。缓存一致性策略原理Cache-Aside、Read-Through、Write-Through 等模式协调缓存与 DB。 设计动机平衡性能与数据准确性。 边界条件缓存更新失败可能导致脏读。 落地建议写操作先更新 DB 再删缓存配合延迟双删减少不一致窗口。线程池拒绝策略原理当队列满且线程数达上限时触发拒绝策略Abort、CallerRuns 等。 设计动机防止系统过载。 边界条件CallerRuns 可能拖慢主线程需评估业务容忍度。 落地建议关键业务使用有界队列 CallerRuns非关键业务用 Abort 并记录日志。MySQL 死锁检测原理InnoDB 通过 wait-for graph 检测死锁回滚代价最小的事务。 设计动机自动解除循环等待。 边界条件高并发下死锁频繁需优化 SQL 和事务顺序。 落地建议统一访问顺序减少事务粒度开启 innodb_deadlock_detect。G1 GC 调优原理分 region 回收可预测停顿时间。 设计动机替代 CMS适合大堆低延迟场景。 边界条件Mixed GC 阶段可能因 Humongous 对象失败。 落地建议设置 -XX:MaxGCPauseMillis监控 Evacuation Failure。Spring 事务传播行为原理定义事务方法调用其他事务方法时的行为REQUIRED、REQUIRES_NEW 等。 设计动机灵活控制事务边界。 边界条件PROPAGATION_REQUIRES_NEW 会挂起当前事务可能影响性能。 落地建议避免嵌套事务过深优先使用 REQUIRED。布隆过滤器应用原理概率型数据结构判断元素是否可能存在。 设计动机高效过滤不存在 key防止缓存穿透。 边界条件存在误判率不能删除元素。 落地建议用于读多写少场景配合 Redis 缓存使用。本地缓存选型原理Caffeine 基于 W-TinyLFU 算法实现高性能缓存。 设计动机减少远程调用提升响应速度。 边界条件集群环境下需解决缓存一致性问题。 落地建议用于读多写少、容忍短暂不一致的数据如配置、用户基础信息。分布式事务最终一致性原理通过消息队列 本地事务表 对账实现最终一致。 设计动机避免强一致带来的性能损耗。 边界条件对账延迟可能导致短暂不一致。 落地建议关键业务如支付采用 TCC一般业务用消息 对账。慢 SQL 优化路径原理通过 explain 分析执行计划优化索引和查询结构。 设计动机降低数据库负载提升响应速度。 边界条件索引过多影响写入性能。 落地建议定期 review 慢查询日志避免 select *使用覆盖索引。Redisson 分布式锁实现原理基于 Lua 脚本保证原子性看门狗线程自动续期。 设计动机简化分布式锁使用复杂度。 边界条件Redis 主从切换可能导致锁失效RedLock 可缓解。 落地建议业务超时时间应大于锁租期避免并发执行。全链路追踪集成原理通过 traceId 串联服务调用链定位性能瓶颈。 设计动机提升可观测性快速定位问题。 边界条件采样率设置影响性能与数据完整性。 落地建议集成 SkyWalking 或 Arthas关键路径全采样。