Java Web应用高并发吞吐量下降，JMeter测试响应突降原因排查

针对你描述的场景——50线程压测稳定，100线程前10分钟正常、之后响应恶化，核心是高并发持续运行后的资源耗尽或累积性问题，可从以下维度逐一排查：

JVM相关问题 #

• 内存泄漏/频繁Full GC：持续高并发下，未释放的对象（比如静态缓存未清理、数据库连接泄漏）堆积，导致堆内存占用飙升，触发频繁Full GC，引发STW（Stop-The-World）拖慢响应。
  • 用jstat -gcutil <进程ID> 1000实时监控GC频率、回收效率，看是否有Full GC次数陡增的情况；
  • 用jmap -dump:format=b,file=heap.hprof <进程ID>导出堆快照，分析对象引用链定位泄漏点。
• 线程池耗尽：自定义线程池的核心线程数、队列容量设置不合理，高并发下任务堆积，线程阻塞或触发拒绝策略。用jstack <进程ID>查看线程状态，是否大量线程处于WAITING/BLOCKED状态，或线程池队列积压。
• 元空间溢出：若应用使用动态代理、热加载等技术，元空间持续占用上涨，触发Full GC。用jstat -gcmetacapacity <进程ID>监控元空间使用率。

数据库层面瓶颈 #

• 连接池耗尽：数据库连接池最大连接数不足，100线程下连接被占满，后续请求等待获取连接。查看连接池监控（如Druid面板），确认连接数是否达上限，或代码中是否存在未关闭的Connection/Statement。
• 数据库资源过载：高并发下数据库CPU、磁盘IO打满，或慢查询、锁竞争加剧。
  • 执行SHOW PROCESSLIST查看是否有大量慢查询或锁等待线程；
  • 监控数据库服务器的CPU、磁盘IO使用率，是否超过阈值。
• 缓存雪崩：缓存大量同时过期，所有请求直接穿透到数据库，导致数据库压力骤增。检查缓存过期时间配置，是否存在批量key同时失效的情况。

系统级资源瓶颈 #

• CPU耗尽：应用服务器CPU使用率长期100%，线程无法及时调度。用top/htop查看整体CPU占用，pidstat -t <进程ID> 1定位进程内占用CPU最高的线程（是GC线程还是业务线程）。
• 磁盘IO瓶颈：频繁写入DEBUG日志、临时文件未清理导致磁盘IO繁忙。用iostat -x 1查看磁盘读写使用率，若%util接近100%则说明IO瓶颈。
• 网络带宽耗尽：100线程下网络流量达到服务器带宽上限，请求/响应传输延迟。用iftop/nload监控带宽使用，看是否接近峰值。

代码与并发问题 #

• 锁竞争加剧：全局锁、重量级锁导致高并发下线程阻塞等待。用jstack <进程ID>查找BLOCKED状态的线程，定位锁的位置（如synchronized块、ReentrantLock）。
• 资源句柄泄漏：文件句柄、Socket连接、Redis连接等未正确关闭，导致系统资源耗尽。用lsof -p <进程ID>查看进程打开的句柄数，是否持续超过系统限制（ulimit -n查看限制值）。
• 异步任务堆积：异步线程池容量不足，任务队列积压导致主线程阻塞。查看异步线程池的监控指标，确认队列长度、线程活跃数是否异常。

中间件/容器问题 #

• Web容器连接数限制：Tomcat/Nginx等容器的maxConnections/worker_connections设置不足，100线程下连接被占满，请求排队等待。检查容器配置文件中的连接数、线程数参数。
• 中间件性能下降：Redis、MQ等中间件出现瓶颈，比如Redis内存满触发淘汰策略、MQ消息堆积，导致依赖的API响应变慢。查看中间件的监控数据（如Redis的used_memory、MQ的消息堆积数）。

内容的提问来源于stack exchange，提问作者Rahul Tiwari