该视频提供的 JVM 优化案例包含代码与参数调整的双重方案，且有官方文档支持。
- 问题诊断：XXX 系统使用 G1 垃圾收集器默认参数时，4G 堆内存下 2M Region 导致 1M 多对象被判定为大对象，直接进入老年代 Humongous Region，引发 Mixed GC 频繁（几分钟一次）、老年代内存上涨及 Full GC 触发服务卡顿；同时 Mixed GC 的 STW 停顿导致上游接口 200ms 超时。
- 优化方案：代码层面缩减对象大小，去掉无用大属性；将 G1 HeapRegionSize 调整至 4M，让 1M 多对象在年轻代回收；将 MaxGCPauseMillis 从 200ms 调整为 100ms。
- 优化效果：Mixed GC 降至 20-40 分钟一次，Full GC 消失；上游接口 200ms 超时情况大幅减少。
该案例覆盖底层原理与工程实践，可直接用于 Java 面试应答。
仅用 LIMIT 语句处理 1 亿行数据深分页会因回表操作导致性能急剧下降。
问题本质：传统 LIMIT Offset 写法会让 MySQL 扫描大量数据并执行回表操作，产生大量随机磁盘 I/O，导致查询耗时从毫秒级飙升至秒级甚至十几秒。
核心解法：视频提出三种主流优化方案，包括索引覆盖、子查询延迟关联和标签记录法 / 游标查询，其中子查询延迟关联是面试推荐方案，能将回表次数从 100 万次降至 20 次。
追问应对：针对必须支持跳页和分库分表的场景，视频给出了引入 Elasticsearch 或 Redis 缓存的解决方案。
视频围绕 MySQL 深分页问题展开，提供了从原理分析到具体优化方案的完整思路。
仅回答 RocketMQ 的 Broker 配置无法覆盖消息丢失问题的全链路环节。
生产者端：需采用同步发送 + 指数退避重试，关键业务可结合事务消息绑定本地事务，异步发送需通过 SendCallback 处理失败。
Broker 端：同步刷盘与同步复制是基础配置，但需配合 Dledger 模式实现多副本强一致性，同时合理设置消息存储时间。
消费者端：必须使用手动 ACK 机制，业务处理成功后再提交 Offset，同时通过数据库唯一键或 Redis 原子操作实现幂等性。
全链路监控：通过 Trace ID 追踪消息流转，T+1 对账系统比对业务数据与 MQ 记录，发现不一致时触发补偿。
视频最终强调消息可靠性需覆盖生产、存储、消费全流程，并提供了对应场景题的整理资料。
仅用 Redis 分布式锁和数据库唯一索引的幂等性方案，在高并发场景下仍可能因竞态条件导致重复扣款。
问题场景：某转账系统因用户网络抖动触发前端重试，两个请求同时到达不同服务器，均通过 Redis 锁检查并完成扣款，导致用户被扣两次款。
核心陷阱："检查锁 - 加锁" 非原子操作，存在微小窗口期，高并发下两个请求可同时通过检查并执行扣款。
解决方案：需从三层设计保障幂等性，包括通过时间轴日志定位并发竞态、压测模拟重复请求并发场景、使用 Redis 原子命令（如 SET NX EX）和数据库唯一索引兜底。
该问题实际考察开发者对原子性边界的理解，而非简单的锁使用能力。
盲目调整 Feign 重试与熔断配置会引发数据不一致、级联超时等更严重的问题。
问题场景：用户下单需通过 API 网关调用订单、库存、支付三个独立服务，网关配置 Feign 重试 + Resilience4j 熔断后，出现库存重复扣减、支付服务被熔断的问题。
错误解法：调大 Feign 重试次数、降低熔断失败率阈值，会导致非幂等接口重复调用引发数据不一致，重试队列积压占用网关资源，过低的熔断阈值误熔断正常服务。
四层解决方案：业务设计层需保证接口幂等性，非幂等接口采用一次调用 + 异步补偿；重试与熔断策略需区分接口类型和服务重要性精准配置；流量控制与隔离需通过限流、线程池隔离、重试队列隔离避免级联雪崩；监控与兜底需通过全链路监控和降级策略保障系统稳定。