后端接口性能优化分析-多线程优化（上）:https://developer.aliyun.com/article/1413668
3.多线程思想：
串行改并行
假设我们设计一个APP首页的接口，它需要查用户信息、需要查banner信息、需要查弹窗信息等等。如果是串行一个一个查，比如查用户信息200ms，查banner信息100ms、查弹窗信息50ms，那一共就耗时350ms了，如果还查其他信息，那耗时就更大了。
其实我们可以改为并行调用，即查用户信息、查banner信息、查弹窗信息，可以同时并行发起。
最后接口耗时将大大降低。
public UserInfo getUserInfo(Long id) throws InterruptedException, ExecutionException { final UserInfo userInfo = new UserInfo(); CompletableFuture userFuture = CompletableFuture.supplyAsync(() -> { getRemoteUserAndFill(id, userInfo); return Boolean.TRUE; }, executor); CompletableFuture bonusFuture = CompletableFuture.supplyAsync(() -> { getRemoteBonusAndFill(id, userInfo); return Boolean.TRUE; }, executor); CompletableFuture growthFuture = CompletableFuture.supplyAsync(() -> { getRemoteGrowthAndFill(id, userInfo); return Boolean.TRUE; }, executor); CompletableFuture.allOf(userFuture, bonusFuture, growthFuture).join(); userFuture.get(); bonusFuture.get(); growthFuture.get(); return userInfo; }
以阿里云开发社区举例：
应急定位场景下，A系统调用B系统获取诊断结论，TR超时时间是500ms，对于一个异常ID事件，需要执行多个诊断项服务，并记录诊断流水；每个诊断的耗时大概在100ms以内，随着业务的增长，超过5个诊断项，计算耗时累加到500ms+，这时候服务会出现高峰期短暂不可用。
将这段代码改成异步执行，这样执行诊断的时间是耗时最大的诊断服务
// 提交future任务并发执行 futures = executor.invokeAll(tasks, timeout, timeUnit); // 遍历读取结果 for (Future<Res> future : futures) { try { // 获取结果 Res singleResult = future.get(); if (singleResult != null) { result.add(singleResult); } } catch (Exception e) { LogUtil.error(e, logger, "并发执行发生异常!,poolName={0}.", threadPoolName); } }
通过上面的两个场景举例，可以看出，实际上针对一些耗时较长的任务运行，适当地利用，可以达到加速的效果。但是凡事都是双刃剑，有利有弊。
线上对响应时间要求较高的场合，尽量少用多线程，尤其是服务线程需要等待任务线程的场合（很多重大事故就是和这个息息相关），如果一定要用，可以对服务线程设置一个最大等待时间。
这句话的核心是在线上高响应时间的场景下，需要谨慎使用多线程，特别是当服务线程需要等待任务线程时。因为在多线程环境中，线程间的调度和同步可能会引入额外的等待时间，这可能导致响应时间增加，影响系统的性能。
举个例子来说，假设我们有一个在线服务，它需要处理大量的用户请求。每个用户请求都会被分配到一个服务线程去处理。为了提高处理速度，每个服务线程可能会启动多个任务线程去并行执行一些计算密集型的任务。这种情况下，服务线程就需要等待所有的任务线程完成才能继续执行。
然而，由于操作系统的线程调度策略，任务线程可能并不会立即执行。此外，如果任务线程的数量超过了CPU的核心数，那么这些线程就需要在CPU核心之间进行切换，这也会引入额外的等待时间。这些都可能导致服务线程需要花费更多的时间等待任务线程，从而导致响应时间增加。
因此，这句话的建议是，在这种场景下，最好尽量少用多线程，或者至少要对服务线程设置一个最大等待时间，以防止服务线程无限期地等待任务线程。这样可以避免因为线程同步和调度问题导致的性能下降，保证在线服务的响应时间。
当然，这并不是说多线程就一定会导致性能下降。如果使用得当，多线程还是可以大大提高系统的性能的。但是在高响应时间的场景下，我们需要更加谨慎地使用多线程，以防止潜在的性能问题。
常见做法
如果单机的处理能力可以满足实际业务的需求，那么尽可能地使用单机多线程的处理方式，减少复杂性；反之，则需要使用多机多线程的方式。
单机多线程
对于单机多线程，可以引入线程池的机制，作用有二：
1） 提高性能，节省线程创建和销毁的开销。
2） 限流，给线程池一个固定的容量，达到这个容量值后再有任务进来，就进入队列进行排队，保障机器极限压力下的稳定处理能力在使用JDK自带的线程池时，一定要仔细理解构造方法的各个参数的含义，如core pool size、max pool size、keepAliveTime、worker queue等，在理解的基础上通过不断地测试调整这些参数值达到最优效果。
多机多线程
如果单机的处理能力不能满足需求，这个时候需要使用多机多线程的方式。这个时候就需要一些分布式系统的知识了，可以选用一些开源成熟的分布式任务调度系统如xxl-job。
4.空间换时间思想：恰当使用缓存
在适当的业务场景，恰当地使用缓存，是可以大大提高接口性能的。缓存其实就是一种空间换时间的思想，就是你把要查的数据，提前放好到缓存里面，需要时，直接查缓存，而避免去查数据库或者计算的过程。
这里的缓存包括：Redis缓存，JVM本地缓存，memcached，或者Map等等。
一级缓存
以一段优化举例：
转账接口的优化，老代码，每次转账，都会根据客户账号，查询数据库，计算匹配联行号。
因为每次都查数据库，都计算匹配，比较耗时，所以使用缓存，优化后流程如下：
但不能为了缓存而缓存，还是要看具体的业务场景。毕竟加了缓存，会导致接口的复杂度增加，它会带来数据不一致问题。
在有些并发量比较低的场景中，比如用户下单，可以不用加缓存。
还有些场景，比如在商城首页显示商品分类的地方，假设这里的分类是调用接口获取到的数据，但页面暂时没有做静态化。
二级缓存
上面的方案其实是基于Redis实现的，虽说redis访问速度很快。但毕竟是一个远程调用，而且菜单树的数据很多，在网络传输的过程中，是有些耗时的。
有没有办法，不经过请求远程，就能直接获取到数据呢？
那就是使用 二级缓存，即基于内存的缓存。
该方案的性能更好，但有个缺点就是，如果数据更新了，不能及时刷新缓存。此外，如果有多台服务器节点，可能存在各个节点上数据不一样的情况。
由此可见，二级缓存给我们带来性能提升的同时，也带来了数据不一致的问题。使用二级缓存一定要结合实际的业务场景，并非所有的业务场景都适用。
设计关键
什么时候更新缓存？如何保障更新的可靠性和实时性？
更新缓存的策略，需要具体问题具体分析。基本的更新策略有两个：
1） 接收变更的消息，准实时更新。
2） 给每一个缓存数据设置5分钟的过期时间，过期后从DB加载再回设到DB。这个策略是对第一个策略的有力补充，解决了手动变更DB不发消息、接收消息更新程序临时出错等问题导致的第一个策略失效的问题。通过这种双保险机制，有效地保证了缓存数据的可靠性和实时性。
缓存是否会满，缓存满了怎么办？
对于一个缓存服务，理论上来说，随着缓存数据的日益增多，在容量有限的情况下，缓存肯定有一天会满的。如何应对？
1） 给缓存服务，选择合适的缓存逐出算法，比如最常见的LRU。
2） 针对当前设置的容量，设置适当的警戒值，比如10G的缓存，当缓存数据达到8G的时候，就开始发出报警，提前排查问题或者扩容。
3） 给一些没有必要长期保存的key，尽量设置过期时间。
缓存是否允许丢失？丢失了怎么办？
根据业务场景判断，是否允许丢失。如果不允许，就需要带持久化功能的缓存服务来支持，比如Redis。更细节的话，可以根据业务对丢失时间的容忍度，还可以选择更具体的持久化策略，比如Redis的RDB或者AOF。
缓存问题
缓存穿透
描述：缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。
解决方案：
1） 接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截。
2） 从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用），这样可以防止攻击用户反复用同一个id暴力攻击。
缓存击穿
描述：缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力。
解决方案：
1） 设置热点数据永远不过期。
2） 加互斥锁，业界比较常用的做法，是使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。类似下面的代码：
public String get(key) { String value = redis.get(key); if (value == null) { //代表缓存值过期 //设置3min的超时，防止del操作失败的时候，下次缓存过期一直不能load db if (redis.setnx(key_mutex, 1, 3 * 60) == 1) { //代表设置成功 value = db.get(key); redis.set(key, value, expire_secs); redis.del(key_mutex); } else { //这个时候代表同时候的其他线程已经load db并回设到缓存了，这时候重试获取缓存值即可 sleep(50); get(key); //重试 } } else { return value; } }
后端接口性能优化分析-多线程优化（下）:https://developer.aliyun.com/article/1413670
