近期查了一个Java性能的case，在此记录下。场景是一个query，查询db，然后聚合计算，返回结果给用户，现象是大规模query超时。
统计query各阶段耗时
一次query分为scanAndMerge、groupBy、aggregation三个阶段，通过统计发现主要耗时在ScanAndMerge阶段。
统计scan与merge耗时
scanAndMerge主要逻辑是一个while循环，从一个BlockingQueue取数据（有一组writer异步向BlockingQueue写数据），然后merge到一个map的数据结构。通过统计发现主要耗时发生在merge结算。
jprofile统计cpu热点
使用jprofile统计发现merge逻辑确实是cpu热点，merge有十万次调用，而merge内部的一些函数调用有千万次调用，怀疑merge内部实现时间复杂度较高。
看merge实现代码
merge内部有两路逻辑，递增插入时间序列命中逻辑A，时间复杂度低；乱序时间序列命中逻辑B，时间复杂度高。正常情况下，均为递增数据，不应命中逻辑B；但是从merge内部时间复杂度来看，疑似命中逻辑B，疑似插入时间序列乱序。在某个query，100%复现此case，故决定debug对插入时间序列进行验证。
尝试使用intellij进行debug
尝试使用intellij进行debug，因为服务器与mac间网络太差，intellij debug需回传大量class信息，导致不可用，于是放弃。
使用jdb进行debug
在服务器上使用jdb对jvm进行进行debug，通过打断点，打印插入数据变量，发现插入时间序列确实为乱序，且有大量重复数据。
代码分析
代码逻辑很简单，从db去数据然后进行merge，且为了提高并发会有n路此流程进行。故乱序可能有两种原因导致，一个是db返回的数据确实为乱序，另一个是并行n路程有冲突。
验证db返回数据
与db间采用thrift协议通信，故模拟java程序快速写了一个python程序从db取数据，发现所取数据并无重复，也无乱序。且负责db的同学看代码也非常确定，故db返回数据基本确定无问题。故怀疑n路并行查询逻辑有问题。
最后确认是n路并行查询逻辑的问题
看配置文件，db有2个shard，内部建立了2个shard client。但是有8路并行查询，每个查询逻辑对应2个shard client中的一个，导致有4路查询都是对应一个shard client。故当某一个组查询一批时序数据后（命中时间复杂度低的逻辑A），会再有3组查询插入相同的时序数据（命中时间复杂度高的逻辑B），导致整体查询小时间复杂度过高。
问题解决
解决问题的方法很简单，暂时把8路并发查询改为2路即可。
总结
此类似case只是简单地去分析慢的原因，思路总结如下：
- 确定是否gc有问题，如有先解决gc问题
- 看代码确定哪个线程慢
- 看该线程的函数cpu热点
- 如果没有热点，该线程可能与其他线程有锁，可以看jvm各线程状态时序图、分析jstack
- 如果有热点，则可能有同步IO请求，或者高时间复杂度逻辑
附录
jprofile使用方法
服务器端安装jprofile程序，执行jpenable命令，选择要profile的jvm pid，输入要监听的端口。
在本地启动jprofile图形界面，输入ip、port，进行profile即可。
intellij debug使用方法
服务器端java进程启动参数增加
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
在本地打开intellij，配置debug的ip、port，然后启动debug，可打断点进行调试。
jdb使用方法
服务器端java进程同intellij debug增加如下参数
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005
上传java源代码到服务器端，使用jdb命令进行调试
jdb -sourcepath sourcecode/src/main/java/ -attach localhost:5005
常用jdb command
stop at : // 开启断点
clear : // 清除断点
list // 显示当前代码配置
print // 打印变量值
next // 下一个
cont // 跳过本次断点