Java高频面试考点场景题

聊聊spring事务的传播机制视频讲解了 Spring 事务传播机制的核心内容及四种关键传播行为。定义核心Spring 事务传播机制指当加 Transactional 注解的方法 a 调用同加该注解的方法 b 时定义 b 方法的事务行为共有七种核心需掌握四种。required 行为这是默认传播行为若当前存在事务则加入若没有则新建事务。requires new 行为不管当前是否有事务都会新建事务同时挂起之前的旧事务。support 行为当前有事务则使用没有则不开启事务。nested 行为当前有事务则嵌套没有则新建基于事务 savepoint 机制实现内层事务可独立提交或回滚但最终受外层事务控制。掌握这些传播机制可帮助管理事务边界避免数据一致性问题。Java对象都在堆上吗Java 对象并非全部分配在堆内存中。逃逸分析定义JVM 通过该技术判断对象是否逃出当前方法以厨师切土豆为喻对象作为返回值或赋值给全局变量则为逃逸仅在方法内使用则未逃逸。栈上分配逻辑若对象未逃逸JVM 会将其分配在栈上方法结束栈弹出后对象直接销毁无需垃圾回收器处理。标签替换操作JVM 将未逃逸对象拆分为基本数据类型直接存入栈的局部变量表省去对象外壳。同步消除操作未逃逸对象仅当前线程可访问JVM 会移除其上的锁提升运行速度。视频结尾提出思考题实际开发中是否该为避免对象逃逸刻意修改代码结构。MySQL里有2,000万数据只能塞进Redis 20万怎么保证真正的热点数据视频讲解了 MySQL 存 2000 万数据、Redis 仅能存 20 万时精准保障热点数据的整套治理体系。预热初始数据系统上线 Redis 为空时依据经验和历史数据做预热如秒杀场景塞商品 ID、推荐场景塞热门类目、首页场景塞核心模块目的是避免系统崩溃。动态探测热点借助热点探测框架如京东 hotkey毫秒级识别访问量暴涨的 Key将其推送到所有服务节点的本地内存实现热点的提前识别。淘汰过气数据使用 Redis 自带的 LRU最近最少使用、LFU最不经常使用淘汰机制自动移除访问频率低的 Key为新热点腾出空间。下沉急热数据针对 QPS 极高的急热 Key将其从 Redis 下沉到 JVM 本地缓存消除网络请求延迟降低 Redis 压力。保障节点一致通过分布式统一推送如 hotkey 的 worker 分布式计算将识别出的热 Key 同步推送至所有服务节点确保多节点缓存一致性。这套体系可从 2000 万数据中精准保住 20 万热点数据。双十一凌晨你的积分中心抖动3秒面试官通过双十一积分中心抖动的场景考察 4 年后端开发者的 Feign 调用故障处理能力。场景故障还原去年双十一依赖的积分中心响应从 20ms 增至 3 秒该开发者设置的 2 秒超时触发全请求超时重试机制疯狂触发导致 CPU 飙至 120%、线程池被打满K8s 直接击溃服务积分中心恢复后服务仍反复重启。核心问题点破该场景的核心是 “重试风暴” 陷阱多数开发者对 “超时 重试” 的理解仅停留在设值层面。三层应对能力需具备现场快照与根因定位、事前防御、代码层防御性设计三层能力。具体防御策略核心写接口禁止自动重试读接口仅重试 1 次并配合指数退避配置熔断器下游连续失败超阈值则打开采用线程池隔离不同依赖用独立 Feign 客户端和线程池非核心依赖设短超时直接返回降级结果不重试。这道题的考察重点是开发者对微服务链路脆弱性的认知程度。面试官最爱挖的MySQL“幻读”大坑。MySQL 通过两种机制应对幻读但特殊操作顺序下仍会出现幻读。快照读防幻读普通 select 查询为快照读MySQL 采用多版本并发控制MVCC生成数据快照查询仅读取快照内容不受外界新增数据影响避免幻读。当前读防幻读带 for update 的查询、update、delete 为当前读MySQL 采用间隙锁锁住符合条件的数据及间隙阻止其他事务插入数据避免幻读。混读致幻读场景事务 A 先以快照读查询无编号 5 的数据事务 B 插入编号 5 的数据并提交事务 A 执行 update当前读修改该数据将其事务 ID 改为自身事务 A 再快照读时能看到该数据触发幻读。带你降维打击MVCC底层逻辑小哲讲解数据库 MVCC 的底层实现逻辑及相关面试要点。核心逻辑说明MVCC 即多版本并发控制核心是维持数据多版本实现读写互不阻塞解决传统读写锁并发低效的问题。隐藏字段支撑InnoDB 引擎为每行数据添加事务 ID、回滚指针两个关键隐藏字段事务 ID 记录最后修改数据的事务回滚指针指向数据修改前的版本。版本链生成更新数据时MySQL 将老数据备份到 Undo Log通过回滚指针把新、老数据串成版本链最新数据在链头最老数据在链尾。ReadView 做判断事务发起查询时生成 ReadView系统活跃事务快照数据库依据规则判断数据版本是否可见不可见则顺着回滚指针找前一版本重新判断。隔离级别差异读已提交级别下每次查询重新生成 ReadView可重复读级别下仅事务首次查询生成 ReadView 并复用解决不可重复读问题。消息队列MQ积压了上百万条消息如何快速处理视频围绕 “MQ 百万级消息积压” 的生产事故给出一套高效的应急处理方案核心步骤如下临时 Topic 分流将原消费者改为 “搬运工”把消息转发到新建的临时 Topic建议 50-100 个分区快速释放旧 Topic 的积压。多倍扩容部署几十台临时消费者并行处理临时 Topic 中的消息通过 “空间换时间” 缓解压力。批量消费避免单条插入数据库攒够 100 条或 500 毫秒后批量插入减少数据库连接压力防止 CPU 飙高。防雪崩与顺序保障批量消费时控制节奏避免瞬间压垮下游系统。对需要顺序的消息如订单用订单 ID 的哈希值确保同一 ID 的消息进入同一分区防止乱序。这套方案既能快速 “救火”也能在面试中体现对 MQ 机制如分区、重平衡和高并发场景的深度理解。Spring循环依赖视频详解 Spring 循环依赖的三级缓存机制及底层解决逻辑。循环依赖定义对象 A 包含属性 B对象 B 包含属性 A按常规创建逻辑会陷入无限套娃死循环。核心破局思路Spring 将对象创建拆分为两步先构建空壳对象再填充属性完成初始化通过提前暴露半成品对象打破死局。三级缓存流程一级仓库存放成品对象二级仓库存放半成品空壳三级仓库存放获取对象的工厂凭证创建 A 时先存 A 的工厂凭证A 需 B 则转去创建 BB 存自身凭证后取 A 的凭证获取空壳B 完成初始化进入一级仓库A 再获取 B 完成初始化进入一级仓库。三级缓存必要性若无代理需求二级缓存即可解决循环依赖但 Spring 要求代理对象在生命周期最后生成三级仓库的工厂凭证可在循环依赖时提前生成代理对象满足 B 需获取 A 的代理对象的要求。Spring Boot配置优先级怎么排的视频讲解了 Spring Boot 配置优先级规则及相关注意事项。核心优先级口诀视频给出口诀 “命令行是亲爹JAR 外比 JAR 内强profile 比默认优先”对应具体优先级排序为命令行 JAR 外 profileJAR 外默认 JAR 内 profileJAR 内默认。同类型配置冲突同一参数在 application.yaml 和 application.properties 中重复配置时因 Spring Boot 按加载顺序覆盖properties 后加载会生效。特殊配置优先级Spring Cloud 的 bootstrap.yaml 为祖宗级别由父上下文加载优先级高于 application 系列配置且内容不会被覆盖多用于从配置中心拉取配置。错误后果提示视频指出配置优先级混淆会导致项目配置错误轻则虚惊一场重则引发 P0 事故甚至被辞退。掌握该优先级规则可避免项目配置失误。MySQL可重复读隔离级别可以完全解决幻读吗MySQL 的可重复读隔离级别无法完全解决幻读问题。概念区分先明确快照读与当前读快照读指普通 SELECT 语句基于 MVCC 机制读取事务启动时的数据快照当前读指 SELECT FOR UPDATE、UPDATE、DELETE 等操作读取最新版本数据并加锁。幻读触发场景事务 A 先执行普通 SELECT快照读查询 id2 的记录事务 B 插入 id4 的记录并提交事务 A 再执行 SELECT FOR UPDATE当前读查询 id2 的记录会读到新增的 id4 记录触发幻读。核心原因同一事务内混用快照读与当前读当前读会读取其他事务提交的新数据与快照读结果不一致。解决办法事务启动时将普通 SELECT 替换为 SELECT FOR UPDATE通过加锁锁定数据范围阻止其他事务插入数据。面试遇到该问题需明确可重复读的局限性及对应解决方式。