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.rhkb.cn/news/371329.html

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

相关文章

Appium adb 获取appActivity

方法一&#xff08;最简单有效的方法&#xff09; 通过cmd命令&#xff0c;前提是先打开手机中你要获取包名的APP adb devices -l 获取连接设备详细信息 adb shell dumpsys activity | grep mFocusedActivity 有时获取到的不是真实的Activity 方法二 adb shell monkey -p …

从0-1实现一个前端脚手架

https://gitee.com/childe-jia/kfc-cli.git gitee完整地址 介绍 为什么需要脚手架&#xff1f; 脚手架本质就是一个工具&#xff0c;作用是能够让使用者专注于写代码&#xff0c;它可以让我们只用一个命令就生成一个已经配置好的项目&#xff0c;而不用我们再花时间去配置和安…

【排序算法】—— 快速排序

快速排序的原理是交换排序&#xff0c;其中qsort函数用的排序原理就是快速排序&#xff0c;它是一种效率较高的不稳定函数&#xff0c;时间复杂度为O(N*longN)&#xff0c;接下来就来学习一下快速排序。 一、快速排序思路 1.整体思路 以升序排序为例&#xff1a; (1)、首先随…

CC工具箱使用指南:【相交占比分析】

一、简介 需求场景如下&#xff0c;有【待分析地块】和【面积占比参考】2个图层。2个图层之间存在空间上的重叠。工具的目的是为了分析出【待分析地块】的每1个图斑中&#xff0c;和【面积占比参考】相交的面积&#xff0c;以及和总面积的占比。 举一个应用场景为例&#xff0…

Idea新增Module报错:sdk ‘1.8‘ type ‘JavaSDK‘ is not registered in ProjectJdkTable

文章目录 一&#xff0c;创建Module报错二&#xff0c;原因分析三&#xff0c;解决方案1&#xff0c;点击上图的加号&#xff0c;把JDK8添加进来即可2&#xff0c;点击左侧[Project]&#xff0c;直接设置SDK为JDK8 四&#xff0c;配置检查与验证 一&#xff0c;创建Module报错 …

【Linux】:程序地址空间

朋友们、伙计们&#xff0c;我们又见面了&#xff0c;本期来给大家解读一下有关Linux程序地址空间的相关知识点&#xff0c;如果看完之后对你有一定的启发&#xff0c;那么请留下你的三连&#xff0c;祝大家心想事成&#xff01; C 语 言 专 栏&#xff1a;C语言&#xff1a;从…

PingCAP 成为全球数据库管理系统市场增速最快的厂商

近日&#xff0c;Gartner 发布的《Market Share Analysis: Database Management Systems, Worldwide, 2023》&#xff08;2024 年 6 月&#xff09;报告显示&#xff1a;“2023 年全球数据库管理系统&#xff08;DBMS&#xff09;市场的增长率为 13.4%&#xff0c;略低于去年的…

LLM4Decompile——专门用于反编译的大规模语言模型

概述 论文地址&#xff1a;https://arxiv.org/abs/2403.05286 反编译是一种将已编译的机器语言或字节码转换回原始高级编程语言的技术。该技术用于分析软件的内部工作原理&#xff0c;尤其是在没有源代码的情况下&#xff1b;Ghidra 和 IDA Pro 等专用工具已经开发出来&#…

学习笔记——动态路由——OSPF聚合(汇总)

十一、OSPF聚合(汇总) 1、路由聚合(汇总) 路由汇总是一种重要的思想&#xff0c;在大型的项目中是必须考虑的一个重点事项。随着网络的规模越来越大&#xff0c;网络中的设备所需维护的路由表项也就会越来越多&#xff0c;路由表的规模也就会逐渐变大&#xff0c;而路由表是需…

【TB作品】51单片机 Proteus仿真 超声波LCD1602ADC0832 身高体重测量仪

00024 超声波LCD1602ADC0832 实验报告&#xff1a;基于51单片机的身高体重测量仪设计 背景介绍 本实验设计并实现了一个基于51单片机的身高体重测量仪。该系统利用超声波传感器测量高度&#xff0c;通过ADC0832模数转换芯片获取重量数据&#xff0c;并使用LCD1602显示屏显示…

系统测试-测试方法学习

目录 &#xff08;1&#xff09;等价类 &#xff08;2&#xff09;边界值 &#xff08;3&#xff09;正交&#xff1a;&#xff08;只用于确定排列组合&#xff0c;不确定具体内容&#xff09; (4)判定表法 &#xff08;5&#xff09;流程分析法 &#xff08;6&#xff0…

Day05-04-持续集成总结

Day05-04-持续集成总结 1. 持续集成2. 代码上线目标项目 1. 持续集成 git 基本使用, 拉取代码,上传代码,分支操作,tag标签 gitlab 用户 用户组 项目 , 备份,https,优化. jenkins 工具平台,运维核心, 自由风格工程,maven风格项目,流水线项目, 流水线(pipeline) mavenpom.xmlta…

uni-app使用ucharts地图,自定义Tooltip鼠标悬浮显示内容并且根据@getIndex点击事件获取点击的地区下标和地区名

项目场景&#xff1a; uni-app使用ucharts地图,自定义Tooltip鼠标悬浮显示内容并且根据getIndex点击事件获取点击的地区下标和地区名 例如&#xff1a; 问题描述 官方给的文档有限&#xff0c;需要自己下载地图json数据然后自己渲染和编写鼠标悬浮显示内容以及获取点击地址…

在DevEco运行typeScript代码,全网详细解决执行Set-ExecutionPolicy RemoteSigned报出的错

目录 基本思路 网络推荐 本人实践 如下操作,报错: 基本思路 //在DevEco运行typeScript代码 /** * 1.保证node -v出现版本,若没有,配置环境变量(此电脑-属性-高级系统变量配置-path-粘贴路径);DevEco在local.properties中可看到当前nodejs的路径 * 2.npm install …

【Transformer】transformer模型结构学习笔记

文章目录 1. transformer架构2. transformer子层解析3. transformer注意力机制4. transformer部分释疑 图1 transformer模型架构 图2 transformer主要模块简介 图3 encoder-decoder示意图N6 图4 encoder-decoder子层示意图 1. transformer架构 encoder-decoder框架是一种处理NL…

strcpy,srtcmp,strlen函数漏洞利用

strcpy,srtcmp,strlen函数漏洞利用 strcpy strcpy函数用于将字符串复制到另一个指针指向的空间中&#xff0c;遇到空字符 **b’x\00’**时停止&#xff0c;&#xff1a; 所以可以利用 strcpy不检查缓冲区 的漏洞&#xff08;构造的字符串要以\0结尾&#xff09;&#xff0c;…

Android平台崩溃和 ANR 问题进行符号化解析、解析崩溃日志的内存地址

使用Android Logcat Stacktrace Utility | Android Logcat | 1.2.3 1.设置so库路径 2.打开Stacktrace Utility工具 3.在Original粘贴报错内存地址 4.点击Resolve Stacktraces,就会解析出内存地址 如果是红色,解析失败了,缺少原生so库,可以在第一步添加so库文件再次尝试…

freemarker生成pdf,同时pdf插入页脚,以及数据量大时批量处理

最近公司有个需求&#xff0c;就是想根据一个模板生成一个pdf文档&#xff0c;当即我就想到了freemarker这个远古老东西&#xff0c;毕竟freemarker在模板渲染方面还是非常有优势的。 准备依赖&#xff1a; <dependency><groupId>org.springframework.boot</gr…

【植物大战僵尸杂交版】获取+存档插件

文章目录 一、还记得《植物大战僵尸》吗&#xff1f;二、在哪下载&#xff0c;怎么安装&#xff1f;三、杂交版如何进行存档功能概述 一、还记得《植物大战僵尸》吗&#xff1f; 最近&#xff0c;一款曾经在15年前风靡一时的经典游戏《植物大战僵尸》似乎迎来了它的"文艺复…

EN-SLAM:Implicit Event-RGBD Neural SLAM解读

论文路径&#xff1a;https://arxiv.org/pdf/2311.11013.pdf 目录 1 论文背景 2 论文概述 2.1 神经辐射场&#xff08;NeRF&#xff09; 2.2 事件相机&#xff08;Event Camera&#xff09; 2.3 事件时间聚合优化策略&#xff08;ETA&#xff09; 2.4 可微分的CRF渲染技术…