最近我们项目升级到了 Spring Boot 2.4.6 + Spring Cloud 2020.0.x，通过我的另一系列即可看出：Spring Cloud 升级之路。但是升级后，我们发现 YoungGC 明显增高，分配对象速率明显增高，但是晋升的对象并没有增多，证明都是新创建的对象并且没过多久就可以被回收。我们来看其中一个进程的监控，这时候的 http 请求速率大概在 100 左右：
这就很奇怪了，请求速率并没有那么大，但是通过监控可以看出每秒钟分配了将近两个 G 的内存。在升级之前，这个分配速率大概在 100~200 MB 左右，在同等请求速率下。那么这多出来的内存究竟是哪里消耗的呢？
我们需要看一下内存中各种对象的统计数据，即使用 jmap 命令。同时不能只查看存活对象的统计，因为从监控中看出来并不是老年代对象过多，因为晋升的对象并没有增多，相反的，我们如果我们能排除现在还存活的对象就更好了。同时，由于 GC 相当频繁，1s 左右就会有一次。所以基本不能期望一次就能抓到我们想要的 jmap。同时 jmap 会导致所有线程进入 safepoint 从而 STW，对线上有一定影响，所以不能太频繁 jmap。所以，我们采取如下策略：
扩容一个实例，之后将一个实例，通过注册中心以及限流器将某个实例的流量切走一半；
针对这个实例，连续执行 jmap -histo（统计所有对象） 以及 jmap -histo:live（仅统计存活对象）；
重复第二步 5 次，每次间隔 100ms，300ms，500ms，700ms；
去掉限流这个实例的限流，将新扩容的实例关闭。
通过这几次的 jmap 对比，我们发现 jmap 统计中排在前面的对象类型有一个 spring 框架的：
num #instances #bytes class name (module) ------------------------------------------------------- 1: 7993252 601860528 [B (java.base@11.0.8) 2: 360025 296261160 [C (java.base@11.0.8) 3: 10338806 246557984 [Ljava.lang.Object; (java.base@11.0.8) 4: 6314471 151547304 java.lang.String (java.base@11.0.8) 5: 48170 135607088 [J (java.base@11.0.8) 6: 314420 126487344 [I (java.base@11.0.8) 7: 4591109 110100264 [Ljava.lang.Class; (java.base@11.0.8) 8: 245542 55001408 org.springframework.core.ResolvableType 9: 205234 29042280 [Ljava.util.HashMap$Node; (java.base@11.0.8) 10: 386252 24720128 [org.springframework.core.ResolvableType; 11: 699929 22397728 java.sql.Timestamp (java.sql@11.0.8) 12: 89150 21281256 [Ljava.beans.PropertyDescriptor; (java.desktop@11.0.8) 13: 519029 16608928 java.util.HashMap$Node (java.base@11.0.8) 14: 598728 14369472 java.util.ArrayList (java.base@11.0.8)这个对象是怎么创建出来的呢？如何定位一个已经不再存活的频繁创建对象，并且这个对象类型是框架内部的？
首先，MAT（Eclipse Memory Analyzer）+ jmap dump 这种整个堆分析，并不太适用，原因是：
对象已经不再存活，MAT 更适合对于内存泄漏的分析，我们这里是创建出来很多预期外的对象，占用了大量内存，这些对象很快就不再存活。
MAT 对于不再存活的对象，无法准确分析出创建者，主要因为 dump 的时候不确定是否能抓到我们想要的信息，或者有很多信息噪声。
虽然这个问题不能这么定位，我还是将我采集的 jmap dump 结果放在这里用 MAT 分析的结果展示出来给大家看下：
那么接下来怎么分析呢？这就又用到了我们的老朋友，JFR + JMC。老读者知道，我经常使用 JFR 定位线上问题，这里怎么使用呢？并没有直接的 JFR 事件统计经常创建哪些对象，但是呢，有间接的事件，可以间接体现是谁创建了这么多对象。我一般这么定位：
通过线程分配对象统计事件查看是哪个线程分配对象过多（Thread Allocation Statistics）。