通过QPS和并发数定位问题
QPS和并发数如图：
现象：接口大量504.
一、现象分析
- 请求堆积与响应延迟
- 每秒到达300个请求，但系统每秒只能处理16个，意味着 每秒积压284个请求。
- 请求处理时间被迫延长（假设无超时）：
平均响应时间 = 并发数 / QPS = 300 / 16 ≈ 18.75秒
用户可能遇到超时（HTTP 504）或客户端主动取消请求。
- 资源耗尽
- 线程池阻塞：若使用同步线程模型（如Tomcat默认配置），线程池会被占满，新请求进入等待队列，最终导致队列溢出（RejectedExecutionException）。
- 数据库连接池耗尽：若每个请求依赖数据库操作，连接池会被占满，触发CannotGetJdbcConnectionException。
- 内存溢出：积压的请求可能导致内存中对象堆积，频繁触发GC甚至OutOfMemoryError。
- 雪崩效应
- 单个接口的阻塞可能扩散到整个应用，导致其他接口也无法正常响应。
二、根本原因排查方向
1. 代码性能瓶颈
- 慢SQL：检查是否有未优化的查询（全表扫描、缺失索引）。
- 同步阻塞操作：如同步调用外部API、文件IO、未使用缓存导致重复计算。
- 锁竞争：不合理的synchronized或ReentrantLock使用导致线程阻塞。
- 低效算法：时间复杂度高的操作（如嵌套循环处理大数据量）。
2. 资源配置不足
- 线程池容量不足：Tomcat默认线程池（如maxThreads=200）可能不足以处理300并发。
- 数据库连接池过小：例如HikariCP默认maximumPoolSize=10，远低于并发需求。
- JVM内存不足：堆内存过小导致频繁GC甚至OOM。
3. 外部依赖瓶颈
- 依赖的第三方服务或中间件（如Redis、Kafka）性能不足，成为瓶颈。
根据接口查看代码，发现一个问题：
更新一个表的数据时，如果没有找到该数据，会进行全表扫描。
当时表数据量小，没问题。但是后面随着业务扩展，表数据大的时候，就会很慢。