本文目录导读：
- 第一名：P99/P95 延迟过高（响应时间之长，导致雪崩）
- 第二名：内存溢出（OOM）导致进程直接崩溃
- 第三名：CPU使用率100%（持续满载）
- 第四名：数据库连接池耗尽
- 第五名：负载均衡（QPS/TPS）上不去
- 总结：哪一项最致命？
- 给参赛/面试者的急救锦囊（如何避免拿到致命数据）：
在Java综合赛后（比如一场涉及性能、并发、内存、代码质量等多维度的综合评审或压测），如果要评选“最致命”的数据，99%的场景下，答案都是：高并发下的“响应时间（RT）飙升”或“超时（Timeout）”。
虽然内存溢出（OOM）和CPU打满（100%）听起来更吓人，但从实际事故定级和业务影响来看，“响应超时”才是综合评分中被扣分最狠的。
下面我按致命程度从高到低为你排序，并拆解原因：
第一名：P99/P95 延迟过高（响应时间之长，导致雪崩）
为什么最致命？
- 业务层面：用户面对超过2秒的等待会直接流失，在综合赛后评审中，这代表系统不可用。
- 技术层面（雪崩效应）：当后端服务响应变慢，前端的连接池、线程池会被占满，新的请求进不来，堆积的请求越来越多，最终导致Tomcat/Netty线程耗尽，整个服务宕机。
- 评委视角：如果你的平均RT是200ms，但P99达到了5秒，说明你的系统存在严重的长尾效应（比如某次GC停顿、或数据库慢查询），这代表系统完全不抗压。
第二名：内存溢出（OOM）导致进程直接崩溃
为什么致命？
- 直接死亡：进程直接退出（JVM Crash），没有任何系统能在OOM后还能自愈，除非配置了重启脚本，但重启往往意味着数据丢失。
- 排查难度极高：在赛后复盘时，OOM往往意味着你的代码有内存泄漏（如静态集合无限增长、线程池队列无界、大对象未释放）。
- 数据指标：在压测中，如果堆内存使用率长时间维持在90%以上并伴随频繁的Full GC（Full GC次数大于每分钟10次），这已经是危重状态。
第三名：CPU使用率100%（持续满载）
为什么致命？
- 隐形杀手：CPU 100%时，系统不会立刻挂，但所有线程都在抢CPU时间片，导致响应时间急剧恶化（这时你会看到RT数据爆炸）。
- 根因：通常是因为死循环、频繁的GC日志打印、或者低效的算法（例如在循环内使用
String +拼接，或者嵌套三层大循环）。 - 综合赛中的残酷现实：如果CPU飙到100%，说明你的代码写得很“贵”——消耗了大量无谓的CPU算力。
第四名：数据库连接池耗尽
为什么致命？
- 次生灾害：它不直接杀死Java进程，但会让服务僵死，所有线程都在等待数据库连接释放，导致业务完全停滞。
- 指标信号：
HikariPool-1 - Connection is not available, request timed out。
第五名：负载均衡（QPS/TPS）上不去
为什么致命？
- 上限太低：别人的系统轻轻松松扛住10万QPS，你的系统在8000 QPS时就开始报错或抖动，这说明你的并发模型（如使用了
synchronized锁住了全流程，或者没有使用线程池）存在严重瓶颈。 - 虽然致命，但通常排在超时和OOM之后，因为它不会导致系统瞬间全挂，只是“抗压能力差”。
哪一项最致命？
“响应时间（RT）的失控”是最致命的。
原因在于连锁反应： 高RT → 线程池耗尽 → 连接池耗尽 → 请求堆积 → CPU飙升（处理垃圾请求） → 最终OOM或服务挂死。
如果在综合赛后只能改一个数据，请盯着你的“压测尾段延迟”和“错误率”。 只要错误率（Error Rate）不为0%，你的整体评分就会直接从A级降至C级。
给参赛/面试者的急救锦囊（如何避免拿到致命数据）：
- 控制超时时间：所有第三方调用（DB、Redis、外部HTTP）必须设置超时阈值（如
setConnectionTimeout(500ms)）和失败降级策略。 - 隔离线程池：不要用一个共享线程池处理所有接口，避免慢接口拖死快接口（Bulkhead隔离舱模式）。
- 幂等与重试：如果数据是写操作，重试机制如果没有幂等保护，很可能导致数据重复，这在综合赛中是“业务逻辑致命伤”。
