转载

SpringBoot2.2.x 版本CPU增高BUG分析

一、发现问题

项目在上线之后，运行24小时之后CPU突然增高，导致不得不重启机器。

二、分析及定位问题

项目在上线前是经过压力测试，刚开始定位是QPS过大，通过增加机器。但结果并不是特别理想，始终会有几台机器增高。

项目环境

[x] 测试机 1c2g

通过jmeter对该机器接口进行压力测试，qps为90，cpu增高到40%持续没多久下降到10%，一直持续稳定。并未产生CPU过高的情况，该机器配置比正式环境要低4倍，第一步得出的结论应该不在接口上

2、更换项目中比较早期版本的插件及线程池

重新上线项目之后，运行1天之后，依然有2台机器的CPU持续增高，并且越往后增加越大

3、开始针对线上高CPU服务器排查

#查看java的pid
top  
#查看pid下的占用高的tid 
top -Hp pid  
#打印tid16进制
printf "%xn" tid  
#查看栈 输出到xx.log
jstack pid|grep -A 2000 tid的16进制 > xx.log

#查看gc 打印每2000ms输出一次，共10次
jstat -gcutil pid 2000 10

结论：栈信息基本都是RUN或TIME_WATING 并没有相关的死锁的线程，但是通过gc发现大量的YGC持续的增高，这时候考虑到可能堆的信息有异常

4、针对堆信息查看

#查看堆
jmap pid  
jmap -heap pid  
jmap -histo:live pid  
...

#常用的是最后一个 加一个more 防止过多内容刷屏 
jmap -histo:live pid|more

执行多次最后一个命令，发现一个队列在持续的增高，几百几百的增加并无然后减少的情况

1:        111885      139385304  [Ljava.lang.Object;
   3:         10515       15412904  [I
   4:        142407       13450056  [C
   5:         13892        4170928  [B
   6:        135968        3263232  java.lang.String
   .....
  34:          6423         308304  java.util.HashMap
  35:         12459         299016  java.util.concurrent.ConcurrentLinkedQueue$Node

最后一行就是发现增长过快的队列，到此算是发现了一个比较有用的信息，回头就去分析代码。但依然没有什么结论，代码逻辑并不复杂也并未使用到该队列。

5、咨询大佬，建议通过火焰图定位某个阶段执行过程的消耗情况

#开始安装火陷图插件
#具体安装插件的过程，大家自行搜索，本文不具体描述如何安装火陷图

6、执行命令生成火陷图

SpringBoot2.2.x 版本CPU增高BUG分析

通过上图，我们能直观的看到在MimeTypeUtils方法中，使用到了过多的这个队列，然后就直接去看源码了。目前官方已经修复了一版在2.2.6版本中（但是很不幸运，并没有完全修复）

下面是2.2.6版本修复一版的代码，去除了之前的一些没有意义判断,MimeTypeUtils.java文件

private static class ConcurrentLruCache<K, V> {

        private final int maxSize;

        private final ConcurrentLinkedQueue<K> queue = new ConcurrentLinkedQueue<>();

        ....

        public V get(K key) {
            this.lock.readLock().lock();
            try {
                if (this.queue.size() < this.maxSize / 2) {
                    V cached = this.cache.get(key);
                    if (cached != null) {
                        return cached;
                    }
                }
                else if (this.queue.remove(key)) {
                    this.queue.add(key);
                    return this.cache.get(key);
                }
            }
            finally {
                this.lock.readLock().unlock();
            }
            this.lock.writeLock().lock();
            try {
                // retrying in case of concurrent reads on the same key
                if (this.queue.remove(key)) {
                    this.queue.add(key);
                    return this.cache.get(key);
                }
                if (this.queue.size() == this.maxSize) {
                    K leastUsed = this.queue.poll();
                    if (leastUsed != null) {
                        this.cache.remove(leastUsed);
                    }
                }
                V value = this.generator.apply(key);
                this.queue.add(key);
                this.cache.put(key, value);
                return value;
            }
            finally {
                this.lock.writeLock().unlock();
            }
        }
    }

单纯的阅读代码，并没有什么大的BUG，但是我们可以去关注队列本身的问题。

查看ConcurrentLinkedQueue remove 源码

public boolean remove(Object o) {
    if (o != null) {
      Node<E> next, pred = null;
      for (Node<E> p = first(); p != null; pred = p, p = next) {
        boolean removed = false;
        E item = p.item;
        if (item != null) {
          if (!o.equals(item)) {
            next = succ(p);
            continue;
          }
          removed = p.casItem(item, null);
        }

        next = succ(p);
        if (pred != null && next != null) // unlink
          pred.casNext(p, next);
        if (removed)
          return true;
      }
    }
    return false;
}

如果存在多个则删除第一个，并返回true，否者返回false，例如：多个线程同时要获取到同一个要删除的元素，则只删除一个，其他返回false，再结合MimeTypeUtils方法，会再去执行add，这就导致会对队列出现无限的增长【可能】（非百分百）。

造成CPU性能过高，是因为队列长度过长，remove方法需要遍历整个队列内容。队列过长的原因是因为remove 并发情况下返回false，开发过程中可能并未关注到remove会返回false，导致无限的执行add方法的可能。

三、验证问题

通过debug发现spring boot在执行过程中会针对用户请求的Accept和返回的Content-Type都会调用该方法。这时候其实就可以恶意构造Accept去请求某个api，Accept中每个用逗号分割都会过一次方法，导致大量性能消耗。本地通过构造多个Accpet值，发现在MimeTypeUtils中确实可以超出本身对队列的长度设置，导致缓慢增长。

1、通过官方github-issues搜索相关问题，发现已经有人在最近提到过该问题，并已经被close。

2、通过再次回复官方研发人员，并提供更多的相关信息证明2.2.6版本修复之后依然存在该问题

[x] https://github.com/spring-projects/spring-framework/issues/24671#issuecomment-611427157

3、在此期间又有人给出通过MediaType 上传类型构造的Accept

[x] https://github.com/spring-projects/spring-framework/issues/24767

4、具体构造验证

[x] 找一台低配版的服务 1c2g
[ ] 使用jmeter，设置线程组，不需要特别高50个线程，永久发送

[ ] 设置header的Accpet，可以先使用内容如下：

application/stream+x-jackson-smile, application/vnd.spring-boot.actuator.v3+json, application/vnd.spring-boot.actuator.v2+json, application/json, multipart/form-data; boundary=----WebKitFormBoundaryVHfecvFDYeDEjhu4, multipart/form-data; boundary=----WebKitFormBoundarymKzwdDkWNDNzQFP0, multipart/form-data; boundary=----WebKitFormBoundaryiWpMXOUbWwBwq2AX, application/x-www-form-urlencoded, text/html;charset=UTF-8, application/octet-stream, application/vnd.ms-excel;charset=utf8, application/msword, multipart/form-data; boundary=----WebKitFormBoundaryGF2AJ2ZdPqbWOyEO, multipart/form-data; boundary=----WebKitFormBoundaryTZLPpyBs2F0ycmkB, multipart/form-data; boundary=----WebKitFormBoundaryBUClXdZPA3oxpUpx, image/jpeg;charset=UTF-8, multipart/form-data; boundary=----WebKitFormBoundarysODcdeMwzfHwEjtw, multipart/form-data; boundary=----WebKitFormBoundary26i2en6YQUSXUBzs, multipart/form-data; boundary=----WebKitFormBoundaryxUUWAyZnZjwlM1oy, multipart/form-data; boundary=----WebKitFormBoundarysVMYk11tVTTsXuEB, multipart/form-data; boundary=----WebKitFormBoundaryXsI4dpNsVTCWWrRo, multipart/form-data; boundary=----WebKitFormBoundaryiV1owCGwTHyQzja0, multipart/form-data; boundary=----WebKitFormBoundarygf1XpLmgasAQU9fi, multipart/form-data; boundary=----WebKitFormBoundaryBNaQtUvpQ2VV7YYA, multipart/form-data; boundary=----WebKitFormBoundaryW1rdrg4AbJ5Jn3Po, multipart/form-data; boundary=----WebKitFormBoundaryoBwFj2ABM5LflDmW, multipart/form-data; boundary=----WebKitFormBoundary40xI2TxryjbkSCtO, multipart/form-data; boundary=----WebKitFormBoundarytaCC9B6g8u4urnLF, multipart/form-data; boundary=----WebKitFormBoundaryOrhplGKYP9ozLkCs, multipart/form-data; boundary=----WebKitFormBoundaryvEUouFAr3R3YJYBh, multipart/form-data; boundary=----WebKitFormBoundaryuQ9tEKtn59w5hPLY, multipart/form-data; boundary=----WebKitFormBoundaryRGvPXUBAuZ6xJ95u, application/vnd.openxmlformats-officedocument.wordprocessingml.document, multipart/form-data; boundary=----WebKitFormBoundary7jpljZi4k61KhCNN, multipart/form-data; boundary=----WebKitFormBoundary7GVKDTHVuBABvjGB, multipart/form-data; boundary=----WebKitFormBoundaryZbNBPl3T4VZ44q6B, audio/mp3, multipart/form-data; boundary=----WebKitFormBoundaryI6rUM76YvxrIEcqv, multipart/form-data; boundary=----WebKitFormBoundaryag4BDWrzifHRdDiR, multipart/form-data; boundary=----WebKitFormBoundary1YRsWAdVqDin8g8p, multipart/form-data; boundary=----WebKitFormBoundaryDaatlrV3KAyZu7wA, multipart/form-data; boundary=----WebKitFormBoundaryyhvikZJdRGH1AjQq, multipart/form-data; boundary=----WebKitFormBoundary2z4SJhqeEx5XtVj4, multipart/form-data; boundary=----WebKitFormBoundaryeDLd1MTvuhmcmzNe, multipart/form-data; boundary=----WebKitFormBoundarybKizrvRESfhxHAMQ, multipart/form-data; boundary=----WebKitFormBoundary24U8tmsOluZqcRXX, multipart/form-data; boundary=----WebKitFormBoundarye4j6KdQyBjY4FqSk, multipart/form-data; boundary=----WebKitFormBoundaryjPmgLdzMcMYYB3yS, multipart/form-data; boundary=----WebKitFormBoundaryxzBZ9w6Je3IJ53NM, multipart/form-data; boundary=----WebKitFormBoundaryScy0j73cvx3iCFyY, multipart/form-data; boundary=----WebKitFormBoundaryTBoS8s4YWwmBGTDA, image/*, multipart/form-data; boundary=----WebKitFormBoundaryRUutFo3RXlNPgoBS, text/html;charset=utf-8, multipart/form-data; boundary=----WebKitFormBoundarykLObBi1tJMf158kt, multipart/form-data; boundary=----WebKitFormBoundary8M8MfCWBEFcsxnBU

[ ] 开始进行请求，然后我们再通过服务器中针对堆信息查看命令，查看 ConcurrentLinkedQueue队列增长情况

[ ] 持续压测，然后再打开另三个jemter，做同样的请求操作，将header的Accept分别设置如下三种情况，也可以更多：

#第一种
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
#第二种
text/css,*/*;q=0.1
#第三种
application/json

[ ] 以上三个线程可以设置每个为30，永久。

[ ] 我们再通过打印堆信息可以发现ConcurrentLinkedQueue队列开始突破限制突然增高，又突然减少，这时候可以把第一个jmeter请求先暂停。然后再持续观察堆信息

[xx<a title="@xxx" href="https://github.com/xxx">@xxx</a> ~]$ jmap -histo:live 10114|grep java.util.concurrent.ConcurrentLinkedQueue
  33:          4809         115416  java.util.concurrent.ConcurrentLinkedQueue$Node
 768:            36            864  java.util.concurrent.ConcurrentLinkedQueue
[xx<a title="@xxx" href="https://github.com/xxx">@xxx</a> ~]$ jmap -histo:live 10114|grep java.util.concurrent.ConcurrentLinkedQueue
  30:          5530         132720  java.util.concurrent.ConcurrentLinkedQueue$Node
 768:            36            864  java.util.concurrent.ConcurrentLinkedQueue
[xx<a title="@xxx8" href="https://github.com/xxx8">@xxx8</a> ~]$ jmap -histo:live 10114|grep java.util.concurrent.ConcurrentLinkedQueue
  30:          5530         132720  java.util.concurrent.ConcurrentLinkedQueue$Node
 767:            36            864  java.util.concurrent.ConcurrentLinkedQueue
[xx<a title="@xxx" href="https://github.com/xxx">@xxx</a> ~]$ jmap -histo:live 10114|grep java.util.concurrent.ConcurrentLinkedQueue
  29:          6994         167856  java.util.concurrent.ConcurrentLinkedQueue$Node
 768:            36            864  java.util.concurrent.ConcurrentLinkedQueue
[xx<a title="@xxx" href="https://github.com/xxx">@xxx</a> ~]$ jmap -histo:live 10114|grep java.util.concurrent.ConcurrentLinkedQueue
  29:          7262         174288  java.util.concurrent.ConcurrentLinkedQueue$Node
 768:            36            864  java.util.concurrent.ConcurrentLinkedQueue
[xx<a title="@xxx" href="https://github.com/xxx">@xxx</a> ~]$ jmap -histo:live 10114|grep java.util.concurrent.ConcurrentLinkedQueue
  26:          9829         235896  java.util.concurrent.ConcurrentLinkedQueue$Node
 777:            36            864  java.util.concurrent.ConcurrentLinkedQueue

明显可以发现ConcurrentLinkedQueue在增高。到此针对SpringBoot在2.2.6版本中cpu持续增高情况已经可以完全的复现，复现过程可能会存在不成功，可以多试几次。

四、解决方案

1、目前发现在多核CPU的情况下增长比较缓慢，但是到一定的长度之后也会加速加大CPU的消耗，所以高配置可能是一个解决方案

2、降级方案，目前通过对比。SpringFramework在5.1.x版本无太大影响。

3、等待更新目前master再次修复一版，预计4.27发布，官方也将MimeTypeUtils列为5.3.x版本重构之一

#修复方案从 ConcurrentLinkedQueue 队列切换到了 ConcurrentLinkedDeque 队列

五、补充

验证 ConcurrentLinkedQueue 队列，出现false情况

import java.util.concurrent.ConcurrentLinkedQueue;
import java.util.concurrent.LinkedBlockingQueue;

public class Main {
    private static ConcurrentLinkedQueue<Integer> queue = new ConcurrentLinkedQueue<>();

    public static void main(String[] args) {
        for (int i = 0; i < 1000; i++) {
            Thread thread1 = new QueueThread(String.valueOf(i));
            thread1.start();
        }
        try {
            Thread.sleep(5000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println("end");
    }

    static class QueueThread extends Thread {
        private int value = 0;

        private String name;

        public QueueThread(String name) {
            this.name = name;
            queue.add(value);
        }

        @Override
        public void run() {
            for (int i = 1; i < 1000; i++) {
                try {
                    boolean flag = queue.remove(value);
                    System.out.println("remove: " + value + " "+ flag);
                    queue.add(value);
                    value++;
                } catch (Exception e) {
                    System.out.println(e);
                }
            }
        }
    }
}

备注：如果是2.2.1-2.2.5 版本是会造成频繁的拿锁与解锁，本篇是以2.2.6版本为分析

原文 https://www.anquanke.com/post/id/203909

正文到此结束