1、背景　　

在新版本程序中做了业务修改，需要给用户量比较大的金主爸爸升级包。交付测试过程中，想到客户量比较大，心血来潮要做一次模拟并发测试。（差不多2000次/s）。发现并发跑起来之后，页面其他接口反应相当迟缓，远没空闲时响应快。然后打回来说我写api存在性能问题，要优化，然后公司的大佬有其他事无暇顾及性能优化的问题。如此，就开启了第一次除sql优化外第一次性能优化路程。

2、初步排除：

2.1、系统运行内存：

测试机器是多个虚拟机公用一个运行内存32GB的硬件机，并发机器机器可用的实际内存并没有分配那么多。  shutdown其他机器，并发服务器给到和现场一样的配置，发现改观不大。  ｔｏｐ查看内存使用情况，内存使用率才２０％，占用率并不高。

2.2、数据库服务器允许最大连接数：

系统采用远程数据库，且最大连接数是4000，跟数据库链接池也没关系。

2.3、文件导致的IO阻塞：

接口有文件读写，检查后确认没有忘记关流的问题。将文件读写的代码块注释掉，并发情况下其他接口还是慢响应。　与文件读写没关系。　

2.４、本代码逻辑判断：

注释掉接口中所有的流程，并发情况下其他接口响应很快。   但是这个没有跑其他接口的并发并不能说明我api就有问题，这点自信需要有，但需要拿出证据捶他们。

 

到此，我心里有点发慌了，因为常规简单的方法都试了，并没有定位问题所在。然后，思来想去并和同事讨论后，可能是jvm某些机制，需要借助jvm调优工具辅助问题排查。

3、jvm调优工具：jps、jstat、stack、jmap等，云环境或者虚拟机环境可能没有对应的命令，需要yum安装

3.1、jps主要查看机器运行的Java进程pid：

3.2、jstat -gc <pid> 发现jvm fullGC并不频繁；

3.3、jstack <pid> > /tmp/tmp.txt将日志重定向到日志文件，vim /tmp/tmp.txt发现经常druid数据库连接时的blocked。截图如下：

 

 

 基本可以确定是数据库链接池相关的问题了。查阅资料发现：druid的jar包版本有问题，好像是小于1.1.24就有连接池无效的问题。https://github.com/apache/dolphinscheduler/pull/6484 这个问题跟我完全能一致，最后升级到1.2.8并将项目的连接池允许的最大连接数配置正成并发量相近的值，最后问题完美解决。

原来不是的问题，是由于jar包用的比较老旧，原架构就有问题。

4、最后：

之前一直以为jvm调优已经相关的命令只是在内存抗不住的时候才能用到，而硬件是可以堆上来的，也基本没有遇到过问题，对其进行了忽视。现在才发现可以通过相关命令查看线程死锁或者线程阻塞的详情。这非常有利于我们定位很多棘手的疑难杂症。

不要排斥陌生的技术，学到了就是自己的。

 

参考文档：

https://github.com/apache/dolphinscheduler/pull/6484

https://blog.csdn.net/qq_26502245/article/details/108510839