k8s 部署 springboot 项目内存持续增长问题分析解决

写在前面


  • 工作中遇到,请教公司前辈解决,简单整理记忆
  • 博文内容涉及一次 GC 问题的分析以及解决
  • 理解不足小伙伴帮忙指正 😃,生活加油

99%的焦虑都来自于虚度时间和没有好好做事,所以唯一的解决办法就是行动起来,认真做完事情,战胜焦虑,战胜那些心里空荡荡的时刻,而不是选择逃避。不要站在原地想象困难,行动永远是改变现状的最佳方式


遇到了什么问题

一个线上的项目,部署在 K8s 上,随着业务量的增加,内存持续增长,当内存上升到申请的内存之后,Web 系统开始卡顿,很长时间无法使用,目前没有什么好的解决办法,每天重启一次。项目中涉及到大量的对其他服务的调用,而且返回报文较大。

下面为一个业务高峰内存异常时,当前Pod 资源使用情况

接口调用返回 JSON 报文 1.79MB,耗时 41.61s

如何解决:

请教公司前辈,做内存 CG 分析,定位问题,怀疑是频繁的CG导致

这里我们先看下在本地环境如何分析,在分析之前,先简单介绍下用的到工具

Apache JMeter

Apache JMeter 是一个功能强大的开源负载测试工具,可以用于测试各种应用的性能,包括Web应用、数据库、FTP服务

支持多种协议和场景,包括HTTP、Web服务、数据库等。适合进行接口测试和压力测试

实际压测,需要添加线程组,配置报文头请求内容结果树汇总报告

适用场景:适用于Web应用、API服务、分布式系统等性能测试

JVisualVM

一个免费的、集成了多个JDK命令行工具的可视化工具。它能提供强大的分析能力,包括生成和分析海量数据、跟踪内存泄漏、监控垃圾回收器、执行内存和CPU分析等。

下面为 CPU, 内存,类,线程的跟踪

下面为VisualVM 中 GC可视化插件,这个插件默认没有,需要单独下载安装

这里我们顺便回忆一下,JVM内存模型

+----------------------------------+
|          JVM 内存模型            |
|                                  |
|  +------------------+          |
|  |(Heap)      |<---------+|
|  |                  |          |
|  +------------------+          |
|                                  |
|  +------------------+          |
|  | 方法区/元空间     |<---------+|
|  | (Method Area/Metaspace)|       |
|  +------------------+          |
|                                  |
|  +------------------+          |
|  | 虚拟机栈(JVM Stack) |<---------+|
|  |                  |          |
|  +------------------+          |
|                                  |
|  +------------------+          |
|  | 本地方法栈(Native Method Stack) |<---------+|
|  +------------------+          |
|                                  |
|  +------------------+          |
|  | 程序计数器(Program Counter) |<---------+|
|  +------------------+          |
+----------------------------------+

和 GC 对应的关系

+------------------+      +------------------+      +------------------+
|  堆内存(Heap)    | ----> |  方法区(Method Area) | ----> |  本地方法栈(Native Method Stack) |
+------------------+      +------------------+      +------------------+|                        ^                     ||                        |                     |v                        |                     v
+------------------+      +------------------+      +------------------+
|  新生代(Young Generation) |      |  持久代(PermGen, Java 7及之前) |      |  线程栈(Thread Stack) |
|  (Eden, Survivor)  |      |  (已废弃, Java 8起使用元空间) |      |  (存储局部变量和方法调用) |
+------------------+      +------------------+      +------------------+|                            ||                            v|                     +------------------+|                     |  元空间(Metaspace) ||                     +------------------+|                            |v                            v
+------------------+      +------------------+
|  老年代(Old Generation) |      |  代码缓存(Code Cache) |
+------------------+      +------------------+

界面说明

左侧 为实时的内存使用 元数据区(Metaspace)老年待(Old)新生代(Eden区 + Survivor区(S0和S1))

右侧 为 日志相关,涉及编译,类加载以及GC的日志

编译时间:11569次编译,每次编译耗时2.620秒。
类加载时间:15689个类被加载,平均每次加载耗时10.402秒。
GC 时间:197次GC,共27615毫秒。

GC日志

Eden新生代总大小为1.310G,使用量为710.500M,共182次收集,每次收集耗时17.848秒。
幸存区0和1的GC日志:

  • Surviver 0(447.500M, 301.500M):使用量为11.828M,显示了每次GC的时间分布和使用情况, 447.500M是幸存区0的上限,而301.500M是幸存区0的下限。
  • Surviver 1(447.500M, 316.000M):使用量为0.0M,显示了每次GC的时间分布和使用情况。

Old Gen:显示了老年代的内存使用情况,总大小为2.623G,使用量为663.208M,共15次收集,每次收集耗时9.767秒。

Metaspace:显示了元空间的内存使用情况,总大小为1.072G,使用量为86.086M。

这里我们简单回顾一下 分代垃圾回收机制

Heap 数据最先到达 eden 区,当Eden区满时,会触发Minor GC(也称为Young GC),将存活的对象转移到Survivor区(S0和S1)。Eden区的设计目标是快速分配内存,因此它通常比Survivor区大

Survivor 区有两个区域:S0和S1(有时也称为From和To)。在Minor GC过程中,存活的对象会从Eden区复制到Survivor区,并在两个Survivor区之间来回复制,直到它们达到一定年龄(由JVM参数MaxTenuringThreshold决定),然后晋升到老年代(Old Generation)Survivor区的设计目标是提供足够的空间以支持频繁的Minor GC,同时避免内存碎片。

经过多次Minor GC后,仍然存活的对象会被晋升到老年代。晋升到老年代的条件包括对象的大小、年龄以及Survivor区的空间使用情况。

当老年代空间不足时,会触发Major GC(也称为Old GC),回收老年代中不再使用的对象

major gc 什么时候会发生,它和 full gc 的区别是什么?

major gc很多参考资料指的是等价于full gc,即老年代的GC,我们也可以发现很多性能监测工具中只有minor gcfull gc

一般情况下,一次full gc将会对年轻代、老年代以及元空间、堆外内存进行垃圾回收。而触发Full GC的原因有很多:

  • 当年轻代晋升到老年代的对象大小比目前老年代剩余的空间大小还要大时,此时会触发Full GC;
  • 当老年代的空间使用率超过某阈值时,此时会触发Full GC;
  • 当元空间不足时(JDK1.7永久代不足),也会触发Full GC;
  • 当调用System.gc()也会安排一次Full GC;

问题复现

选择一个合适的接口 通过 JMeter 做压力测试

先配置较小的 堆分配,添加 JVM 参数 -Xms2024m -Xmx2024m, 通过 JVisualVM GC 查看内存日志

可以看到 即使GC 频繁回收,老年代和新生代的内存都是 100%,这个时候系统就基本属于卡顿状态

项目报错提示

org.springframework.web.util.NestedServletException: Handler dispatch failed; nested exception is java.lang.OutOfMemoryError: Java heap spaceat org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1087)at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:965)at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1006)at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:909)at javax.servlet.http.HttpServlet.service(HttpServlet.java:665)at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:883)at javax.servlet.http.HttpServlet.service(HttpServlet.java:750)

在处理Spring框架的Web请求时,发生了嵌套的Servlet异常。根本原因是Java堆内存不足(OutOfMemoryError: Java heap space)

所以这里我们 增加Java堆内存的大小,修改 启动参数 -Xms4024m -Xmx4024m

可以看到即使配置了 4G 的内存,还是存在问题,GC 频繁回收,老年代和新生代的内存使用没有下去。

项目抱错提示

org.springframework.web.util.NestedServletException: Handler dispatch failed; nested exception is java.lang.OutOfMemoryError: GC overhead limit exceededat org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1087)at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:965)at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1006)at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:909)at javax.servlet.http.HttpServlet.service(HttpServlet.java:665)at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:883)at javax.servlet.http.HttpServlet.service(HttpServlet.java:750)

Java垃圾回收器(GC)花费的时间过长,超过了默认的阈值(98%),导致应用程序无法正常运行。

在实际的场景中,如果是在 云平台,没有对应的桌面工具使用,可以考虑使用 Java 自带的一些性能分析工具

bash-4.4# which java
/opt/jdk/bin/java
bash-4.4# cd /opt/jdk/bin/
bash-4.4# ls
ControlPanel    jar             javac           javap           jconsole        jhat            jmc             jsadebugd       jstatd          orbd            rmid            servertool      wsimport
appletviewer    jarsigner       javadoc         javapackager    jcontrol        jinfo           jmc.ini         jstack          jvisualvm       pack200         rmiregistry     tnameserv       xjc
extcheck        java            javafxpackager  javaws          jdb             jjs             jps             jstack.log      keytool         policytool      schemagen       unpack200
idlj            java-rmi.cgi    javah           jcmd            jdeps           jmap            jrunscript      jstat           native2ascii    rmic            serialver       wsgen
bash-4.4# 

JDK bin 目录下有一些 Java 常用的性能分析工具

这里命令最后面的 1 为进程 id,容器化部署,所以主进程即为 业务进程,如果不是容器化部署,可能需要 top, pgrep 等命令来确定 进程ID

使用jinfo命令查看JVM的配置参数的输出

bash-4.4# jinfo -flags 1
Attaching to process ID 1, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.192-b12
Non-default VM flags: -XX:CICompilerCount=2 -XX:InitialHeapSize=4781506560 -XX:MaxHeapSize=4781506560 -XX:MaxNewSize=1593835520 -XX:MinHeapDeltaBytes=196608 -XX:NewSize=1593835520 -XX:OldSize=3187671040 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseFastUnorderedTimeStamps 
Command line:  -Xms4560m -Xmx4560m
bash-4.4#
  • JVM版本:JVM版本是25.192-b12。
  • 非默认VM标志:这些是JVM的非默认配置参数,包括:
  • XX:CICompilerCount=2:设置编译器数量为2。
  • XX:InitialHeapSize=4781506560:设置初始堆大小为4560.0MB。
  • XX:MaxHeapSize=4781506560:设置最大堆大小为4560.

使用 jmap 命令查看 JVM堆内存 配置和使用的输出。

下面为负载正常的输出

bash-4.4# jmap -heap 1
Attaching to process ID 1, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.192-b12using thread-local object allocation.
Mark Sweep Compact GCHeap Configuration:MinHeapFreeRatio         = 40MaxHeapFreeRatio         = 70MaxHeapSize              = 4781506560 (4560.0MB)NewSize                  = 1593835520 (1520.0MB)MaxNewSize               = 1593835520 (1520.0MB)OldSize                  = 3187671040 (3040.0MB)NewRatio                 = 2SurvivorRatio            = 8MetaspaceSize            = 21807104 (20.796875MB)CompressedClassSpaceSize = 1073741824 (1024.0MB)MaxMetaspaceSize         = 17592186044415 MBG1HeapRegionSize         = 0 (0.0MB)Heap Usage:
New Generation (Eden + 1 Survivor Space):capacity = 1434451968 (1368.0MB)used     = 644721408 (614.854248046875MB)free     = 789730560 (753.145751953125MB)44.945485968338815% used
Eden Space:capacity = 1275068416 (1216.0MB)used     = 615064856 (586.5715560913086MB)free     = 660003560 (629.4284439086914MB)48.237792441719456% used
From Space:capacity = 159383552 (152.0MB)used     = 29656552 (28.282691955566406MB)free     = 129727000 (123.7173080444336MB)18.607034181293688% used
To Space:capacity = 159383552 (152.0MB)used     = 0 (0.0MB)free     = 159383552 (152.0MB)0.0% used
tenured generation:capacity = 3187671040 (3040.0MB)used     = 42750216 (40.76978302001953MB)free     = 3144920824 (2999.2302169799805MB)1.3411112835532741% used40672 interned Strings occupying 4176272 bytes.
bash-4.4# 
  • JVM版本:JVM版本是25.192-b12。
  • GC类型:使用的是Mark Sweep Compact GC(标记-清除-紧凑)类型的垃圾回收器。
  • 堆内存配置:
    • 最小堆空闲比率(MinHeapFreeRatio):40%
    • 最大堆空闲比率(MaxHeapFreeRatio):70%
    • 最大堆大小(MaxHeapSize):4560.0MB
    • 新生代大小(NewSize):1520.0MB
    • 最大新生代大小(MaxNewSize):1520.0MB
    • 老年代大小(OldSize):3040.0MB
    • 新生代和老年代的比例(NewRatio):2
    • Survivor区的比例(SurvivorRatio):8
    • 元空间大小(MetaspaceSize):20.796875MB
    • 压缩类空间大小(CompressedClassSpaceSize):1024.0MB
    • 最大元空间大小(MaxMetaspaceSize):17592186044415 MB
    • G1堆区域大小(G1HeapRegionSize):0.0MB
  • 堆内存使用情况: 配额:capacity ,used 使用的,free 空闲的
    • 新生代(Eden + 1 Survivor Space):总容量为1368.0MB…
    • 老年代的使用率非常低 1.3411112835…

下面为负载异常的输出:

bash-4.4# jmap -heap 1
Attaching to process ID 1, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.192-b12using thread-local object allocation.
Mark Sweep Compact GCHeap Configuration:MinHeapFreeRatio         = 40MaxHeapFreeRatio         = 70MaxHeapSize              = 4781506560 (4560.0MB)NewSize                  = 1593835520 (1520.0MB)MaxNewSize               = 1593835520 (1520.0MB)OldSize                  = 3187671040 (3040.0MB)NewRatio                 = 2SurvivorRatio            = 8MetaspaceSize            = 21807104 (20.796875MB)CompressedClassSpaceSize = 1073741824 (1024.0MB)MaxMetaspaceSize         = 17592186044415 MBG1HeapRegionSize         = 0 (0.0MB)Heap Usage:
New Generation (Eden + 1 Survivor Space):capacity = 1434451968 (1368.0MB)used     = 1366285424 (1302.9913177490234MB)free     = 68166544 (65.00868225097656MB)95.24790334422686% used
Eden Space:capacity = 1275068416 (1216.0MB)used     = 1275068416 (1216.0MB)free     = 0 (0.0MB)100.0% used
From Space:capacity = 159383552 (152.0MB)used     = 91217008 (86.99131774902344MB)free     = 68166544 (65.00868225097656MB)57.23113009804174% used
To Space:capacity = 159383552 (152.0MB)used     = 0 (0.0MB)free     = 159383552 (152.0MB)0.0% used
tenured generation:capacity = 3187671040 (3040.0MB)used     = 3187671024 (3039.999984741211MB)free     = 16 (1.52587890625E-5MB)99.99999949806615% used36548 interned Strings occupying 3847648 bytes.
bash-4.4# 

两个很明显的表现

  • 老年代(tenured generation:)的使用率非常高,几乎达到了100%(99.99999949806615%),这表明老年代中的对象已经填满了。
  • 新生代(New Generation (Eden + 1 Survivor Space))的使用率也比较高,95.24790334422686% used

这个时候我们可以通过 watch 命令来持续监听命令的输出

bash-4.4# watch jmap -heap 1

问题分析

没有太多的内存供程序使用,我们需要从下面几个方向入手:

  • 找到 GC 频繁的原因,即内存爆炸增长的地方,想办法减少大对象的创建
  • 考虑 调整垃圾回收器的阈值
  • GC 优化,考虑选择合适的垃圾回收器

第一个原因需要从代码角度解决,在代码层面,减少内存使用,两个方法考虑:

  • 一个是纵向处理,即在对象本身上考虑,对大对象瘦身,减少不必要的组合对象(考虑建造者设计模式),或者本身。
  • 一个是横向处理,即在对象数量上考虑,减少对象创建的数量,比如考虑单例,原型 等设计模式。

第二个调整阈值,可以确定当前和阈值关系不大,修改 GC 频率太大会影响 正常线程的执行,当JVM 进行GC 是,会对当前执行的线程有一定的影响,具体和 JDK 版本 垃圾回收器都有一定的关系。

垃圾回收器进行GC时会暂停应用程序的所有线程(Stop-The-World),以便能够安全地回收不再使用的对象。这种暂停时间的长短取决于垃圾回收器的类型和堆内存的大小

以下是GC对线程的一些影响:

  1. 暂停时间:当GC进行时,所有线程都会暂停执行。这意味着应用程序的用户界面可能会冻结,或者长时间运行的任务可能会延迟完成。
  2. 线程优先级:在GC期间,JVM可能会调整线程的优先级,以确保垃圾回收器能够顺利运行。这可能会导致某些线程在GC期间执行的频率降低。
  3. 线程间通信:由于所有线程都被暂停,因此在GC期间线程间的通信可能会受到影响。这可能会导致某些同步操作失败或数据不一致。
  4. 资源利用:GC过程中,JVM会占用一部分CPU和内存资源来执行垃圾回收任务。这可能会导致应用程序的性能下降。

minor gc(新生代的垃圾回收) 是否会导致 stop the world ?

不管什么GC,都会发送stop the world,区别是发生的时间长短。而这个时间跟垃圾收集器又有关系,Serial、PartNew、Parallel Scavenge收集器无论是串行还是并行,都会挂起用户线程,而CMS和G1在并发标记时,是不会挂起用户线程,但其他时候一样会挂起用户线程,stop the world的时间相对来说小很多了。

问题解决

这里我们简单回顾下 JVM 垃圾回收算法类型及其优缺点,以及回收器

标记-清除算法(Mark-Sweep):标记直接清除

  • 优点:不需要移动对象,简单高效。
  • 缺点:标记-清除过程效率低,GC产生内存碎片。

复制算法(Copying):整体复制,需要额外的空间

  • 优点:简单高效,不会产生内存碎片。
  • 缺点:内存使用率低,且有可能产生频繁复制问题。

标记-整理算法(Mark-Compact):先标记,然后需要清理的和不需要清理的分组

  • 优点:综合了前两种算法的优点。
  • 缺点:仍需要移动局部对象。

分代收集算法(Generational Collection)

  • 优点:分区回收
  • 缺点: 对于长时间存活对象的场景回收效果不明显,甚至起到反作用。

常见回收器分类

回收器类型回收算法特点设置参数
Serial New/ Serial Old回收器复制算法/标记-整理算法单线程复制回收,简单高效,但会暂停程序导致停顿-XX:+UseSerialGC(年轻代、老年代回收器为:Serial New、Serial Old)
ParNew New/ ParNew Old回收器复制算法/标记-整理算法多线程复制回收,降低了停顿时间,但容易增加上下文切换-XX:+UseParNewGC(年轻代、老年代回收器为:ParNew New、Serial Old,JDK1.8中无效)
- XX:+UseParallelOldGC(年轻代、老年代回收器为:Parallel Scavenge、Parallel Old)
Parallel Scavenge回收器复制算法并行回收器,追求高吞吐量,高效利用CPU-XX:+UseParallelGC(年轻代、老年代回收器为:Parallel Scavenge、Serial Old)
- XX:ParallelGCThreads=4(设置并发线程)
CMS回收器标记-清理算法老年代回收器,高并发、低停顿,追求最短GC回收停顿时间,CPU占用比较高,响应时间快,停顿时间短-XX:+UseConcMarkSweepGC(年轻代、老年代回收器为:ParNew New、CMS(Serial Old作为备用))
G1回收器标记-整理+复制算法高并发、低停顿,可预测停顿时间-XX:+UseG1GC(年轻代、老年代回收器为:G1、G1)
- XX:MaxGCPauseMillis=200(设置最大暂停时间)
GC 优化

传统的 GC 优化一般为:

  • 减少 新生代 GC(Minor GC) 次数
  • 减少 老年代 GC(Full GC) 次数
  • 选择合适的垃圾回收器

前两种在实际的优化中需要不断的调整 新生代和老年代的堆内存配额,结合业务负载选择合适的阈值,稍微比较麻烦。

所以我们先从选择合适的垃圾回收器开始,当前使用的 Jdk1.8,通过上面的 heap 信息输出可以看到默认情况下使用的垃圾回收器为 Mark Sweep Compact GC,即我们经常讲的 CMS

CMS在 1.9 被标记为废弃,主要原因在于标记清除下的悬浮内存,导致内存空间碎片化,进而导致full GC的发生。full GC 往往消耗更多的时间。

考虑使用 1.9 后主推的G1,所以这里我们使用 G1 尝试

G1CMS的优势在于以下几点:

  1. 并行与并发:G1能够更充分利用多CPU、多核环境运行
  2. 分代收集:G1虽然也用了分代概念,但相比其他收集器需要配合不同收集协同工作,但G1收集器能够独立管理整个堆
  3. 空间管理:与CMS的标记一清理算法不同,G1从整体上基于标记一整理算法,将整个Java堆划分为多个大小相等的独立区域(Region),这种算法能够在运行过程中不产生内存碎片
  4. 可预测的停顿:降低停顿时间是G1和CMS共同目标,但是G1追求低停顿外,还能建立可预测的停顿时间模型,能让使用者明确指定一个长度为M毫秒的时间片段内,消耗在垃圾收集器上的时间不得超过N毫秒。

修改启动参数尝试 -Xms4024m -Xmx4024m -XX:+UseG1GC

做压力测试,可以看到 修改了 G1 回收器后,相同的压测线程数,JVisualVM 数据展示,老年代可以正常回收,即使频繁发生 full GC

可以看到相关对 上面的 CMS ,G1 在数据展示上多了最下面的 Histogram 区域:

Histogram: 对象年龄分布的直方图,显示了对象在不同年龄阶段的数量。

Parameters: 配置参数,包括:

  • Tenuring Threshold: 晋升阈值,当前值为1。
  • Max Tenuring Threshold: 最大晋升阈值,当前值为15。
  • Desired Survivor Size: 期望的幸存区大小,当前值为25165824。
  • Current Survivor Size: 当前幸存区大小,当前值为8。

我们在容器环境通过 jmap 查看 GC信息

bash-4.4# jmap -heap 1
Attaching to process ID 1, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.192-b12using thread-local object allocation.
Garbage-First (G1) GC with 8 thread(s)Heap Configuration:MinHeapFreeRatio         = 40MaxHeapFreeRatio         = 70MaxHeapSize              = 4223664128 (4028.0MB)NewSize                  = 1363144 (1.2999954223632812MB)MaxNewSize               = 2533359616 (2416.0MB)OldSize                  = 5452592 (5.1999969482421875MB)NewRatio                 = 2SurvivorRatio            = 8MetaspaceSize            = 21807104 (20.796875MB)CompressedClassSpaceSize = 1073741824 (1024.0MB)MaxMetaspaceSize         = 17592186044415 MBG1HeapRegionSize         = 1048576 (1.0MB)Heap Usage:
G1 Heap:regions  = 4028capacity = 4223664128 (4028.0MB)used     = 396765408 (378.3849792480469MB)free     = 3826898720 (3649.615020751953MB)9.39386740933582% used
G1 Young Generation:
Eden Space:regions  = 225capacity = 2652897280 (2530.0MB)used     = 235929600 (225.0MB)free     = 2416967680 (2305.0MB)8.893280632411066% used
Survivor Space:regions  = 7capacity = 7340032 (7.0MB)used     = 7340032 (7.0MB)free     = 0 (0.0MB)100.0% used
G1 Old Generation:regions  = 148capacity = 1563426816 (1491.0MB)used     = 153495776 (146.38497924804688MB)free     = 1409931040 (1344.6150207519531MB)9.81790605285358% used62301 interned Strings occupying 6150008 bytes.
bash-4.4# 

Garbage-First (G1) GC with 8 thread(s) 当前使用的垃圾回收算法,可以看到 GC 相关数据趋于平稳

代码层面优化

对应上面的第一个方向,即大内存对象的处理上,对下面的一些做了修改

横向处理:

  • 静态方法内调用 RestTemplate 实例发送请求,由每次 new 改成了单例
RestTemplate restTemplate = new RestTemplate();

修改为:

// 创建请求实体
RestTemplate restTemplate = SingletonFactoryRestTemple.getInstance();
=============
/***  RestTemplate 单例*/
public class SingletonFactoryRestTemple {private static RestTemplate instance;// 私有构造函数private SingletonFactoryRestTemple() {// 防止通过反射创建多个实例if (instance != null) {throw new RuntimeException("Use getInstance() method to get the single instance of this class.");}}// 静态公共方法,用于获取实例public static RestTemplate getInstance() {if (instance == null) {synchronized (SingletonFactoryRestTemple.class) {if (instance == null) {instance = new RestTemplate();}}}return instance;}
}
  • 在for循环内部存在每次创建对象解析模板创建改成了循环外创建一次,循环内重复使用

纵向处理

通过 jmap 对 head 内的对象内存使用直方图输出,可以看到用的最多的为 char[]String

^Cbash-4.4# jmap -histo:live 1 | head -20num     #instances         #bytes  class name
----------------------------------------------1:      23497860     1344485416  [C2:      23566026      565584624  java.lang.String3:       3274822      235787184  com.sun.xml.internal.messaging.saaj.soap.impl.ElementImpl4:       4080048      195842304  com.sun.org.apache.xerces.internal.dom.AttrNSImpl5:         13983      144511032  [I6:       2226796       90912544  [Ljava.lang.Object;7:       3283152       78795648  javax.xml.namespace.QName8:       3274976       78599424  com.sun.xml.internal.messaging.saaj.soap.impl.ElementImpl$AttributeManager9:       1776891       71075640  com.sun.xml.internal.messaging.saaj.soap.impl.TextImpl10:          9628       68625592  [B11:       2376607       57038568  com.sun.org.apache.xerces.internal.dom.AttributeMap12:       2213528       53124672  java.util.ArrayList13:         64656        5689728  java.lang.reflect.Method14:        135717        5428680  java.util.LinkedHashMap$Entry15:        194489        4667736  com.ruoyi.hotel.service.UserService.ArrayOfKeyValueOfanyTypeanyType.KeyValueOfanyTypeanyType16:        144083        4610656  java.util.concurrent.ConcurrentHashMap$Node17:        125953        4030496  java.util.HashMap$Node
bash-4.4# 
  • 所以对 String 类型的大的 HTTP 报文做了瘦身处理,对XML 复杂报文做了标签替换。

博文部分内容参考

© 文中涉及参考链接内容版权归原作者所有,如有侵权请告知 😃



© 2018-2024 liruilonger@gmail.com, 保持署名-非商用-相同方式共享(CC BY-NC-SA 4.0)

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/diannao/42627.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

语音识别FBank特征提取学习笔记

语音识别就是把一段语音信号转换成对应的文本信息&#xff0c;这一过程包括四个大的模块&#xff0c;分别是&#xff1a;特征提取、声学模型、语言模型、字典与解码。 本篇就来梳理一下特征提取模块的实现思路和方法。 常用的语音特征有&#xff1a; 梅尔频率倒谱系数&#x…

学生管理系统(通过顺序表,获取连续堆区空间实现)

将学生的信息&#xff0c;以顺序表的方式存储&#xff08;堆区&#xff09;&#xff0c;并且实现封装函数 &#xff1a; 1】顺序表的创建&#xff0c; 2】判满、 3】判空、 4】往顺序表里增加学生信息、 5】遍历学生信息 6】任意位置插入学生信息 7】任意位置删除学生信…

0301STM32GPIO外设输出

STM32GPIO外设输出 STM32内部的GPIO外设GPIO简介基本结构GPIO位结构输入部分&#xff1a;输出部分&#xff1a; GPIO八种工作模式浮空/上拉/下拉输入模拟输入开漏/推挽输出复用开漏/推挽输出 手册寄存器描述GPIO功能描述外设的GPIO配置GPIO寄存器描述端口输入数据寄存器端口输出…

QT入门笔记-自定义控件封装 30

具体代码如下: QT core guigreaterThan(QT_MAJOR_VERSION, 4): QT widgetsCONFIG c17# You can make your code fail to compile if it uses deprecated APIs. # In order to do so, uncomment the following line. #DEFINES QT_DISABLE_DEPRECATED_BEFORE0x060000 …

并查集(还有反集也在)

一.定义 定义&#xff1a; 并查集是一种树型的数据结构&#xff0c;用于处理一些不相交集合的合并及查询问题&#xff08;即所谓的并、查&#xff09;。比如说&#xff0c;我们可以用并查集来判断一个森林中有几棵树、某个节点是否属于某棵树等。 主要构成&#xff1a; 并查集…

Android计算器界面的设计——表格布局TableLayout实操

目录 任务目标任务分析任务实施 任务目标 使用TextView、Button等实现一个计算器界面&#xff0c;界面如图1所示。 图1 计算器界面效果图 任务分析 界面整体使用表格布局&#xff0c;第一行使用一个TextView控件&#xff0c;横跨4列&#xff0c;中间4行4列&#xff0c;最后一…

io流 多线程

目录 一、io流 1.什么是io流 2.流的方向 i.输入流 ii.输出流 3.操作文件的类型 i.字节流 1.拷贝 ii.字符流 ​3.字符流输出流出数据 4.字节流和字符流的使用场景 5.练习 6.缓冲流 1.字节缓冲流拷贝文件 2.字符缓冲流特有的方法 1.方法 2.总结 7.转换流基本用法…

第2集《修习止观坐禅法要》

请打开补充讲表第一面&#xff0c;附表一、念佛摄心方便法。 我们前面讲到修止&#xff0c;就是善取所缘境的相貌&#xff0c;然后心于所缘&#xff0c;专一安住&#xff1b;心于所缘&#xff0c;相续安住&#xff1b;达到心一境性的目的。 站在修学净土的角度&#xff0c;他…

《C语言》预处理

文章目录 一、预定义符号二、#define定义常量三、#define定义宏四、宏更函数的对比五、#和##1、#运算符2、##运算符 一、预定义符号 C语言设置了一些预定义符号&#xff0c;可以直接使用&#xff0c;在预处理期间进行处理的。 __FILE__//进行编译的源文件 __LINE__//文件当前的…

【数据结构与算法】插入排序

&#x1f493; 博客主页&#xff1a;倔强的石头的CSDN主页 &#x1f4dd;Gitee主页&#xff1a;倔强的石头的gitee主页 ⏩ 文章专栏&#xff1a;《数据结构与算法》 期待您的关注 ​

人工智能、机器学习、神经网络、深度学习和卷积神经网络的概念和关系

人工智能&#xff08;Artificial Intelligence&#xff0c;缩写为AI&#xff09;--又称为机器智能&#xff0c;是研究、开发用于模拟、延伸和扩展人的智能的理论、方法、技术及应用系统的一门新的技术科学。 人工智能是智能学科重要的组成部分&#xff0c;它企图了解智能的实质…

【问题解决】 pyocd 报错 No USB backend found 的解决方法

pyocd 报错 No USB backend found 的解决方法 本文记录了我在Windows 10系统上遇到的pyocd命令执行报错——No USB backend found 的分析过程和解决方法。遇到类似问题的朋友可以直接参考最后的解决方法&#xff0c;向了解问题发送原因的可以查看原因分析部分。 文章目录 pyoc…

排序-java(插入排序和选择排序)

一&#xff0c;分类 主要的排序大致分为以下几类&#xff1a; 1&#xff0c;插入排序&#xff0c;又分为直接插入排序和希尔排序 2&#xff0c;选择排序&#xff0c;又分为选择排序和堆排序 3&#xff0c;交换排序&#xff0c;又分为冒泡排序和快速排序 4&#xff0c;归并…

springboot配置扫描生效顺序

文章目录 举例分析项目结构如下noddles-user-backend 两个配置文件noddles-user-job 配置文件noddles-user-server 配置文件问题:server和Job启动时对应加载的数据库配置为哪一个&#xff1f; 总结 在微服务架构中&#xff0c;backend模块会定义一个基础的配置文件&#xff0c;…

Report Design Analysis报告之logic level详解

目录 一、前言 二、Logic Level distribution 2.1 logic level配置 2.2 Logic Level Distribution报告 2.3 Logic Level 报告详情查看 2.4 Route Distributions 报告详情查看 2.5 示例代码 一、前言 ​在工程设计中&#xff0c;如果需要了解路径的逻辑级数&#xff0c;可…

卷积神经网络基础篇

文章目录 1、卷积层1.1、激活函数1.3、sigmoid1.4、Tanh1.5、ReLU1.6、Leaky ReLU1.7、误差计算 2、池化层3、全连接层4、CNN训练 参考链接1 参考链接2 1、卷积层 卷积层&#xff08;Convolutional layer&#xff09;&#xff0c;这一层就是卷积神经网络最重要的一个层次&…

动手学深度学习(Pytorch版)代码实践 -循环神经网络- 56门控循环单元(`GRU`)

56门控循环单元&#xff08;GRU&#xff09; 我们讨论了如何在循环神经网络中计算梯度&#xff0c; 以及矩阵连续乘积可以导致梯度消失或梯度爆炸的问题。 下面我们简单思考一下这种梯度异常在实践中的意义&#xff1a; 我们可能会遇到这样的情况&#xff1a;早期观测值对预测…

机器人动力学模型及其线性化阻抗控制模型

机器人动力学模型 机器人动力学模型描述了机器人的运动与所受力和力矩之间的关系。这个模型考虑了机器人的质量、惯性、关节摩擦、重力等多种因素&#xff0c;用于预测和解释机器人在给定输入下的动态行为。动力学模型是设计机器人控制器的基础&#xff0c;它可以帮助我们理解…

2024/7/7周报

文章目录 摘要Abstract文献阅读题目问题本文贡献问题描述图神经网络Framework实验数据集实验结果 深度学习MAGNN模型相关代码GNN为什么要用GNN&#xff1f;GNN面临挑战 总结 摘要 本周阅读了一篇用于多变量时间序列预测的多尺度自适应图神经网络的文章&#xff0c;多变量时间序…

SAP已下发EWM的交货单修改下发状态

此种情况针对EWM未接收到ERP交货单时&#xff0c;可以使用此程序将ERP交货单调整为未分配状态&#xff0c;在进行调整数据后&#xff0c;然后使用VL06I&#xff08;启用自动下发EWM配置&#xff0c;则在交货单修改保存后会立即下发EWM&#xff09;重新下发EWM系统。 操作步骤如…