5秒到1秒，记一次效果“非常”显著的性能优化

并发编程一定要小心，尤其是在业务代码中的并发编程。我们构造了专用的线程池，来支撑这个并发获取的功能。

final ThreadPoolExecutor executor = new ThreadPoolExecutor(100, 200, 1, 
            TimeUnit.HOURS, new ArrayBlockingQueue<>(100)); 
复制代码

压缩和并行化，是我们本次优化中，最有效的手段。它们直接砍掉了请求大半部分的耗时，非常的有效。但我们还是不满足，因为每次请求，依然有1秒钟以上呢。

4. 缓存分类，进一步加速

我们发现，有些数据的获取，是放在循环中的，有很多无效请求，这不能忍。

for(List){
    client.getData();
}
复制代码

如果将这些常用的结果缓存起来，那么就可以大大减少网络IO请求的次数，增加程序的运行效率。

缓存在大多数应用程序的优化中，作用非常大。但由于压缩和并行效果的对比，缓存在我们这个场景中，效果不是非常的明显，但依然减少了大约三四十毫秒的请求时间。

我们是这么做的。

首先，我们将一部分代码逻辑简单，适合Cache Aside Pattern模式的数据，放在了分布式缓存Redis中。具体来说，就是读取的时候，先读缓存，缓存读不到的时候，再读数据库；更新的时候，先更新数据库，再删除缓存（延时双删）。使用这种方式，能够解决大部分业务逻辑简单的缓存场景，并能解决数据的一致性问题。

但是，仅仅这么做是不够的，因为有些业务逻辑非常的复杂，更新的代码发非常的分散，不适合使用Cache Aside Pattern进行改造。我们了解到，有部分数据，具有以下特点：

1. 这些数据，通过耗时的获取之后，在极端的时间内，会被再次用到
2. 业务数据对它们的一致性要求，可以控制在秒级别以内
3. 对于这些数据的使用，跨代码、跨线程，使用方式多样

针对于这种情况，我们设计了存在时间极短的堆内内存缓存，数据在1秒之后，就会失效，然后重新从数据库中读取。加入某个节点调用服务端接口是1秒钟1k次，我们直接给降低到了1次。

在这里，使用了Guava的LoadingCache，减少的Feign接口调用，是数量级的。

LoadingCache<String, String> lc = CacheBuilder
      .newBuilder()
      .expireAfterWrite(1,TimeUnit.SECONDS)
      .build(new CacheLoader<String, String>() {
      @Override
      public String load(String key) throws Exception {
            return slowMethod(key);
}});
复制代码

5. MySQL索引的优化

我们的业务系统，使用的是MySQL数据库，由于没有专业DBA介入，而且数据表是使用JPA生成的。在优化的时候，发现了大量不合理的索引，当然是要优化掉。

由于SQL具有很强的敏感性，我这里只谈一些在优化过程中碰到的索引优化规则问题，相信你一样能够在自己的业务系统中进行类比。

索引非常有用，但是要注意，如果你对字段做了函数运算，那索引就用不上了。常见的索引失效，还有下面两种情况：

• 查询的索引字段类型，与用户传递的数据类型不同，要做一层隐式转换。比如varchar类型的字段上，传入了int参数
• 查询的两张表之间，使用的字符集不同，也就无法使用关联字段作为索引

MySQL的索引优化，最基本的是遵循最左前缀原则，当有a、b、c三个字段的时候，如果查询条件用到了a，或者a、b，或者a、b、c，那么我们就可以创建（a，b，c）一个索引即可，它包含了a和ab。当然，字符串也是可以加前缀索引的，但在平常应用中较少。

有时候，MySQL的优化器，会选择了错误的索引，我们需要使用force index指定所使用的索引。在JPA中，就要使用nativeQuery，来书写绑定到MySQL数据库的SQL语句，我们尽量的去避免这种情况。

另外一个优化是减少回表。由于InnoDB采用了B+树，但是如果不使用非主键索引，会通过二级索引（secondary index）先查到聚簇索引（clustered index），然后再定位到数据。多了一步，产生回表。使用覆盖索引，可以一定程度上避免回表，是常用的优化手段。具体做法，就是把要查询的字段，与索引放在一起做联合索引，是一种空间换时间的做法。

6. JVM优化

我通常将JVM的优化放在最后一环。而且，除非系统发生了严重的卡顿，或者OOM问题，都不会主动对其进行过度优化。

很不幸的是，我们的应用，由于开启了大内存（8GB+），在JDK1.8默认的并行收集器下，经常发生卡顿。虽然不是很频繁，但动辄几秒钟，已经严重影响到部分请求的平滑性。

程序刚开始，是光秃秃跑在JVM下的，GC信息，还有OOM，什么都没留下。为了记录GC信息，我们做了如下的改造。

第一步，加入GC问题排查的各种参数。

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/opt/xxx.hprof  -DlogPath=/opt/logs/ -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintTenuringDistribution -Xloggc:/opt/logs/gc_%p.log -XX:ErrorFile=/opt/logs/hs_error_pid%p.log
复制代码

这样，我们就可以拿着生成的GC文件，上传到gceasy等平台进行分析。可以查看JVM的吞吐量和每个阶段的延时等。

第二步，开启SpringBoot的GC信息，接入Promethus监控。

在pom中加入依赖。

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
复制代码

然后配置暴露点就可以了。这样，我们就拥有了实时的分析数据，有了优化的依据。

management.endpoints.web.exposure.include=health,info,prometheus
复制代码

在观测了JVM的表现之后，我们切换成了G1垃圾回收器。G1有最大停顿目标，可以让我们的GC时间更加的平滑。它主要有以下几个调优参数：

• -XX:MaxGCPauseMillis 设置目标停顿时间，G1会尽力达成。
• -XX:G1HeapRegionSize 设置小堆区大小。这个值为2的次幂，不要太大，也不要太小。如果是在不知道如何设置，保持默认。
• -XX:InitiatingHeapOccupancyPercent 当整个堆内存使用达到一定比例（默认是45%），并发标记阶段就会被启动。
• -XX:ConcGCThreads 并发垃圾收集器使用的线程数量。默认值随JVM运行的平台不同而不同。不建议修改。

切换成G1之后，这种不间断的停顿，竟然神奇的消失了！期间，还发生过很多次内存溢出的问题，不过有MAT这种神器的加持，最终都很easy的被解决了。

7. 其他优化

在工程结构和架构方面，如果有硬伤的话，那么代码优化方面，起到的作用其实是有限的，就比如我们这种情况。

但主要代码还是要整一下容得。有些处于高耗时逻辑中的关键的代码，我们对其进行了格外的关照。按照开发规范，对代码进行了一次统一的清理。其中，有几个印象比较深深刻的点。

有同学为了能够复用map集合，每次用完之后，都使用clear方法进行清理。

map1.clear();
map2.clear();
map3.clear();
map4.clear();
复制代码

这些map中的数据，特别的多，而clear方法有点特殊，它的时间复杂度事O(n)的，造成了较高的耗时。

public void clear() {
    Node<K,V>[] tab;
    modCount++;
    if ((tab = table) != null && size > 0) {
        size = 0;
        for (int i = 0; i < tab.length; ++i)
            tab[i] = null;
    }
}
复制代码

同样的线程安全的队列，有ConcurrentLinkedQueue，它的size()方法，时间复杂度非常高，不知怎么就被同事给用上了，这都是些性能杀手。

public int size() {
        restartFromHead: for (;;) {
            int count = 0;
            for (Node<E> p = first(); p != null;) {
                if (p.item != null)
                    if (++count == Integer.MAX_VALUE)
                        break;  // @see Collection.size()
                if (p == (p = p.next))
                    continue restartFromHead;
            }
            return count;
        }
}
复制代码

另外，有些服务的web页面，本身响应就非常的慢，这是由于业务逻辑复杂，前端JavaScript本身就执行缓慢。这部分代码优化，就需要前端的同事去处理了，如图，使用chrome或者firefox的performance选项卡，可以很容易发现耗时的前端 代码。

8. 总结

性能优化，其实也是有套路的，但一般团队都是等发生了问题才去优化，鲜有未雨绸缪的。但有了监控和APM就不一样，我们能够随时拿到数据，反向推动优化过程。

有些性能问题，能够在业务需求层面，或者架构层面去解决。凡是已经带到代码层，需要程序员介入的优化，都已经到了需求方和架构方不能再乱动，或者不想再动的境地。

性能优化首先要收集信息，找出瓶颈点，权衡CPU、内存、网络、、IO等资源，然后尽量的减少平均响应时间，提高吞吐量。

缓存、缓冲、池化、减少锁冲突、异步、并行、压缩，都是常见的优化方式。在我们的这个场景中，起到最大作用的，就是数据压缩和并行请求。当然，加上其他优化方法的协助，我们的业务接口，由5-6秒的耗时，直接降低到了1秒之内，这个优化效果还是非常可观的。估计在未来很长一段时间内，都不会再对它进行优化了。

作者：小姐姐味道
链接：https://juejin.cn/post/6997944097155579934