前语

留意看，这个男人叫小帅，他正在做一个老体系的重构，其中有一个查询接口慢到了不起不改的地步，面对完全不熟练的项目，一脸懵逼的他会选用什么样的手法来脱离窘境呢，让咱们一同走进科学。嘴瓢了，哈哈，天降大任于斯人也，必先送其屎山，请叫我掏粪男孩。骚话说过了，接下来说点正经的。其实我个人仍是比较喜爱这样的优化使命的，平常我也会经过我的代码风格以及言传身教(夸张一下，都别打我)来影响搭档们，我感觉咱们的技巧是有提高的。可是呢，一直以来也没有一个详细的总结，那么今日便是圣剑解封之日，新手接口优化完全攻略，咱们一同来装逼吧！

接口背景

查询页面如图，总数其实不多就1W3，列表横向展现约90个字段。关于这儿展现字段过多的问题，我提一嘴，这是用户强制要求的，而且该体系已上线，所以这个问题不能叫做问题。除此之外，该列表也并非普通的单表查询，存在联查和字段填充，约30个字段存在额定逻辑，其中最要命的库存字段需求实时查库，也便是说不能缓存。本项目为部分中心项目，因而查询细节不好说，大致便是会经过许多运算，最终拼成一个列表回来给前端。没错，咱们了解的屎山便是这样，又臭又长。

接口现状

我，作为京城牢头兼优化小能手，自然是见义勇为(呜呜呜)，成了被选中的人。项目作为中心项目，自然是有着中心的杂乱度，至少刚看到项目代码和听人解说了一遍后，我感觉和没听一样，淦。给了一天的时刻来优化，这个感觉，对味了，仿佛回到了之前做看板项目的时分(详见设计方案-大数据量查询接口优化)。接口的现状自不必多说，代码中少的不幸的注释，仅有的注释也看不了解(刚开始不懂事务)，大概五百行的中心代码和一堆到处乱跳的内部办法以及好几坨大SQL……令人失望的现状，也没办法，拼好破碎的道心开始着手进行优化。

喔，对了，说一下之前的状况。该查询接口究竟是高频查询接口，而且现已上线了，之前是现已优化过一轮了，听说没优化前甚至会触发网关超时。至于大半年后为啥又出现了接口慢的问题，应该是跟联表和多个数据源的数据膨胀有关，导致当时快的子查询渐渐变得功用低下了。

优化及整理预备

一个查询接口的优化，我的思路仍是比较简略，先上通用解决方案，再依据事务逻辑进行深度定制优化。熟练的打开查询页面，按下F12键，拿到查询接口入参和对应接口地址。拉下代码，问问搭档主分支用的哪个，将正式数据同步到开发环境，启动项目，postman调用接口，趁热打铁。

我测，15s，好家伙，怪不得要优化，我要是用户也受不了。而且前端展现字段是装备化的，也便是说列表查询接口还有前置的页面装备获取，加上前端渲染后，其实体感更慢。切到IDEA，看看代码，捋了捋，差点背曩昔，五百行的代码加上七八个SQL，还短少注释……我先晕一会儿。

活了，接着吹打接着舞。一般我将这种杂乱查询类的接口，内部逻辑代码依照类型分为三种，数据源、核算、拼接。

• 数据源型，一般是经过SQL或许外部接口获取数据。
• 核算型，一般是某些字段需求经过核算得到，这部分代码也要独自符号，优化的时分拆分出来
• 拼接型，通常查询没有这一步，可是部分动态表格，前端会要求特别的数据结构，这种情况下会有，可是一般也不需求优化。

假如不想重构代码的话，能够简略写个TODO打个夺目的符号，特别是数据源和核算类的代码，这将会是咱们进行优化的要点。在整理期间还能够做一下小优化，这些优化由于不太影响功用，所以不作为优化手法展现。

整理代码

当然在进行这一步的时分，我会挑选依照IDEA的夺目提示以及对代码的了解干掉一些无用和重复的代码。一起尽量从头定义变量名，改成自己能看懂的，而不是abc123之类的。

代码剪枝

代码剪枝的意思是假如内层函数没有别的引用，我会挑选将代码兼并到当前办法中，防止乱跳，看着麻烦。

兼并循环

像这种不影响其他部分核算的循环，完全能够兼并到其他必要的循环中，削减循环。这儿只要一页查10条数据，循环10次比较少，看不出优化效果，可是这是个好习惯，不是吗？

抽取公共变量，防止重复操作

这一步便是整理数据源的含义地点，当代码行数过多，而且有几个开发接手过的情况下难免产生。一个查询A，我在办法A中写过了，可是到了办法B，可能是新加的功用，换人了或许忘了之前写过，又重复一次查询A，这完全是没有含义的。

优化手法

一切的优化并不是无芯浮萍，针对问题去优化才是咱们该做的，不要在收益不高的当地去用力。在做完整理预备后，将置疑代码块圈起来打印运行时刻，这种比较朴素，没办法再这样。

我是引荐咱们搭配功用剖析插件来定位，比方XRebel、Skywalking。内存和CPU一般不在查询接口优化的考虑规模，当然要看的话，我引荐IDEA自带的Profiler插件。在本次优化中，我是运用了IDEA插件商场里的XRebel来进行接口功用剖析，详细的安装和运用能够网上搜一下，剖析成果如下图。

这儿是19秒，正常，由于正式服务器和数据库比我本地功用要高，自然要快一些。这都不重要，细看一下图，很明晰，甚至连可执行的SQL都放上去了。每一行从左到右依次是执行时刻、办法名，详情里边是详细的可执行SQL。经过观察能够发现耗时比较长的有setDeliveryCalculationInfo中的setStock和setCalculationInfo办法，详细是由于SQL查询慢了，定位到了问题代码块那就能够着手进行优化了。以下仅经过实战的视点介绍效果够大的办法，就不多讲废话了。

缓存

缓存真的是空间换时刻的首选利器，分布式缓存Redis或许本地缓存Caffeine任君挑选。虽然是额定增加了中间件，可是现在项目一般都会有吧，所以在我看来这是改动收益性价比最高的一种办法。运用缓存也很简略，能够提早或许随查询将固定或许可预期改变时刻的成果放入缓存，设置适宜的过期时刻即可。当然这么简略的手法，优化过一次的接口必定早就用上了(淦，我就知道没有那么简略！)，剩余的都是要求实时查询的SQL。

SQL优化

SQL优化这部分我现已讲过太多了，SQL句子优化能够看从零开始的SQL修炼手册-实战篇(32保藏)，设计思维和硬件优化看口语化解说数据库优化(11保藏)。但从我个人视点而言，由于我是做的供应链事务，首要是去简化ERP上的逻辑，定制化开发。受限于一些固定的表结构，导致很简略有大SQL，比方两三百行那种，各种联查子查询。你们懂的，反正在我这，这种杂乱SQL，是性价比很低的优化操作，我一般挑选不动，玩玩索引得了。

List转Map

经典空间换时刻的优化手法，在算法中比较常用，当然实践开发中也是必要的优化手法。这个手法呢，我之前有篇文章功用优化-怎么爽玩多线程来开发(72保藏)讲过，和搭档也讲过，算是我比较喜爱的一种优化办法。先说说优点，最大的优点便是削减数据库查询或许外部接口调用次数，比方你用参数A+B查询数据库，循环调用10次就有10次查询数据库。但你换个视点，一次性全查出来然后转化为Map，将参数A+B当作Key从Map里取，那就少了9次数据库查询，这个功用提高是十分巨大的。

当然不行忽视的还有较大的难度，但只要做好预备，仍是比较简略的，还记得前面提到的优化整理吗？数据源类的代码拆分出来后，需求了解SQL的内容，怎么修正SQL去一次性查出想要的数据是优化的第一步。举个例子，这儿有个办法耗时12秒，里边每个SQL其实查询不慢，也就1秒，这种SQL优化还有含义吗？必定没有啊，紧缩成几百毫秒，集腋成裘也仍是坏事啊。所以要改SQL，将这10次查询成果紧缩成一次查询。

比较走运的是只要一个条件，那么简略粗犷的改成IN查询即可。

一起由于获取了全量的数据，要特别留意内存占用的问题，防止产生OOM。常见优化手法有，削减数据传输，回来指定字段，并用精简后字段的包装类去接SQL成果，而不是直接拿实体类去接。之前有个OOM的问题便是几十万的数据，本来也不多，就那么几个有用字段，成果拿一个有一百多个字段的实体类去接，最终占用了1G内存。最终定位到问题，解决也简略，换个包装类只接有用字段，内存占用一下就降下来了。

List转Map这儿我比较喜爱直接用JDK8的Stream流来转化，这儿value留意一下，不一定给整个实体类，按需即可。比方我这儿便是简略的产品名称对应数量，那么value用数量就行了，细节该留意仍是留意一下。

最终必定是要改一下代码的，依照如下图的思路去做改变即可。提一嘴，前期整理预备很重要，否则你都不知道在哪改这些代码。

多线程

提高功用的不贰法宝，上面List转Map首要针对的是能进行改造的SQL。所谓能改造的SQL是说，查出来的全量数据大小适宜，而且本身紧缩后的SQL也快。那么假如有很多联查，打死也紧缩不了咋整呢，来人啊，上多线程。传世经典功用优化-怎么爽玩多线程来开发(72保藏)还提到了别的三种法宝，分别是并行聚合处理数据、修正for循环为并行操作、修正Map遍历为并行操作。

• 并行聚合处理数据首要运用CompletableFuture.allOf()办法，将本来串行的操作改为并行，来紧缩多阶段核算的总时刻。
• 修正for循环为并行操作首要针对查询数据库或许调外部接口这种很多IO的场景。
• 修正Map遍历为并行操作则是为了提高Map的遍历功率，和修正for循环同理。

微醺码头

来码头整点薯条，休息一下。以上为通用查询接口的常用优化手法，差不多能覆盖八九成的开发情况了，接下来会扩展一下相关知识点。

恳求兼并

将多个恳求兼并，一致处理后回来成果，简略来看，便是将一个接口改成了逻辑上支撑批量恳求。一般是高并发情况下才会用到，而且要求调用方能支撑回来后的一致处理成果，所以尽量能不必就不必。

实现的话，引荐用结构比方hystrix，这种会比较有保证。假如自己弄得话，能够用ConcurrentLinkedQueue作为收集恳求的队列，CompletableFuture来控制恳求的调用，newScheduledThreadPool来守时一致执行兼并后的恳求，这个我就不贴详细实现代码了，网上挺多。

集群核算替代单机

典型堆硬件产生突变的例子，比方将杂乱的核算分片拆分到集群的各个机器上，最终汇总核算成果回来即可。最大化使用机器，这个分片思路其实蛮常见的，比方用elastic-job分布式使命调度这个守时结构里，就很明显的在入参处传递了分片。

好文引荐

看了不少，田螺哥的这篇实战总结！18种接口优化方案的总结，总结的比较全面吧。阿里开发者的浅谈体系功用提高的经验和办法则从更大的视点去论述了功用优化这个大模块。后期我也会写一篇功用优化相关的文章，带有我的一些了解和实战，敬请期待嗷。

还有个事说一下，咱们可能比较关心，最近怎么挖掘项目中的亮点(多方向带事例)(114保藏)又火起来了，所以本文也被总结成一段亮点追加到文章中了，欢迎咱们跳转观看。

写在最终

哈哈，淋漓尽致，写完JVM之后再写我喜爱的便是直爽！本文依旧是为咱们带来幸福快乐的装逼小技巧，为了完成人人装逼的巨大梦想，特意用相对口语化的表达办法(也是我最喜爱的)完成了本篇。说回正题，本篇是查询接口的功用优化，是针对单一场景的优化技巧。当然其他的当地也能够参阅运用，究竟优化的思路都是相通的。

再来说说近况，依旧是鸭梨山大┗|｀O′|┛ 嗷~，哎，不过没办法，实际这个磨人的小妖精真是让人欲罢不能。下一篇不出意外会是口语化系列，讲MySQL，手里还攥着一篇重构体系的素材，假如顺利的话，下周或许下下周出吧。最终的最终，仍是祝咱们身体健康、工作顺利，这儿是愿世界开满幸福快乐之花的Java菜恐龙，下周见啦~