Prämisse:
1. Das Unternehmen führte einen Stresstest auf einer Maschine durch, die mit dem HTTP-Dienst bereitgestellt wurde. Der Test wurde eine Nacht lang (10 Stunden) durchgeführt (jeweils 200 Parallelität), und der Durchsatz betrug ca 56 %. Am nächsten Tag (Tomcat wurde in diesem Zeitraum nicht neu gestartet) wurde ebenfalls ein Nachttest (10 Stunden) (jeweils 200 Parallelität) durchgeführt, der Durchsatz sank jedoch auf etwa 16 %. Die Umgebung ist die gleiche, warum ist die Lücke so groß?
2. Als ich am ersten Tag einen Stresstest mit 1.000 Parallelität durchführte, betrug die Anzahl der Threads etwa 1.000+. Als ich jedoch am zweiten Tag einen Stresstest mit 1.000 Parallelität durchführte, betrug die Anzahl der Threads auf 700+ gesunken. Warum ist die Anzahl der Threads vorher auf 700+ gesunken? Dies ist direkt proportional zur Anzahl der Threads, aber nicht später?
Verfügt Tomcat für die beiden oben genannten Prämissen über Strategien oder verursacht der JDBC-Verbindungspool oder der Redis-Verbindungspool das obige Phänomen (unter Verwendung des G1-Recyclingmechanismus)?
这情况就复杂了，其复杂度取决于你的项目运行环境、依赖哪些其他服务。如果你的压测环境复杂（就是很多人都在你这台服务器上运行自己的东西），那压测结果不稳定是可以预见的。
遇到吞吐量下降时，先判断瓶颈在哪里：
本机资源是否紧张。本机资源主要包括 CPU、内存、网络带宽和磁盘吞吐。这些都需要进行观测排查。
依赖服务是否紧张，如数据库、外部接口是否处理时间过长。
如果这些都无法明显定位问题所在，那就进入程序调试阶段了：在每个请求处理过程中，记录每一步的时长，找出瓶颈在哪一步，这个粒度会很细，会要反复修改日志，反复运行，反复观察，但一定会找到问题。
不要一遇到问题就做没有根据的胡乱猜测，这时候“发散思维”帮不上忙，要做的是对问题顺藤摸瓜，严谨分析。