前言

最近随着国产化热潮，公司的用于营业的电脑全部从windows更换成了某国产化电脑，换成国产化之后，我们系统的前台web界面也由之前的jsp页面重构成vue.所以之前的一体式架构也变成了前后端分离的架构。但是在更换过程后，发现一些接口耗时相当长。虽然之前可能也不快，但是之前都是前后台在一起的，耗时长也没关系，多等一会儿就显示出来了，但是由于接入服务网关，服务网关请求后有超时时间限制，所以不得不优化了。

排查思路：

排查前先看下未优化时调用的耗时情况。

1、先确定程序慢在了哪里？

使用arthas工具跟踪接口，如下：

从上图可以看出，耗时主要发生在civilPrint()这个方法上，
继续跟踪civilPrint方法

下面还有很多行这样类似的代码，就不贴出来了。

从上图可以看出耗时很大程度是由嵌套循环引起的，然后一些频繁的get,set方法累积起来导致耗时贼长。

2、根据业务分析是否可以从业务逻辑上优化。

从上面可以看出嵌套循环是引起耗时的主要原因，那么需要从业务层面来分析一下，看了代码之后发现，嵌套的原因是：
用户通过查询数据库，获取到关联的所有用户，然后遍历用户，查询每个用户的其他信息。然后将这些信息放到List中做为出参供前台使用。业务看起来很简单，但是貌似也不能改变这种逻辑。

3、如果不能从业务逻辑上优化，那就要考虑从代码角度优化了。
既然从业务的角度不能优化，那么就要从代码层面来尝试解决了。

还有类似这种的让人看了头大的，一个方法中出现了还不止一次。

这些其实都是引起业务慢接口耗时长的一些原因。但是将这些写法优化后，还是不太理想，由于是嵌套循环，最后还是考虑使用多线程来优化，用户查询出的结果，放到线程中去处理，然后各自将处理结果放到集合中，主线程等待所有线程处理完毕之后，再进行下一步。这样耗时就会大大缩短。
优化后的关键代码如下：

这里要注意下锁的释放，一定要放到finally中去处理，否则一旦报错导致程序执行失败，线程就会一直处于等待状态。

最后看下优化后的效果：

开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第13天，点击查看活动详情