写代码五行属于什么,从自己的角度提升代码质量
认证作者
当时一想，500/s吞吐量还不简单。tomcat按照100个线程，那就是单线程1S内处理5个请求，200ms处理一个请求即可。这个没有问题，平时接口响应时间大部分都100ms左右，还不是分分钟满足的事情。
然而压测一开，100 的并发，吞吐量居然只有 50 ...
而且再一查，100
公司的一个ToB系统，因为客户使用的也不多，没啥并发要求，就一直没有经过压测。这两天来了一个“大客户”，对并发量提出了要求：核心接口与几个重点使用场景单节点吞吐量要满足最低500/s的要求。
当时一想，500/s吞吐量还不简单。tomcat按照100个线程，那就是单线程1S内处理5个请求，200ms处理一个请求即可。这个没有问题，平时接口响应时间大部分都100ms左右，还不是分分钟满足的事情。
然而压测一开，100 的并发，吞吐量居然只有 50 ...
而且再一查，100的并发，CPU使用率居然接近 80% ...
从上图可以看到几个重要的信息。
最小值： 表示我们非并发场景单次接口响应时长。还不足100ms。挺好!
最大值： 并发场景下，由于各种锁或者其他串行操作，导致部分请求等待时长增加，接口整体响应时间变长。5秒钟。有点过分了！！！
再一看百分位，大部分的请求响应时间都在4s。无语了！！！
所以 1s钟的 吞吐量 单节点只有 50 。距离 500 差了10倍。 难受！！！！
分析过程定位“慢”原因这里暂时先忽略 CPU 占用率高的问题
首先平均响应时间这么慢，肯定是有阻塞。先确定阻塞位置。重点检查几处：
锁 (同步锁、分布式锁、数据库锁)耗时操作 (链接耗时、SQL耗时)结合这些先配置耗时埋点。
接口响应时长统计。超过500ms打印告警日志。接口内部远程调用耗时统计。200ms打印告警日志。redis访问耗时。超过10ms打印告警日志。SQL执行耗时。超过100ms打印告警日志。上述配置生效后，通过日志排查到接口存在慢SQL。具体SQL类似与这种：
update table set field = field - 1 where type = 1 and filed > 1;复制代码上述SQL相当于并发操作同一条数据，肯定存在锁等待。日志显示此处的等待耗时占接口总耗时 80% 以上。
二话不说先改为敬。因为是压测环境，直接先改为异步执行，确认一下效果。实际解决方案，感兴趣的可以参考另外一篇文章：大量请求同时修改数据库表一条记录时应该如何设计
PS：当时心里是这么想的： 妥了，大功告成。就是这里的问题！绝壁是这个原因！优化一下就解决了。当然，如果这么简单就没有必要写这篇文章了...
优化后的效果：
嗯...
emm...
好！ 这个优化还是很明显的，提升提升了近2倍。
此时已经感觉到有些不对了，慢SQL已经解决了（异步了~ 随便吧~ 你执行 10s我也不管了），虽然对吞吐量的提升没有预期的效果。但是数据是不会骗人的。
最大值： 已经从 5s -> 2s
百分位值： 4s -> 1s
这已经是很大的提升了。
继续定位“慢”的原因通过第一阶段的“优化”，我们距离目标近了很多。废话不多说，继续下一步的排查。
我们继续看日志，此时日志出现类似下边这种情况：
2023-01-04 15:17:05:347 INFO **.**.**.***.50 [TID: 1s22s72s8ws9w00] **********************2023-01-04 15:17:05:348 INFO **.**.**.***.21 [TID: 1s22s72s8ws9w00] **********************2023-01-04 15:17:05:350 INFO **.**.**.***.47 [TID: 1s22s72s8ws9w00] **********************2023-01-04 15:17:05:465 INFO **.**.**.***.234 [TID: 1s22s72s8ws9w00] **********************2023-01-04 15:17:05:467 INFO **.**.**.***.123 [TID: 1s22s72s8ws9w00] **********************2023-01-04 15:17:05:581 INFO **.**.**.***.451 [TID: 1s22s72s8ws9w00] **********************2023-01-04 15:17:05:702 INFO **.**.**.***.72 [TID: 1s22s72s8ws9w00] **********************复制代码前三行info日志没有问题，间隔很小。第4 ~ 第5，第6 ~ 第7，第7 ~ 第8 很明显有百毫秒的耗时。检查代码发现，这部分没有任何耗时操作。那么这段时间干什么了呢？
发生了线程切换，换其他线程执行其他任务了。(线程太多了)日志打印太多了，压测5分钟日志量500M。（记得日志打印太多是有很大影响的）STW。（但是日志还在输出，所以前两种可能性很高，而且一般不会停顿百毫秒）按照这三个思路做了以下操作：
首先，提升日志打印级别到DEBUG。emm... 提升不大，好像增加了10左右。
然后，拆线程 @Async 注解使用线程池，控制代码线程池数量（之前存在3个线程池，统一配置的核心线程数为100）结合业务，服务总核心线程数控制在50以内，同步增加阻塞最大大小。结果还可以，提升了50，接近200了。
最后，观察JVM的GC日志，发现YGC频次4/s，没有FGC。1分钟内GC时间不到1s，很明显不是GC问题，不过发现JVM内存太小只有512M，直接给了4G。吞吐量没啥提升，YGC频次降低为2秒1次。
唉，一顿操作猛如虎。
PS：其实中间还对数据库参数一通瞎搞，这里不多说了。
其实也不是没有收获，至少在减少服务线程数量后还是有一定收获的。另外，已经关注到了另外一个点：CPU使用率，减少了线程数量后，CPU的使用率并没有明显的下降，这里是很有问题的，当时认为CPU的使用率主要与开启的线程数量有关，之前线程多，CPU使用率较高可以理解。但是，在砍掉了一大半的线程后，依然居高不下这就很奇怪了。
此时关注的重点开始从代码“慢”方向转移到“CPU高”方向。
定位CPU使用率高的原因CPU的使用率高，通常与线程数相关肯定是没有问题的。当时对居高不下的原因考虑可能有以下两点：
有额外的线程存在。代码有部分CPU密集操作。然后继续一顿操作：
观察服务活跃线程数。观察有无CPU占用率较高线程。在观察过程中发现，没有明显CPU占用较高线程。所有线程基本都在10%以内。类似于下图，不过有很多线程。
没有很高就证明大家都很正常，只是多而已...
此时没有下一步的排查思路了。当时想着,算了打印一下堆栈看看吧，看看到底干了啥~
在看的过程中发现这段日志：
"http-nio-6071-exec-9" #82 daemon prio=5 os_prio=0 tid=0x00007fea9aed1000 nid=0x62 runnable [0x00007fe934cf4000] java.lang.Thread.State: RUNNABLEat org.springframework.core.annotation.AnnotationUtils.getValue(AnnotationUtils.java:1058)at org.springframework.aop.aspectj.annotation.AbstractAspectJAdvisorFactory$AspectJAnnotation.resolveExpression(AbstractAspectJAdvisorFactory.java:216)at org.Springframework.aop.aspectj.annotation.AbstractAspectJAdvisorFactory$AspectJAnnotation.(AbstractAspectJAdvisorFactory.java:197)at org.springframework.aop.aspectj.annotation.AbstractAspectJAdvisorFactory.findAnnotation(AbstractAspectJAdvisorFactory.java:147)at org.springframework.aop.aspectj.annotation.AbstractAspectJAdvisorFactory.findAspectJAnnotationOnMethod(AbstractAspectJAdvisorFactory.java:135)at org.springframework.aop.aspectj.annotation.ReflectiveAspectJAdvisorFactory.getAdvice(ReflectiveAspectJAdvisorFactory.java:244)at org.springframework.aop.aspectj.annotation.InstantiationModelAwarePointcutAdvisorImpl.instantiateAdvice(InstantiationModelAwarePointcutAdvisorImpl.java:149)at org.springframework.aop.aspectj.annotation.InstantiationModelAwarePointcutAdvisorImpl.(InstantiationModelAwarePointcutAdvisorImpl.java:113)at org.springframework.aop.aspectj.annotation.ReflectiveAspectJAdvisorFactory.getAdvisor(ReflectiveAspectJAdvisorFactory.java:213)at org.springframework.aop.aspectj.annotation.ReflectiveAspectJAdvisorFactory.getAdvisors(ReflectiveAspectJAdvisorFactory.java:144)at org.springframework.aop.aspectj.annotation.BeanFactoryAspectJAdvisorsBuilder.buildAspectJAdvisors(BeanFactoryAspectJAdvisorsBuilder.java:149)at org.springframework.aop.aspectj.annotation.AnnotationAwareAspectJAutoProxyCreator.findCandidateAdvisors(AnnotationAwareAspectJAutoProxyCreator.java:95)at org.springframework.aop.aspectj.autoproxy.AspectJAwareAdvisorAutoProxyCreator.shouldSkip(AspectJAwareAdvisorAutoProxyCreator.java:101)at org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.wrapIfNecessary(AbstractAutoProxyCreator.java:333)at org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.postProcessAfterInitialization(AbstractAutoProxyCreator.java:291)at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsAfterInitialization(AbstractAutowireCapableBeanFactory.java:455)at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1808)at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:620)at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:542)at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:353)at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:233)at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveNamedBean(DefaultListableBeanFactory.java:1282)at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveNamedBean(DefaultListableBeanFactory.java:1243)at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveBean(DefaultListableBeanFactory.java:494)at org.springframework.Beans.factory.support.DefaultListableBeanFactory.getBean(DefaultListableBeanFactory.java:349)at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBean(DefaultListableBeanFactory.java:342)at cn.hutool.extra.spring.SpringUtil.getBean(SpringUtil.java:117) ...... ......上边的堆栈发现了一个点： 在执行getBean的时候，执行了createBean方法。我们都知道Spring托管的Bean都是提前实例化好放在IOC容器中的。createBean要做的事情有很多，比如Bean的初始化，依赖注入其他类，而且中间还有一些前后置处理器执行、代理检查等等，总之是一个耗时方法，所以都是在程序启动时去扫描，加载，完成Bean的初始化。
而我们在运行程序线程堆栈中发现了这个操作。而且通过检索发现竟然有近200处。
通过堆栈信息很快定位到执行位置：
RedisTool redisTool = BeanUtils.getBean(RedisMaster.class);复制代码而RedisMaster类
@Component@Scope("prototype")public class RedisMaster implements IRedisTool { // ......}复制代码没错就是用了多例。而且使用的地方是Redis（系统使用Jedis客户端，Jedis并非线程安全，每次使用都需要新的实例），接口对Redis的使用还是比较频繁的，一个接口得有10次左右获取Redis数据。也就是说执行10次左右的createBean逻辑 ...
叹气！！！
赶紧改代码，直接使用万能的 new 。
在看结果之前还有一点需要提一下，由于系统有大量统计耗时的操作。实现方式是通过：
long start = System.currentTimeMillis();// ......long end = System.currentTimeMillis();long runTime = start - end;复制代码或者Hutool提供的StopWatch：
这里感谢一下huoger 同学的评论，当时还误以为该方式能够降低性能的影响，但是实际上也只是一层封装。底层使用的是 System.nanoTime()。
StopWatch watch = new StopWatch();watch.start();// ......watch.stop();System.out.println(watch.getTotalTimeMillis());复制代码而这种在并发量高的情况下，对性能影响还是比较大的，特别在服务器使用了一些特定时钟的情况下。这里就不多说，感兴趣的可以自行搜索一下。
最终结果：
排查涉及的命令如下：
查询服务进程CPU情况： top –Hp pid
查询JVM GC相关参数：jstat -gc pid 2000 (对 pid [进程号] 每隔 2s 输出一次日志)
打印当前堆栈信息： jstack -l pid >> stack.log
总结结果是好的，过程是曲折的。总的来说还是知识的欠缺，文章看起来还算顺畅，但都是事后诸葛亮，不对，应该是事后臭皮匠。基本都是边查资料边分析边操作，前后花费了4天时间，尝试了很多。
Mysql : Buffer Pool 、Change Buffer 、Redo Log 大小、双一配置...代码 : 异步执行，线程池参数调整，tomcat 配置，Druid连接池配置...JVM : 内存大小，分配，垃圾收集器都想换...总归一通瞎搞，能想到的都试试。
后续还需要多了解一些性能优化知识，至少要做到排查思路清晰，不瞎搞。
最后5行代码有哪些：
new Redis实例：1耗时统计：3SQL异步执行 @Async： 1（上图最终的结果是包含该部分的，时间原因未对SQL进行处理，后续会考虑Redis原子操作 定时同步数据库方式来进行，避免同时操数据库）TODO问题虽然解决了。但是原理还不清楚，需要继续深挖。
为什么createBean对性能影响这么大？
如果影响这么大，Spring为什么还要有多例？
首先非并发场景速度还是很快的。这个毋庸置疑。毕竟接口响应时间不足50ms。
所以问题一定出在，并发createBean同一对象的锁等待场景。根据堆栈日志，翻了一下Spring源码，果然发现这里出现了同步锁。相信锁肯定不止一处。
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#doCreateBean
System.currentTimeMillis并发度多少才会对性能产生影响，影响有多大？
很多公司（包括大厂）在业务代码中，还是会频繁的使用System.currentTimeMillis获取时间戳。比如：时间字段赋值场景。所以，性能影响肯定会有，但是影响的门槛是不是很高。
继续学习性能优化知识
吞吐量与什么有关？首先，接口响应时长。直接影响因素还是接口响应时长，响应时间越短，吞吐量越高。一个接口响应时间100ms,那么1s就能处理10次。
其次，线程数。现在都是多线程环境，如果同时10个线程处理请求，那么吞吐量又能增加10倍。当然由于CPU资源有限，所以线程数也会受限。理论上，在 CPU 资源利用率较低的场景，调大tomcat线程数，以及并发数，能够有效的提升吞吐量。
最后，高性能代码。无论接口响应时长，还是 CPU 资源利用率，都依赖于我们的代码，要做高性能的方案设计，以及高性能的代码实现，任重而道远。
CPU使用率的高低与哪些因素有关？CPU使用率的高低，本质还是由线程数，以及CPU使用时间决定的。
假如一台10核的机器，运行一个单线程的应用程序。正常这个单线程的应用程序会交给一个CPU核心去运行，此时占用率就是10%。而现在应用程序都是多线程的，因此一个应用程序可能需要全部的CPU核心来执行，此时就会达到100%。
此外，以单线程应用程序为例，大部分情况下，我们还涉及到访问Redis/Mysql、RPC请求等一些阻塞等待操作，那么CPU就不是时刻在工作的。所以阻塞等待的时间越长，CPU利用率也会越低。也正是因为如此，为了充分的利用CPU资源，多线程也就应运而生（一个线程虽然阻塞了，但是CPU别闲着，赶紧去运行其他的线程）。
一个服务线程数在多少比较合适（算上Tomcat，最终的线程数量是226），执行过程中发现即使tomcat线程数量是100，活跃线程数也很少超过50，整个压测过程基本维持在20左右。附接口优化的一些通用方案
1. 批量思想：批量操作数据库
优化前：
//for循环单笔入库for(TransDetail detail:transDetailList){ insert(detail); }优化后：
batchInsert(transDetailList);打个比喻：
打个比喻:假如你需要搬一万块砖到楼顶,你有一个电梯,电梯一次可以放适量的砖（最多放500）, 你可以选择一次运送一块砖,也可以一次运送500,你觉得哪种方式更方便，时间消耗更少?
2. 异步思想：耗时操作，考虑放到异步执行耗时操作，考虑用异步处理，这样可以降低接口耗时。
假设一个转账接口，匹配联行号，是同步执行的，但是它的操作耗时有点长，优化前的流程：
为了降低接口耗时，更快返回，你可以把匹配联行号移到异步处理，优化后：
除了转账这个例子，日常工作中还有很多这种例子。比如：用户注册成功后，短信邮件通知，也是可以异步处理的~至于异步的实现方式，你可以用线程池，也可以用消息队列实现。3. 空间换时间思想：恰当使用缓存。
在适当的业务场景，恰当地使用缓存，是可以大大提高接口性能的。缓存其实就是一种空间换时间的思想，就是你把要查的数据，提前放好到缓存里面，需要时，直接查缓存，而避免去查数据库或者计算的过程。
这里的缓存包括：Redis缓存，JVM本地缓存，memcached，或者Map等等。我举个我工作中，一次使用缓存优化的设计吧，比较简单，但是思路很有借鉴的意义。
那是一次转账接口的优化，老代码，每次转账，都会根据客户账号，查询数据库，计算匹配联行号。
因为每次都查数据库，都计算匹配，比较耗时，所以使用缓存，优化后流程如下：
4. 预取思想：提前初始化到缓存
预取思想很容易理解，就是提前把要计算查询的数据，初始化到缓存。如果你在未来某个时间需要用到某个经过复杂计算的数据，才实时去计算的话，可能耗时比较大。这时候，我们可以采取预取思想，提前把将来可能需要的数据计算好，放到缓存中，等需要的时候，去缓存取就行。这将大幅度提高接口性能。
我记得以前在第一个公司做视频直播的时候，看到我们的直播列表就是用到这种优化方案。就是启动个任务，提前把直播用户、积分等相关信息，初始化到缓存。
5. 池化思想：预分配与循环使用大家应该都记得，我们为什么需要使用线程池？
线程池可以帮我们管理线程，避免增加创建线程和销毁线程的资源损耗。
如果你每次需要用到线程，都去创建，就会有增加一定的耗时，而线程池可以重复利用线程，避免不必要的耗时。 池化技术不仅仅指线程池，很多场景都有池化思想的体现，它的本质就是预分配与循环使用。
比如TCP三次握手，大家都很熟悉吧，它为了减少性能损耗，引入了Keep-Alive长连接，避免频繁的创建和销毁连接。当然，类似的例子还有很多，如数据库连接池、HttpClient连接池。
我们写代码的过程中，学会池化思想，最直接相关的就是使用线程池而不是去new一个线程。
6. 事件回调思想：拒绝阻塞等待。如果你调用一个系统B的接口，但是它处理业务逻辑，耗时需要10s甚至更多。然后你是一直阻塞等待，直到系统B的下游接口返回，再继续你的下一步操作吗？这样显然不合理。
我们参考IO多路复用模型。即我们不用阻塞等待系统B的接口，而是先去做别的操作。等系统B的接口处理完，通过事件回调通知，我们接口收到通知再进行对应的业务操作即可。
如果大家忘记了IO模型，可以复习一下我的文章：看一遍就理解：IO模型详解
7. 远程调用由串行改为并行假设我们设计一个APP首页的接口，它需要查用户信息、需要查banner信息、需要查弹窗信息等等。如果是串行一个一个查，比如查用户信息200ms，查banner信息100ms、查弹窗信息50ms，那一共就耗时350ms了，如果还查其他信息，那耗时就更大了。
其实我们可以改为并行调用，即查用户信息、查banner信息、查弹窗信息，可以同时并行发起。
最后接口耗时将大大降低。有些小伙伴说，不知道如何使用并行优化接口?
我之前写过一篇文章并行优化接口的文章，保姆级别的！大家可以看一下，看完会有用的：后端思维篇，手把手教你写一个并行调用模板
8. 锁粒度避免过粗在高并发场景，为了防止超卖等情况，我们经常需要加锁来保护共享资源。但是，如果加锁的粒度过粗，是很影响接口性能的。
什么是加锁粒度呢？
其实就是就是你要锁住的范围是多大。比如你在家上卫生间，你只要锁住卫生间就可以了吧，不需要将整个家都锁起来不让家人进门吧，卫生间就是你的加锁粒度。
不管你是synchronized加锁还是redis分布式锁，只需要在共享临界资源加锁即可，不涉及共享资源的，就不必要加锁。这就好像你上卫生间，不用把整个家都锁住，锁住卫生间门就可以了。
比如，在业务代码中，有一个ArrayList因为涉及到多线程操作，所以需要加锁操作，假设刚好又有一段比较耗时的操作（代码中的slowNotShare方法）不涉及线程安全问题。反例加锁，就是一锅端，全锁住:
//不涉及共享资源的慢方法private void slowNotShare() { try { TimeUnit.MILLISECONDS.sleep(100); } catch (InterruptedException e) { }}//错误的加锁方法public int wrong() { long beginTime = System.currentTimeMillis(); IntStream.rangeClosed(1, 10000).parallel().forEach(i -> { //加锁粒度太粗了，slowNotShare其实不涉及共享资源 synchronized (this) { slowNotShare(); data.add(i); } }); log.info("cosume time:{}", System.currentTimeMillis() - beginTime); return data.size();}复制代码正例：
public int right() { long beginTime = System.currentTimeMillis(); IntStream.rangeClosed(1, 10000).parallel().forEach(i -> { slowNotShare();//可以不加锁 //只对List这部分加锁 synchronized (data) { data.add(i); } }); log.info("cosume time:{}", System.currentTimeMillis() - beginTime); return data.size();}复制代码9. 切换存储方式：文件中转暂存数据如果数据太大，落地数据库实在是慢的话，就可以考虑先用文件的方式暂存。先保存文件，再异步下载文件，慢慢保存到数据库。
这里可能会有点抽象，给大家分享一个，我之前的一个真实的优化案例吧。
之前开发了一个转账接口。如果是并发开启，10个并发度，每个批次1000笔转账明细数据，数据库插入会特别耗时，大概6秒左右；这个跟我们公司的数据库同步机制有关，并发情况下，因为优先保证同步，所以并行的插入变成串行啦，就很耗时。
优化前，1000笔明细转账数据，先落地DB数据库，返回处理中给用户，再异步转账。如图：
记得当时压测的时候，高并发情况，这1000笔明细入库，耗时都比较大。所以我转换了一下思路，把批量的明细转账记录保存的文件服务器，然后记录一笔转账总记录到数据库即可。接着异步再把明细下载下来，进行转账和明细入库。最后优化后，性能提升了十几倍。
优化后，流程图如下：
如果你的接口耗时瓶颈就在数据库插入操作这里，用来批量操作等，还是效果还不理想，就可以考虑用文件或者MQ等暂存。有时候批量数据放到文件，会比插入数据库效率更高。
10. 索引提到接口优化，很多小伙伴都会想到添加索引。没错，添加索引是成本最小的优化，而且一般优化效果都很不错。
索引优化这块的话，一般从这几个维度去思考：
你的SQL加索引了没？你的索引是否真的生效？你的索引建立是否合理？10.1 SQL没加索引我们开发的时候，容易疏忽而忘记给SQL添加索引。所以我们在写完SQL的时候，就顺手查看一下 explain执行计划。
explain select * from user_info where userId like '3';复制代码你也可以通过命令show create table ，整张表的索引情况。
show create table user_info;复制代码如果某个表忘记添加某个索引，可以通过alter table add index命令添加索引
alter table user_info add index idx_name (name);复制代码一般就是：SQL的where条件的字段，或者是order by 、group by后面的字段需需要添加索引。
10.2 索引不生效有时候，即使你添加了索引，但是索引会失效的。田螺哥整理了索引失效的常见原因：
10.3 索引设计不合理
我们的索引不是越多越好，需要合理设计。比如：
删除冗余和重复索引。索引一般不能超过5个索引不适合建在有大量重复数据的字段上、如性别字段适当使用覆盖索引如果需要使用force index强制走某个索引，那就需要思考你的索引设计是否真的合理了11. 优化SQL处了索引优化，其实SQL还有很多其他有优化的空间。比如这些：
更详细的内容，大家可以看我之前的这两篇文章哈：
盘点MySQL慢查询的12个原因后端程序员必备：书写高质量SQL的30条建议12.避免大事务问题为了保证数据库数据的一致性，在涉及到多个数据库修改操作时，我们经常需要用到事务。而使用spring声明式事务，又非常简单，只需要用一个注解就行@Transactional，如下面的例子：
@Transactionalpublic int createUser(User user){ //保存用户信息 userDao.save(user); passCertDao.updateFlag(user.getPassId()); return user.getUserId();}复制代码这块代码主要逻辑就是创建个用户，然后更新一个通行证pass的标记。如果现在新增一个需求，创建完用户，调用远程接口发送一个email消息通知，很多小伙伴会这么写：
@Transactionalpublic int createUser(User user){ //保存用户信息 userDao.save(user); passCertDao.updateFlag(user.getPassId()); sendEmailRpc(user.getEmail()); return user.getUserId();}复制代码这样实现可能会有坑，事务中嵌套RPC远程调用，即事务嵌套了一些非DB操作。如果这些非DB操作耗时比较大的话，可能会出现大事务问题。
所谓大事务问题就是，就是运行时间长的事务。由于事务一致不提交，就会导致数据库连接被占用，即并发场景下，数据库连接池被占满，影响到别的请求访问数据库，影响别的接口性能。
大事务引发的问题主要有：接口超时、死锁、主从延迟等等。因此，为了优化接口，我们要规避大事务问题。我们可以通过这些方案来规避大事务：
RPC远程调用不要放到事务里面一些查询相关的操作，尽量放到事务之外事务中避免处理太多数据13. 深分页问题在以前公司分析过几个接口耗时长的问题，最终结论都是因为深分页问题。
深分页问题，为什么会慢？我们看下这个SQL
select id,name,balance from account where create_time> '2020-09-19' limit 100000,10;复制代码limit 100000,10意味着会扫描100010行，丢弃掉前100000行，最后返回10行。即使create_time，也会回表很多次。
我们可以通过标签记录法和延迟关联法来优化深分页问题。
13.1 标签记录法就是标记一下上次查询到哪一条了，下次再来查的时候，从该条开始往下扫描。就好像看书一样，上次看到哪里了，你就折叠一下或者夹个书签，下次来看的时候，直接就翻到啦。
假设上一次记录到100000，则SQL可以修改为：
select id,name,balance FROM account where id > 100000 limit 10;复制代码这样的话，后面无论翻多少页，性能都会不错的，因为命中了id主键索引。但是这种方式有局限性：需要一种类似连续自增的字段。
13.2 延迟关联法延迟关联法，就是把条件转移到主键索引树，然后减少回表。优化后的SQL如下：
select acct1.id,acct1.name,acct1.balance FROM account acct1 INNER JOIN (SELECT a.id FROM account a WHERE a.create_time > '2020-09-19' limit 100000, 10) AS acct2 on acct1.id= acct2.id;复制代码优化思路就是，先通过idx_create_time二级索引树查询到满足条件的主键ID，再与原表通过主键ID内连接，这样后面直接走了主键索引了，同时也减少了回表。
14. 优化程序结构优化程序逻辑、程序代码，是可以节省耗时的。比如，你的程序创建多不必要的对象、或者程序逻辑混乱，多次重复查数据库、又或者你的实现逻辑算法不是最高效的，等等。
我举个简单的例子：复杂的逻辑条件，有时候调整一下顺序，就能让你的程序更加高效。
假设业务需求是这样：如果用户是会员，第一次登陆时，需要发一条感谢短信。如果没有经过思考，代码直接这样写了
if(isUserVip && isFirstLogin){ sendSmsMsg();}复制代码假设有5个请求过来，isUserVip判断通过的有3个请求，isFirstLogin通过的只有1个请求。 那么以上代码，isUserVip执行的次数为5次，isFirstLogin执行的次数也是3次，如下：
如果调整一下isUserVip和isFirstLogin的顺序：
if(isFirstLogin && isUserVip ){ sendMsg();}复制代码isFirstLogin执行的次数是5次，isUserVip执行的次数是1次：
酱紫程序是不是变得更高效了呢？
15. 压缩传输内容压缩传输内容，传输报文变得更小，因此传输会更快啦。10M带宽，传输10k的报文，一般比传输1M的会快呀。
打个比喻，一匹千里马，它驮着100斤的货跑得快，还是驮着10斤的货物跑得快呢？
再举个视频网站的例子：
如果不对视频做任何压缩编码，因为带宽又是有限的。巨大的数据量在网络传输的耗时会比编码压缩后，慢好多倍。
16. 海量数据处理，考虑NoSQL之前看过几个慢SQL，都是跟深分页问题有关的。发现用来标签记录法和延迟关联法，效果不是很明显，原因是要统计和模糊搜索，并且统计的数据是真的大。最后跟组长对齐方案，就把数据同步到Elasticsearch，然后这些模糊搜索需求，都走Elasticsearch去查询了。
我想表达的就是，如果数据量过大，一定要用关系型数据库存储的话，就可以分库分表。但是有时候，我们也可以使用NoSQL，如Elasticsearch、Hbase等。
17. 线程池设计要合理我们使用线程池，就是让任务并行处理，更高效地完成任务。但是有时候，如果线程池设计不合理，接口执行效率则不太理想。
一般我们需要关注线程池的这几个参数：核心线程、最大线程数量、阻塞队列。
如果核心线程过小，则达不到很好的并行效果。如果阻塞队列不合理，不仅仅是阻塞的问题，甚至可能会OOM如果线程池不区分业务隔离，有可能核心业务被边缘业务拖垮。大家可以看下我之前两篇有关于线程池的文章：
细数线程池的10个坑面试必备：Java线程池解析18.机器问题 （fullGC、线程打满、太多IO资源没关闭等等）。有时候，我们的接口慢，就是机器处理问题。主要有fullGC、线程打满、太多IO资源没关闭等等。
之前排查过一个fullGC问题： 运营小姐姐导出60多万的excel的时候，说卡死了，接着我们就收到监控告警。后面排查得出，我们老代码是Apache POI生成的excel，导出excel数据量很大时，当时JVM内存吃紧会直接Full GC了。如果线程打满了，也会导致接口都在等待了。所以。如果是高并发场景，我们需要接入限流，把多余的请求拒绝掉。如果IO资源没关闭，也会导致耗时增加。这个大家可以看下，平时你的电脑一直打开很多很多文件，是不是会觉得很卡。
文章评论