后端接口性能优化分析-程序结构优化（中）:https://developer.aliyun.com/article/1413672
11.压缩传输内容
压缩传输内容，传输报文变得更小，因此传输会更快啦。10M带宽，传输10k的报文，一般比传输1M的会快呀。
打个比喻，一匹千里马，它驮着100斤的货跑得快，还是驮着10斤的货物跑得快呢？
再举个视频网站的例子：
如果不对视频做任何压缩编码，因为带宽又是有限的。巨大的数据量在网络传输的耗时会比编码压缩后，慢好多倍。
压缩文本数据可以有效地减少该数据所需的存储空间，从而提高数据库和缓存的空间利用率。然而，压缩和解压缩的过程会增加CPU的负载，因此需要仔细考虑是否有必要进行数据压缩。此外，还需要评估压缩后数据的效果，即压缩对数据的影响如何。
比如说使用GZIP压缩算法的cpu负载和耗时都是比较高的。使用压缩非但不能起到降低接口耗时的效果，可能导致接口耗时增加，要谨慎使用。除此之外，还有其他压缩算法在压缩时间和压缩率上有所权衡。可以选择适合的自己的压缩算法。
12.线程池设计
我们使用线程池，就是让任务并行处理，更高效地完成任务。但是有时候，如果线程池设计不合理，接口执行效率则不太理想。
一般我们需要关注线程池的这几个参数：核心线程、最大线程数量、阻塞队列。
- 如果核心线程过小，则达不到很好的并行效果。
- 如果阻塞队列不合理，不仅仅是阻塞的问题，甚至可能会
OOM - 如果线程池不区分业务隔离，有可能核心业务被边缘业务拖垮。
下面是线程池设计建议总结：
线程池默认使用无界队列，任务过多导致OOM
JDK开发者提供了线程池的实现类，我们基于Executors组件，就可以快速创建一个线程池。日常工作中，一些小伙伴为了开发效率，反手就用Executors新建个线程池。写出类似以下的代码：
public class NewFixedTest { public static void main(String[] args) { ExecutorService executor = Executors.newFixedThreadPool(10); for (int i = 0; i < Integer.MAX_VALUE; i++) { executor.execute(() -> { try { Thread.sleep(10000); } catch (InterruptedException e) { //do nothing } }); } } }
使用newFixedThreadPool创建的线程池，是会有坑的，它默认是无界的阻塞队列，如果任务过多，会导致OOM问题。运行一下以上代码，出现了OOM。
Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit exceeded at java.util.concurrent.LinkedBlockingQueue.offer(LinkedBlockingQueue.java:416) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1371) at com.example.dto.NewFixedTest.main(NewFixedTest.java:14)
这是因为newFixedThreadPool使用了无界的阻塞队列的LinkedBlockingQueue，如果线程获取一个任务后，任务的执行时间比较长(比如，上面demo代码设置了10秒)，会导致队列的任务越积越多，导致机器内存使用不停飙升， 最终出现OOM。
看下newFixedThreadPool的相关源码，是可以看到一个无界的阻塞队列的，如下：
//阻塞队列是LinkedBlockingQueue，并且是使用的是无参构造函数 public static ExecutorService newFixedThreadPool(int nThreads) { return new ThreadPoolExecutor(nThreads, nThreads, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<Runnable>()); } //无参构造函数，默认最大容量是Integer.MAX_VALUE，相当于无界的阻塞队列的了 public LinkedBlockingQueue() { this(Integer.MAX_VALUE); }
因此，工作中，建议大家自定义线程池，并使用指定长度的阻塞队列。
线程池创建线程过多，导致OOM
有些小伙伴说，既然Executors组件创建出的线程池newFixedThreadPool，使用的是无界队列，可能会导致OOM。那么，Executors组件还可以创建别的线程池，如newCachedThreadPool，我们用它也不行嘛？
我们可以看下newCachedThreadPool的构造函数：
public static ExecutorService newCachedThreadPool() { return new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60L, TimeUnit.SECONDS, new SynchronousQueue<Runnable>()); }
它的最大线程数是Integer.MAX_VALUE。大家应该意识到使用它，可能会引发什么问题了吧。没错，如果创建了大量的线程也有可能引发OOM！
所以我们使用线程池的时候，还要当心线程创建过多，导致OOM问题。大家尽量不要使用newCachedThreadPool，并且如果自定义线程池时，要注意一下最大线程数。
共享线程池，次要逻辑拖垮主要逻辑
要避免所有的业务逻辑共享一个线程池。比如你用线程池A来做登录异步通知，又用线程池A来做对账。如下图：
如果对账任务checkBillService响应时间过慢，会占据大量的线程池资源，可能直接导致没有足够的线程资源去执行loginNotifyService的任务，最后影响登录。就这样，因为一个次要服务，影响到重要的登录接口，显然这是绝对不允许的。因此，我们不能将所有的业务一锅炖，都共享一个线程池，因为这样做，风险太高了，犹如所有鸡蛋放到一个篮子里。应当做线程池隔离！
线程池拒绝策略的坑，使用不当导致阻塞
我们知道线程池主要有四种拒绝策略，如下：
- AbortPolicy: 丢弃任务并抛出RejectedExecutionException异常。(默认拒绝策略)
- DiscardPolicy：丢弃任务，但是不抛出异常。
- DiscardOldestPolicy：丢弃队列最前面的任务，然后重新尝试执行任务。
- CallerRunsPolicy：由调用方线程处理该任务。
如果线程池拒绝策略设置不合理，就容易有坑。我们把拒绝策略设置为DiscardPolicy或DiscardOldestPolicy并且在被拒绝的任务，Future对象调用get()方法,那么调用线程会一直被阻塞。
温馨提示，日常开发中，使用 Future.get() 时，尽量使用带超时时间的，因为它是阻塞的。
future.get(1, TimeUnit.SECONDS);
Spring内部线程池的坑
工作中，个别开发者，为了快速开发，喜欢直接用spring的@Async，来执行异步任务。
@Async public void testAsync() throws InterruptedException { System.out.println("处理异步任务"); TimeUnit.SECONDS.sleep(new Random().nextInt(100)); }
Spring内部线程池，其实是SimpleAsyncTaskExecutor，这玩意有点坑，它不会复用线程的，它的设计初衷就是执行大量的短时间的任务。
也就是说来了一个请求，就会新建一个线程！大家使用spring的@Async时，要避开这个坑，自己再定义一个线程池。正例如下：
@Bean(name = "threadPoolTaskExecutor") public Executor threadPoolTaskExecutor() { ThreadPoolTaskExecutor executor=new ThreadPoolTaskExecutor(); executor.setCorePoolSize(5); executor.setMaxPoolSize(10); executor.setThreadNamePrefix("tianluo-%d"); // 其他参数设置 return new ThreadPoolTaskExecutor(); }
使用线程池时，没有自定义命名
使用线程池时，如果没有给线程池一个有意义的名称，将不好排查回溯问题。这不算一个坑吧，只能说给以后排查埋坑
public class ThreadTest { public static void main(String[] args) throws Exception { ThreadPoolExecutor executorOne = new ThreadPoolExecutor(5, 5, 1, TimeUnit.MINUTES, new ArrayBlockingQueue<Runnable>(20)); executorOne.execute(()->{ throw new NullPointerException(); }); } }
运行结果：
Exception in thread "pool-1-thread-1" java.lang.NullPointerException at com.example.dto.ThreadTest.lambda$main$0(ThreadTest.java:17) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)
可以发现，默认打印的线程池名字是pool-1-thread-1，如果排查问题起来，并不友好。因此建议大家给自己线程池自定义个容易识别的名字。其实用CustomizableThreadFactory即可，正例如下：
public class ThreadTest { public static void main(String[] args) throws Exception { ThreadPoolExecutor executorOne = new ThreadPoolExecutor(5, 5, 1, TimeUnit.MINUTES, new ArrayBlockingQueue<Runnable>(20),new CustomizableThreadFactory("Tianluo-Thread-pool")); executorOne.execute(()->{ throw new NullPointerException(); }); } }
线程池参数设置不合理
线程池最容易出坑的地方，就是线程参数设置不合理。比如核心线程设置多少合理，最大线程池设置多少合理等等。当然，这块不是乱设置的，需要结合具体业务。
比如线程池如何调优，如何确认最佳线程数？
最佳线程数目 = （（线程等待时间+线程CPU时间）/线程CPU时间 ）* CPU数目
我们的服务器CPU核数为8核，一个任务线程cpu耗时为20ms，线程等待（网络IO、磁盘IO）耗时80ms，那最佳线程数目：( 80 + 20 )/20 * 8 = 40。也就是设置 40个线程数最佳。
线程池异常处理的坑
public class ThreadTest { public static void main(String[] args) throws Exception { ThreadPoolExecutor executorOne = new ThreadPoolExecutor(5, 5, 1, TimeUnit.MINUTES, new ArrayBlockingQueue<Runnable>(20),new CustomizableThreadFactory("Tianluo-Thread-pool")); for (int i = 0; i < 5; i++) { executorOne.submit(()->{ System.out.println("current thread name" + Thread.currentThread().getName()); Object object = null; System.out.print("result## " + object.toString()); }); } } }
按道理，运行这块代码应该抛空指针异常才是的，对吧。但是，运行结果却是这样的;
current thread nameTianluo-Thread-pool1 current thread nameTianluo-Thread-pool2 current thread nameTianluo-Thread-pool3 current thread nameTianluo-Thread-pool4 current thread nameTianluo-Thread-pool5
这是因为使用submit提交任务，不会把异常直接这样抛出来。最好就是try...catch捕获
public class ThreadTest { public static void main(String[] args) throws Exception { ThreadPoolExecutor executorOne = new ThreadPoolExecutor(5, 5, 1, TimeUnit.MINUTES, new ArrayBlockingQueue<Runnable>(20),new CustomizableThreadFactory("Tianluo-Thread-pool")); for (int i = 0; i < 5; i++) { executorOne.submit(()->{ System.out.println("current thread name" + Thread.currentThread().getName()); try { Object object = null; System.out.print("result## " + object.toString()); }catch (Exception e){ System.out.println("异常了"+e); } }); } } }
也可以使用Future.get来获取异常。
线程池使用完毕后，忘记关闭
如果线程池使用完，忘记关闭的话，有可能会导致内存泄露问题。所以，大家使用完线程池后，记得关闭一下。同时，线程池最好也设计成单例模式，给它一个好的命名，以方便排查问题。
public class ThreadTest { public static void main(String[] args) throws Exception { ThreadPoolExecutor executorOne = new ThreadPoolExecutor(5, 5, 1, TimeUnit.MINUTES, new ArrayBlockingQueue<Runnable>(20), new CustomizableThreadFactory("Tianluo-Thread-pool")); executorOne.execute(() -> { }); //关闭线程池 executorOne.shutdown(); } }
ThreadLocal与线程池搭配，线程复用，导致信息错乱
使用ThreadLocal缓存信息，如果配合线程池一起，有可能出现信息错乱的情况。先看下一下例子：
private static final ThreadLocal<Integer> currentUser = ThreadLocal.withInitial(() -> null); @GetMapping("wrong") public Map wrong(@RequestParam("userId") Integer userId) { //设置用户信息之前先查询一次ThreadLocal中的用户信息 String before = Thread.currentThread().getName() + ":" + currentUser.get(); //设置用户信息到ThreadLocal currentUser.set(userId); //设置用户信息之后再查询一次ThreadLocal中的用户信息 String after = Thread.currentThread().getName() + ":" + currentUser.get(); //汇总输出两次查询结果 Map result = new HashMap(); result.put("before", before); result.put("after", after); return result; }
按理说，每次获取的before应该都是null，但是呢，程序运行在 Tomcat 中，执行程序的线程是Tomcat的工作线程，而Tomcat的工作线程是基于线程池的。
线程池会重用固定的几个线程，一旦线程重用，那么很可能首次从 ThreadLocal 获取的值是之前其他用户的请求遗留的值。这时，ThreadLocal 中的用户信息就是其他用户的信息。
把tomcat的工作线程设置为1
server.tomcat.max-threads=1
用户1，请求过来，会有以下结果，符合预期：
用户2请求过来，会有以下结果，「不符合预期」：
因此，使用类似 ThreadLocal 工具来存放一些数据时，需要特别注意在代码运行完后，显式地去清空设置的数据，正例如下：
@GetMapping("right") public Map right(@RequestParam("userId") Integer userId) { String before = Thread.currentThread().getName() + ":" + currentUser.get(); currentUser.set(userId); try { String after = Thread.currentThread().getName() + ":" + currentUser.get(); Map result = new HashMap(); result.put("before", before); result.put("after", after); return result; } finally { //在finally代码块中删除ThreadLocal中的数据，确保数据不串 currentUser.remove(); } }
13.机器问题 （GC、线程打满、太多IO资源没关闭等等）
有时候，我们的接口慢，就是机器处理问题。主要有fullGC、线程打满、太多IO资源没关闭等等。
GC
比如说要导出60W+的excel的时候，卡死了，接着收到了监控告警。排查得出，代码是Apache POI生成的excel，导出excel数据量很大时，当时JVM内存吃紧会直接Full GC了。
无论是Young GC还是Full GC，在进行垃圾回收时都会暂停所有的业务线程。因此，需要关注垃圾回收的频率，以确保对业务的影响尽可能小。
一般情况下，通过调整堆大小和新生代大小可以解决大部分垃圾回收问题。其中，新生代是用于存放新创建的对象的区域。对于Young GC的频率增加的情况，一般是系统的请求量大量增长导致。但如果young gc增长非常多，就需要考虑是否需要增加新生代的大小。
因为如果新生代过小，很容易被打满。这导致本可以被Young GC掉的对象被晋升（Promotion）到老年代，过早地进入老年代。这样一来，不仅Young GC频繁触发，Full GC也会频繁触发。
线程
如果线程打满了，也会导致接口都在等待了。所以。如果是高并发场景，我们需要接入限流，把多余的请求拒绝掉。
资源
如果IO资源没关闭，也会导致耗时增加。这个大家可以看下，平时你的电脑一直打开很多很多文件，是不是会觉得很卡。
提升服务器硬件
如果cpu负载较高 可以考虑提高每个实例cpu数量，提高实例个数。同时关注网络IO负载，如果机器流量较大，网卡带宽可能成为瓶颈。
高峰期和低峰期如果机器负载相差较大，可以考虑设置弹性伸缩策略，高峰期之前自动扩容，低峰期自动缩容，最大程度提高资源利用率。
关于JVM调优部分的内容，将会在后续专门的出一些文章，因为目前笔者对这方面理解还不够，所以暂不多做赘述！！！
14.调用链路优化
在评估接口性能时，我们需要首先找出最耗时的部分，并优化它，这样优化效果才会立竿见影。
跨地域调用
假如说北京到上海的跨地域调用需要耗费大约30毫秒的时间，这个耗时是相当高的，所以我们应该特别关注调用链路上是否存在跨地域调用的情况。这些跨地域调用包括Rpc调用、Http调用、数据库调用、缓存调用以及MQ调用等等。在整理调用链路的时候，我们还应该标注出跨地域调用的次数，例如跨地域调用数据库可能会出现多次，在链路上我们需要明确标记。我们可以考虑通过降低调用次数来提高性能，因此在设计优化方案时，我们应该特别关注如何减少跨地域调用的次数。
举个例子，在某种情况下，假设上游服务在上海，而我们的服务在北京和上海都有部署，但是数据库和缓存的主节点都在北京，这时候就无法避免跨地域调用。那么我们该如何进行优化呢？考虑到我们的服务会更频繁地访问数据库和缓存，如果让我们上海节点的服务去访问北京的数据库和缓存，那么跨地域调用的次数就会非常多。因此，我们应该让上游服务去访问我们在北京的节点，这样只会有1次跨地域调用，而我们的服务在访问数据库和缓存时就无需进行跨地域调用。
单元化架构：不同的用户路由到不同的集群单元
如果主数据库位于北京，那么南方的用户每次写请求就只能通过跨地域访问来完成吗？实际上并非如此。数据库的主库不仅可以存在于一个地域，而是可以在多个地域上部署主数据库。将每个用户归属于最近的地域，该用户的请求都会被路由到所在地域的数据库。这样的部署不仅提升了系统性能，还提高了系统的容灾等级，即使单个机房发生故障也不会影响全网的用户。
这个思想类似于CDN（内容分发网络），它能够将用户请求路由到最近的节点。事实上，由于用户的存储数据已经在该地域的数据库中，用户的请求极少需要切换到其他地域。
为了实现这一点，我们需要一个用户路由服务来提供用户所在地域的查询，并且能够提供高并发的访问。
除了数据库之外，其他的存储中间件（如MQ、Redis等）以及Rpc框架都需要具备单元化架构能力。
微服务拆分过细会导致Rpc调用较多
微服务拆分过细会导致更多的RPC调用，一次简单的请求可能就涉及四五个服务，当访问量非常高时，多出来的三五次Rpc调用会导致接口耗时增加很多。
每个服务都需要处理网络IO，序列化反序列化，服务的GC 也会导致耗时增加，这样算下来一个大服务的性能往往优于5个微服务。
当然服务过于臃肿会降低开发维护效率，也不利于技术升级。微服务过多也有问题，例如增加整体链路耗时、基础架构升级工作量变大、单个需求代码变更的服务更多等弊端。需要你权衡开发效率、线上性能、领域划分等多方面因素。
提前过滤，减少无效调用
在某些活动匹配的业务场景里，相当多的请求实际上是不满足条件的，如果能尽早的过滤掉这些请求，就能避免很多无效查询。例如用户匹配某个活动时，会有非常多的过滤条件，如果该活动的特点是仅少量用户可参加，那么可首先使用人群先过滤掉大部分不符合条件的用户。
拆分接口
前面提到如果Http接口功能过于庞大，核心数据和非核心数据杂糅在一起，耗时高和耗时低的数据耦合在一起。为了优化请求的耗时，可以通过拆分接口，将核心数据和非核心数据分别处理，从而提高接口的性能。
而在Rpc接口方面，也可以使用类似的思路进行优化。当上游需要调用多个Rpc接口时，可以并行地调用这些接口。优先返回核心数据，如果处理非核心数据或者耗时高的数据超时，则直接降级，只返回核心数据。这种方式可以提高接口的响应速度和效率，减少不必要的等待时间。
