--- theme: healer-readable --- ### 小菜的一次接口优化：从68474ms到1329ms ### 前言突然，有人大喊一声：小菜，你过来一下小菜被吓得抖了一抖，连忙切出开发界面，看了一眼，原来是项目经理在喊小菜屁颠屁颠的过去后项目经理：小菜，有空你看看后台管理里的商品信息导出Excel功能，导出数据只有几千条但是要等特别久小菜：没问题，等我忙完手上的活就来看看怎么回事 ### 分析与优化小菜回到工位后，立马看了看后台管理系统的商品信息导出功能该功能是通过导入规定格式的Excel（比如商品名称），然后导出这些商品的所有信息小菜用对应的模板（大概数据量5千）使用此功能，大概等了1分钟多才导出结果小菜：我可以先用arthas的trace监听这个接口，看看接口里哪些方法耗时，再具体进行分析 ![5ebf0da94e3d187b59b79e81cb66baa.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6c2616c2554947129f4158cde77bb3d2~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=1118&h=88&s=27518&e=png&b=022356) 使用arthas的trace命令监听端口后，发现总耗时70284ms，其中`XXMessage`耗时68s，导出Excel花费1.8s 小菜：那具体的业务处理应该在`XXMessage`里了，我先来看看 ```java public List xxMessage(MultipartFile file, HttpServletRequest request, HttpServletResponse response) { //导出结果 List exportVOS = new ArrayList<>(); try { //EasyExcel 读取模板数据 //使用AnalysisEventListener 在读取数据时加入导出结果，在读完后进行封装操作 EasyExcel.read(file.getInputStream(), Product.class, new AnalysisEventListener() { private final List list = new ArrayList<>(); //解析完一行后如何处理 @Override public void invoke(Product p, AnalysisContext analysisContext) { doLine(p); } //解析完所有数据后如何处理 @Override public void doAfterAllAnalysed(AnalysisContext analysisContext) { doAfter(); } }).sheet().doRead(); } catch (IOException e) { e.printStackTrace(); } return exportVOS; } ``` 小菜：使用的EasyExcel读取，那真正的处理应该在实现的AnalysisEventListener中小菜：让我先来看看每解析一行如何处理的 ```java //存储要处理的数据 List products = new ArrayList<>(); private void doLine(Product data) { try { //拿到所有使用ExcelProperty的字段 List fields = Arrays.stream(data.getClass().getDeclaredFields()) .filter(f -> f.isAnnotationPresent(ExcelProperty.class)) .collect(Collectors.toList()); //判断字段是否为空，为空则集合添加false不为空添加true List lines = new ArrayList<>(fields.size()); for (Field field : fields) { field.setAccessible(true); Object value = field.get(data); if (value == null) { lines.add(Boolean.TRUE); } else { lines.add(Boolean.FALSE); } } //ExcelProperty的所有字段不为空就加入集合 if(lines.stream().allMatch(Boolean.TRUE::equals)){ products.add(data); } } catch (Exception e) { log.error("parse data fail: " + e.getMessage()); } } ``` （ExcelProperty注解用于标记表格中的列）小菜拿出做算法题分析时间复杂度的思路小菜：这里总共有三个循环分别是：获取使用`ExcelProperty`的字段、判断每个字段是否为空、allMatch匹配数组中所有元素为true 小菜：那么用时间复杂度表示就是`O（3N）`，N为数据量，而这些集合的数据量则是使用ExcelProperty的字段，好像是固定的，并不会随着Excel表格中数据量的提升而提升，那么可以把它们看成常量，那最终时间复杂度就是常量级别`O（1）` 小菜：但是还用了反射会有些性能开销小菜：咦？为啥要判断实体每个字段不为空才加入要处理的集合呢？小菜：好像直接判断该商品名不为空就可以了吧？小菜：用反射来实现通用性，难道这段代码是前辈复制的？于是，小菜洋洋得意的将代码改成： ```java //存储要处理的数据 List products = new ArrayList<>(); private void doLine(Product data) { if (StringUtils.isNotEmpty(data.getProductName())) { products.add(data); } } ``` 为了担心自己改错，小菜还保留原始代码，方便回滚再来看下解析完数据后的处理方法小菜看着这一望无际一百多行没有注释、多层if嵌套的代码，整个人都呆了大致观看了一遍后，小菜将shit mountain代码梳理成以下代码： ```java //存储要处理的数据 List products = new ArrayList<>(); private void doLine(Product data) { if (StringUtils.isNotEmpty(data.getProductName())) { products.add(data); } } private void doAfter() { //要处理的数据为空直接返回 if (Empty.isEmpty(products)) { return; } //循环处理数据 products.forEach(product->{ //根据商品名查询出商品列表 IO List skus = skuService.list(product.getProductName()); //查到商品数据为空跳过 if (Empty.isEmpty(skus)) { continue; } //查询商品具体数据 IO //查询分类、规格... IO //封装实体添加到导出列表 }); } ``` 看到这里小菜一下就明白为什么接口这么慢了小菜：好好好，你这样写代码是吧小菜：不考虑查数据库的网络IO是吧，肯定是不想写联表SQL，偷懒直接用MP 小菜直接用一次联表查询替代这么多的查询，为了避免数据量太大，小菜设置每次处理的最大数据量，分多次处理 ```java private void doAfter() { //要处理的数据为空直接返回 if (Empty.isEmpty(products)) { return; } int batchSize = 520; //将大集合拆分为多个小集合分批次处理 List> lists = CollectionUtils.split(products,batchSize); //循环处理数据 lists.forEach(products->{ //转换为商品名列表 List productNames = products.stream().map(Product::getProductName).collect(Collectors.toList()); //联表查询 IO List skus = skuService.list(productNames); skus.forEach(skus->{ //封装实体添加到导出列表 }); }); } ``` 小菜优化完代码后，再用arthas监听一遍，发现这次只需要3s，速度提升近23倍 ![0dadfdaf5e5b37810bf2266d03a2250.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8672cd7bf5aa46e58fa5347c9a37cb36~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=1112&h=89&s=35789&e=png&b=022457) ### 最后接口优化的方式有很多种，在优化前我们需要进行分析哪里需要优化在平时的开发中，也要多考虑时间、空间复杂度，并不是什么场景下都要去避免关联多张表查询循环查数据库会造成多次网络IO，等待时间会很久，需要降低网络IO的次数，这种场景就可以联表查询如果担心查的数据太多，联表查询性能慢，可以考虑分析执行计划增加索引，又或者分批次进行处理其他接口优化的方式还有很多种，比如数据库优化、缓存、异步.... 缓存，可以使用本地缓存、分布式缓存、多级缓存，但引入缓存又会带来一致性问题，要分析业务场景使用适合使用缓存异步，可以使用MQ去做异步，也可以使用多线程去做异步，各有各的特点在一些业务场景中，不要为了使用某项技术而去使用技术是用来服务业务的，使用技术前要考虑到当前项目采用该技术是否合适，就像找伴侣一样，强扭的瓜不甜有什么问题可以在评论区交流，如果觉得菜菜写的不错，可以点赞、关注、收藏支持一下~ 关注菜菜，分享更多干货，公众号：菜菜的后端私房菜 ### 彩蛋小菜装作忧愁的来到项目经理旁边小菜：经理，这个接口对应的实现有些复杂，我估计下周忙完手上的事情就可以优化，你先帮我提个需求吧项目经理：ok没问题，下周忙完就尽快优化吧 #### 求关注~ 😁我是菜菜，热爱技术交流、分享与写作，喜欢图文并茂、通俗易懂的输出知识 📚在我的博客中，你可以找到Java技术栈的各个专栏：Java并发编程与JVM原理、Spring和MyBatis等常用框架及Tomcat服务器的源码解析，以及MySQL、Redis数据库的进阶知识，同时还提供关于消息中间件和Netty等主题的系列文章，都以通俗易懂的方式探讨这些复杂的技术点 🏆除此之外，我还是掘金优秀创作者、腾讯云年度影响力作者、华为云年度十佳博主.... 👫我对技术交流、知识分享以及写作充满热情，如果你愿意，欢迎加我一起交流（vx:CaiCaiJava666），也可以持续关注我的公众号：菜菜的后端私房菜，我会分享更多技术干货，期待与更多志同道合的朋友携手并进，一同在这条充满挑战与惊喜的技术之旅中不断前行 🤝如果觉得菜菜写的不错，可以点赞、关注、收藏支持一下~