Java高频面试考点场景题16

Thread.sleep 导致线上系统崩溃的核心原因并非简单的线程阻塞，而是对线程资源的错误占用。

问题定位：视频通过真实面试场景展开，描述线上系统因 Thread.sleep 导致 CPU 飙升、请求超时的现象，强调需使用 jdk 自带工具（如 top-H-P、jstack）定位线程状态，判断是否占用 Tomcat 工作线程。

线程池配置：指出将 sleep 改为线程池处理的思路正确，但需精细化配置，包括根据任务类型（IO/CPU 密集型）设置核心线程数、使用有界队列、选择合理拒绝策略（如 CallerRunsPolicy）。

资源隔离：提出不同业务需使用独立线程池，防止单个业务占满线程池拖垮所有接口，体现高并发系统的基础素养。

熔断兜底：建议为线程池添加动态监控和自动熔断机制，通过 Metrics 监控活跃线程数、队列积压数，配置阈值触发熔断，避免系统被拖死。

视频通过四层拆解，揭示 Thread.sleep 问题背后的线程资源管理、线程池原理及高并发系统设计思路。

问题场景：服务运行两年后突然 OOM，重启后同一时间点再次 OOM，代码中 ThreadLocal 存储 UserContext（含 HashMap）且每次请求结束调用 remove ()。

核心原因：线程池复用导致 ThreadLocal 中的对象未被销毁，随请求累积占用内存；用户量翻倍、线程池扩容加速了内存泄漏。

三层防御：现场快照用 MAT 定位根因，压测设计长时循环监控老年代曲线，代码层通过 try-finally、工具类封装、弱引用等方式防御。

该问题考察开发者对内存管理的深度理解，需从工具使用、压测设计到代码规范全面覆盖。

缓存穿透：描述为查询缓存和数据库均不存在的数据，解决方案包括缓存空对象和布隆过滤器，布隆过滤器通过位数组和多个哈希函数实现，存在小概率误判。

缓存击穿：指热点 Key 过期导致大量请求同时访问数据库，推荐使用互斥锁或逻辑过期解决。

缓存雪崩：因大量 Key 同时过期或 Redis 宕机引发，可通过过期时间加随机值、Redis 高可用和熔断降级应对。

布隆过滤器深度解析：详细讲解其数据结构、添加与查询逻辑、误判场景及参数选择，强调其高效但存在误判的特点。

视频最后总结了缓存问题的分层回答框架，指出大厂更关注原理、方案、适用场景和坑点的掌握。

问题场景：实时风控系统用线程池处理规则，上线两周稳定，第三周高峰期 CPU 飙至 95%，接口响应从 50 毫秒增至 5 秒；服务器 CPU 极高，但 jstack 显示所有业务线程处于可运行状态，无死循环、无 GC 风暴，内存仅用 40%。

核心陷阱：线程数超过 CPU 核心数时，CPU 大量时间花在上下文切换而非执行业务逻辑，该问题常因排查停留在看堆、找死循环层面被忽视。

三层能力：第一层通过 vmstat、pidstat、jstack 等命令定位上下文切换问题；第二层压测模拟任务提交速度高于处理速度的场景，设置线程数预警；第三层根据业务类型（CPU 密集型 / I/O 密集型）合理配置线程池大小，使用有界队列和谨慎的任务拒绝策略。

视频指出线程池配置不当可能成为 CPU 上下文切换的催化剂。

内存结构差异：G1 将堆划分为多个独立的 Region，年轻代与老年代均由 Region 集合构成；而 CMS、Parallel GC 等其他收集器的老年代为整体连续空间，无 Region 划分。

回收逻辑限制：非 G1 收集器因老年代结构限制，只能选择完全回收或不回收老年代；G1 则可基于 Region 挑出垃圾多、回收收益高的老年代区域进行部分回收。

Mixed GC 核心：Mixed GC 需同时回收全部新生代垃圾与部分老年代 Region，该模式仅 G1 的 Region 化结构可支持，其他收集器缺乏细粒度回收基础。

Mixed GC 是 G1 适配大堆、低延迟场景的核心机制，可避免 Full GC 导致的服务卡顿。

面试场景还原：面试官以电商大促期间订单系统接口超时、数据库连接池爆满的真实事故提问，开发者先回答加连接数、查慢 SQL、拆长事务，后续被追问连接泄露定位工具、连接池参数调优时，仅能背诵基础理论，无法结合业务并发模型计算参数值。

连接池保卫战三板斧：视频提出从监控、代码、架构三方面解决连接池问题，包括三层监控联动锁定根因、优化事务边界与连接参数、通过读写分离和缓存减轻数据库压力。

常见误区：多数开发者对连接池的理解仅停留在配置最大连接数，遇到真实雪崩时无法有效排查。

视频强调连接池全链路调优是 Java 工程师从熟练到精通的必修课。