通过QPS和并发数定位问题

QPS和并发数如图：

现象：接口大量504.

一、现象分析

1. 请求堆积与响应延迟
   • 每秒到达300个请求（这也可能是前面积压的请求，还没有返回。所以越积越多），但系统每秒只能处理16个，意味着 每秒积压284个请求。
   • 请求处理时间被迫延长（假设无超时）：
     平均响应时间 = 并发数 / QPS = 300 / 16 ≈ 18.75秒
     用户可能遇到超时（HTTP 504）或客户端主动取消请求。
2. 资源耗尽
   • 线程池阻塞：若使用同步线程模型（如Tomcat默认配置），线程池会被占满，新请求进入等待队列，最终导致队列溢出（RejectedExecutionException）。
   • 数据库连接池耗尽：若每个请求依赖数据库操作，连接池会被占满，触发CannotGetJdbcConnectionException。
   • 内存溢出：积压的请求可能导致内存中对象堆积，频繁触发GC甚至OutOfMemoryError。
3. 雪崩效应
   • 单个接口的阻塞可能扩散到整个应用，导致其他接口也无法正常响应。

---

二、根本原因排查方向

1. 代码性能瓶颈

• 慢SQL：检查是否有未优化的查询（全表扫描、缺失索引）。
• 同步阻塞操作：如同步调用外部API、文件IO、未使用缓存导致重复计算。
• 锁竞争：不合理的synchronized或ReentrantLock使用导致线程阻塞。
• 低效算法：时间复杂度高的操作（如嵌套循环处理大数据量）。

2. 资源配置不足

• 线程池容量不足：Tomcat默认线程池（如maxThreads=200）可能不足以处理300并发。
• 数据库连接池过小：例如HikariCP默认maximumPoolSize=10，远低于并发需求。
• JVM内存不足：堆内存过小导致频繁GC甚至OOM。

3. 外部依赖瓶颈

• 依赖的第三方服务或中间件（如Redis、Kafka）性能不足，成为瓶颈。

---

根据接口查看代码，发现一个问题：
更新一个表的数据时，如果没有找到该数据，会进行全表扫描。
当时表数据量小，没问题。但是后面随着业务扩展，表数据大的时候，就会很慢。