老年代一直增大，系統巨慢，內存泄漏

問題

線上系統接口響應很慢，完全不正常，有些接口長達2分多鐘，甚至直接一直處理pending狀態，之前做了SQL監控和優化，SQL查詢和插入一般控制在了3S之內。

環境

k8s java1.8 spring cloud 持久層 JPA+H

過程

由于線上系統跑在K8S POD里，里面的jar啟動就是1號進程
jstat 等一些工具無法attach1號進程，就只能用arthas了

dashboard 看看GC情況

copy 垃圾回收是針對新生代的，看到回收了217次. 時間50S
marksweepcompact 是針對老年代的回到10次 20S
這個是jar啟動4小時之后的統計

vmoption 可以臨時設置JVM開啟GC 默認日志是 JAVA日志在那兒顯示，GC就顯示在那兒

GPT說什么時候發生fullgc

Full GC（Full Garbage Collection）通常在以下情況下發生：

新生代空間不足：當新生代的Eden區域已經被占滿，且無法容納新的對象時，會觸發一次Full GC。這是因為新生代的對象在經過多次垃圾回收后仍然存活，需要被轉移到老年代中。

永久代/元空間空間不足：對于使用永久代（PermGen）或元空間（Metaspace）的Java版本，在永久代/元空間空間不足時，也可能觸發Full GC。永久代/元空間主要用于存放類的元數據、靜態變量等。

顯式調用System.gc()：當應用程序顯式調用System.gc()方法來請求進行垃圾回收時，可能會觸發Full GC。但調用System.gc()并不能保證立即進行Full GC，具體是否進行Full GC由JVM決定。

空間分配擔保失敗：在進行Minor GC（新生代垃圾回收）時，如果老年代的剩余空間不足以容納新生代中所有存活的對象，就會觸發Full GC。這種情況下，JVM會進行一次Full GC，以確保所有存活的對象都能被轉移到老年代中。

長時間存活的對象：當老年代中的對象存活時間很長時，也可能會觸發Full GC。這是因為老年代主要用于存放存活時間較長的對象，當老年代空間不足時，需要進行Full GC來回收無用的對象。

需要注意的是，并不是每次Full GC都是由以上情況引起的，具體觸發Full GC的條件和策略會根據不同的垃圾收集器、JVM參數和應用程序的特點而有所不同。因此，在實際情況中，可以通過查看GC日志和使用監控工具來了解何時發生Full GC以及如何優化和調整應用程序的垃圾收集行為。

jmap -heap 進程看看內存情況

可以看到metespace 只有20M 很明顯metespace擴容會引起fullGC.
這里要說一下，雖然此處看到的是20M，但通過arthas的dashboard指令看到的metaspace卻是160M,很明顯，他自己擴容過了。。

加啟動參數,限制擴容大小

-XX:MetaspaceSize=512m
-XX:MaxMetaspaceSize=512m

加了參數還是不能解決可以看看這個文章
https://zhuanlan.zhihu.com/p/537924677
這個文章大致的意思是說使用查看類加載的指令，看看哪些類加載的比較多.

用到的指令

jcmd PID GC.run
這個指令比較有意思，可以直接上生產環境測試下fullgc 消耗的時間.. 反正卡都卡了，線上試試也不是不行
jmap -histo:live pid > 2.txt
這個可以導出當前存活的對象的數量
jmap -heap pid 查看堆內存情況
pmap -x pid |grep 這兒可以寫要查看的內存大小
jcmd pid GC.heap_info 可以查看metaspace占用情況

jmap -dump:file=/path pid
導出堆內存
pmap -x 1 | sort -n -k 2 排序看看最大的內存塊
apt-get install binutils 二進制文件處理工具包主要用到里面的strings 用于查看gdb導出的內存塊中的字符串
strings -10 x.dump 查看x.dump這個內存塊中字符串長度超過10個的

然后，通過配置jvm啟動參數，觀察類的加載和卸載目前是看看哪些類加載的比較多.
-XX:+TraceClassLoading -XX:+TraceClassUnloading

寫到這兒，上面的參數和說法我還沒加GC日志驗證，明天加了GC日志，再來更新

又看了下，res漲到6G了

紅線上面的堆區下面的是非堆區，很明顯堆內存占用巨大，基本可以排除非堆的問題

堆外內存泄漏（上圖反應出來的情況，并不是堆外內存泄漏）

最初是懷疑，堆外內存泄漏導致的內存上漲，想用tcmall 進行堆外內存跟蹤但k8s內的docker pod 死活也裝不了這些東西，查了資料發現tcmall什么的內存泄漏跟蹤工具，都是
利用linux 自己的攔截進程加載的SO的辦法，攔截了進程中的malloc內存分配函數,這個東西可以參考 LD_PRELOAD,
自己寫個SO攔截了malloc函數后，再繼續使用Libunwind這個庫,輸出進程調用你自己寫的攔截SO時的整個調用堆棧，最終實現，調用鏈的記錄。

又發現新情況用 pmap -x pid|grep 65404 出來的64M的塊共106行也就是106個算下來6.7G 和上面的6G占用差不多...

開啟GC日志后，重啟服務

截個圖

top -Hp pid

此處res 1.6g

看看堆內存的情況
arthas 的 memory指令

堆和非堆加起來1.4G 和1.6G差不多

2小時候GC日志分析

先總結
日志中很多由于堆內存不足導致頻繁的年輕代GC和老年代GC，以及由于metaspace不足導致的full gc，兩小時內發生了5次full GC。
而且由于老年代的對象特別多，導致GC時和full GC時花了很長時間，所以需要解決的問題有幾個：
調整年輕代和老年代的堆大小，減少GC次數
解決老年代為什么存儲了這么多對象的問題,而且是不斷上漲(占用越多，GC越耗時)

日志片段

老年代引發的GC

972.907: [GC (Allocation Failure) 5972.907: [DefNew: 331445K->3239K(350912K), 0.3575620 secs]5973.265: [Tenured: 861540K->548505K(861572K), 3.1592128 secs] 1107544K->548505K(1212484K), [Metaspace: 184994K->184994K(1222656K)], 3.5182106 secs] [Times: user=2.65 sys=0.87, real=3.52 secs]

metaspace引發fullgc(兩小時內引發了5次full gc)
342.710: [Full GC (Metadata GC Threshold) 342.711: [Tenured: 237537K->255779K(681344K), 2.0443248 secs] 257931K->255779K(988032K), [Metaspace: 155254K->155254K(1193984K)], 2.0450780 secs] [Times: user=1.78 sys=0.39, real=2.05 secs]
可以看到此時老年代Tenured 空間足夠，但由于metaspace引發了full gc 所以老年代也跟著GC了，耗時2S
Metaspace 回收前155254K回收后還是155254K 但空間不夠，所以引發了擴容metaspace增加到了1193984K,耗時2S

為什么回收后還是155254K?這證明Metaspace中的對象還被其他地方持有引用，導致GC時，無法清除這些對象，所以自動擴容

GC (Allocation Failure) 是堆內存不足引發的GC ?到底是哪個堆呢？日志給出了說明
可以看到年輕代DefNew 容量 350912K 實際只用了 331445K 這不足以引發GC
再看老年代 Tenured 容量 861572K 實際用了 861540K 很明顯，這次GC是由于老年代不夠了引發的GC，而且時間3s...
Metaspace 就不說了，此時空間還夠。。

來揪出幕后黑手

導出堆內存

發現這兒玩意兒占了2.1g內存.
餅圖最大塊就是他，右鍵list objects -> with outgoing ref... 看看他到底泄漏了什么

進去記得先排序，把他持有的對象最多的排在前面

繼續根據最多的跟進去，找到熟悉的內容很多SQL。。。如果是很多SQL的話，那且不是加載了很多char[] 或者String對象？

回到預覽界面，我們看看加載的對象情況，記得排序

排序后根據這個順序似乎看的出從上到下是個引用鏈，最西面是String String下面當然是char[]了
看看String的內容

排序后大量的業務SQL句子....

隨便找個String
list objects -> with incoming ref 看看是誰再引用他

由此可見到最終還是到了這個對象身上.

如何優化

本質問題，內存泄漏且這些對象被引用導致老年大越來越大，一但GC就回很卡。。
1、調整hb的queryPlanCahe緩存相關的設置

  jpa:
    hibernate:
      plan_cache_max_size: 64
      plan_parameter_metadata_max_size: 32
      query.in_clause_parameter_padding: true

上面的配置好像沒什么效果，最后直接關閉了hibernate所有的緩存功能,關閉后沒有明顯的性能下降

 plan_cache_max_size: 64
      plan_parameter_metadata_max_size: 32
      query.in_clause_parameter_padding: true
      #關閉二級緩存
      cache.use_second_level_cache: false
      #關閉查詢緩存
      cache.use_query_cache: false

一些別人解決的摘錄

大概的意思就是，QueryPlanCache會緩存sql，以便于后邊的相同的sql重復編譯，如果in后的參數不同，hibernate會把其當成不同的sql進行緩存，從而緩存大量的sql導致heap內存溢出。我的程序中沒有使用in，但通過查看程序，我發現我的一條hql中同時采用paramter string拼接和占位符兩種方式,這樣會不會因為每一個paramter string都不同，hibernate認為這是不同的hql從而進行大量緩存喃？于是我全部采用站位符的方式，再進行測試，發現程序heap內存一直處于穩定狀態，問題解決。

2、將新生代串行收集器改為并行收集器

-XX:NewSize=1024m     新生代 1G應該夠了
-XX:MetaspaceSize=512m 這個可能有點小。。下次重啟配大點
-XX:PermSize=2048m  這個參數在JDK1.8上沒卵用。。。老年代會自己擴容..
-XX:+UseParNewGC  新生代啟用并行收集器

解決內存泄漏且優化GC后的效果，除了matespace空間不足會擴容，雖然耗時最長的3S，但此時不會導致fullGC ，問題不大,觀察幾天看看.

由于效果不是很明顯，最后換成了G1收集器

-XX:InitialHeapSize=4096m","-XX:MaxHeapSize=4096m","-XX:MetaspaceSize=1024m","-XX:MaxMetaspaceSize=1024m","-XX:+UseG1GC","-XX:MaxGCPauseMillis=100","-XX:ParallelGCThreads=5"

坑點

網上很多jvm的工具指令的參數，對你自己的環境來說不一定用的了
如果使用某個指令參數報錯最好看下這個指令的Help

優化前全部日志

OpenJDK 64-Bit Server VM (25.312-b07) for linux-amd64 JRE (1.8.0_312-b07), built on Oct 15 2021 05:40:24 by "openjdk" with gcc 4.4.7 20120313 (Red Hat 4.4.7-23)
Memory: 4k page, physical 65293096k(65291512k free), swap 0k(0k free)
CommandLine flags: -XX:InitialHeapSize=1044689536 -XX:MaxHeapSize=16715032576 -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseCompressedClassPointers -XX:+UseCompressedOops 
2.828: [GC (Allocation Failure) 2.829: [DefNew: 272512K->4386K(306560K), 0.0451689 secs] 272512K->4386K(987904K), 0.0453887 secs] [Times: user=0.04 sys=0.02, real=0.05 secs] 
3.800: [GC (Allocation Failure) 3.800: [DefNew: 276898K->6271K(306560K), 0.0528579 secs] 276898K->6271K(987904K), 0.0531354 secs] [Times: user=0.06 sys=0.01, real=0.06 secs] 
4.434: [Full GC (Metadata GC Threshold) 4.434: [Tenured: 0K->8215K(681344K), 0.1028772 secs] 198736K->8215K(987904K), [Metaspace: 20241K->20241K(1069056K)], 0.1030639 secs] [Times: user=0.11 sys=0.01, real=0.10 secs] 
6.384: [GC (Allocation Failure) 6.385: [DefNew: 272640K->2140K(306688K), 0.0142882 secs] 280855K->10356K(988032K), 0.0144099 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 
7.626: [GC (Allocation Failure) 7.626: [DefNew: 274780K->2421K(306688K), 0.0109280 secs] 282996K->10636K(988032K), 0.0110222 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 
8.309: [GC (Allocation Failure) 8.309: [DefNew: 275061K->3368K(306688K), 0.0128557 secs] 283276K->11583K(988032K), 0.0129517 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 
8.812: [Full GC (Metadata GC Threshold) 8.812: [Tenured: 8215K->12002K(681344K), 0.1228985 secs] 217495K->12002K(988032K), [Metaspace: 34090K->34090K(1081344K)], 0.1230888 secs] [Times: user=0.11 sys=0.00, real=0.13 secs] 
10.691: [GC (Allocation Failure) 10.692: [DefNew: 272640K->3882K(306688K), 0.0428921 secs] 284642K->15885K(988032K), 0.0431057 secs] [Times: user=0.03 sys=0.01, real=0.05 secs] 
11.742: [GC (Allocation Failure) 11.742: [DefNew: 276522K->9656K(306688K), 0.0804945 secs] 288525K->21659K(988032K), 0.0806765 secs] [Times: user=0.07 sys=0.01, real=0.08 secs] 

18.093: [GC (Allocation Failure) 18.093: [DefNew: 289623K->19295K(306688K), 0.0474664 secs] 301626K->31298K(988032K), 0.0476189 secs] [Times: user=0.04 sys=0.00, real=0.04 secs] 
18.845: [Full GC (Metadata GC Threshold) 18.845: [Tenured: 12002K->31933K(681344K), 0.3761287 secs] 94851K->31933K(988032K), [Metaspace: 56790K->56790K(1101824K)], 0.3763483 secs] [Times: user=0.36 sys=0.04, real=0.37 secs] 
21.706: [GC (Allocation Failure) 21.706: [DefNew: 272640K->5904K(306688K), 0.0700657 secs] 304573K->37837K(988032K), 0.0703041 secs] [Times: user=0.07 sys=0.00, real=0.07 secs] 
23.746: [GC (Allocation Failure) 23.746: [DefNew: 278544K->11313K(306688K), 0.0444317 secs] 310477K->43246K(988032K), 0.0446261 secs] [Times: user=0.04 sys=0.00, real=0.04 secs] 
24.885: [GC (Allocation Failure) 24.885: [DefNew: 283953K->15012K(306688K), 0.0605599 secs] 315886K->46945K(988032K), 0.0606853 secs] [Times: user=0.06 sys=0.01, real=0.06 secs] 
26.501: [GC (Allocation Failure) 26.501: [DefNew: 287652K->20286K(306688K), 0.0732979 secs] 319585K->52219K(988032K), 0.0734128 secs] [Times: user=0.07 sys=0.00, real=0.08 secs] 
27.719: [GC (Allocation Failure) 27.719: [DefNew: 292926K->16069K(306688K), 0.0952460 secs] 324859K->53436K(988032K), 0.0954281 secs] [Times: user=0.08 sys=0.02, real=0.10 secs] 
29.144: [GC (Allocation Failure) 29.144: [DefNew: 288709K->20125K(306688K), 0.1084914 secs] 326076K->57492K(988032K), 0.1087023 secs] [Times: user=0.10 sys=0.01, real=0.11 secs] 
30.717: [Full GC (Metadata GC Threshold) 30.717: [Tenured: 37367K->52962K(681344K), 0.4952737 secs] 291288K->52962K(988032K), [Metaspace: 94109K->94109K(1134592K)], 0.4954589 secs] [Times: user=0.82 sys=0.05, real=0.50 secs] 


1257.478: [GC (Allocation Failure) 1257.478: [DefNew: 242316K->29707K(306816K), 0.5356358 secs]1258.014: [Tenured: 718311K->467689K(819452K), 2.6721233 secs] 822522K->467689K(1126268K), [Metaspace: 176951K->176951K(1214464K)], 3.2086182 secs] [Times: user=2.47 sys=0.74, real=3.21 secs] 
1261.062: [GC (Allocation Failure) 1261.062: [DefNew: 311936K->2894K(350912K), 0.2643887 secs] 779625K->608689K(1130396K), 0.2648144 secs] [Times: user=0.21 sys=0.14, real=0.27 secs] 
1261.455: [GC (Allocation Failure) 1261.455: [DefNew: 314830K->2947K(350912K), 0.0362270 secs] 920625K->608742K(1130396K), 0.0364520 secs] [Times: user=0.05 sys=0.02, real=0.03 secs] 

1329.071: [GC (Allocation Failure) 1329.072: [DefNew: 314469K->6847K(350912K), 0.1146619 secs] 920264K->612642K(1130396K), 0.1154181 secs] [Times: user=0.08 sys=0.04, real=0.12 secs] 
1367.587: [GC (Allocation Failure) 1367.587: [DefNew: 318783K->4626K(350912K), 0.0374704 secs] 924578K->610422K(1130396K), 0.0381221 secs] [Times: user=0.06 sys=0.02, real=0.04 secs] 
1473.660: [GC (Allocation Failure) 1473.660: [DefNew: 316562K->5726K(350912K), 0.0831708 secs] 922358K->611521K(1130396K), 0.0836858 secs] [Times: user=0.05 sys=0.03, real=0.09 secs] 
1532.514: [GC (Allocation Failure) 1532.514: [DefNew: 317662K->12979K(350912K), 0.1717818 secs] 923457K->618775K(1130396K), 0.1726229 secs] [Times: user=0.10 sys=0.07, real=0.17 secs] 

3157.846: [GC (Allocation Failure) 3157.846: [DefNew: 333913K->14056K(350912K), 0.2155066 secs]3158.062: [Tenured: 785563K->378616K(785572K), 2.0365184 secs] 1108373K->378616K(1136484K), [Metaspace: 182004K->182004K(1218560K)], 2.2558829 secs] [Times: user=1.76 sys=0.50, real=2.25 secs] 




5972.907: [GC (Allocation Failure) 5972.907: [DefNew: 331445K->3239K(350912K), 0.3575620 secs]5973.265: [Tenured: 861540K->548505K(861572K), 3.1592128 secs] 1107544K->548505K(1212484K), [Metaspace: 184994K->184994K(1222656K)], 3.5182106 secs] [Times: user=2.65 sys=0.87, real=3.52 secs] 
5977.912: [GC (Allocation Failure) 5977.912: [DefNew: 365888K->633K(411584K), 0.0714753 secs] 914393K->618230K(1325764K), 0.0717480 secs] [Times: user=0.05 sys=0.02, real=0.08 secs] 

5987.640: [GC (Allocation Failure) 5987.640: [DefNew: 368819K->4224K(411584K), 0.0472467 secs] 1262776K->898181K(1325764K), 0.0476013 secs] [Times: user=0.04 sys=0.01, real=0.05 secs] 
5988.796: [GC (Allocation Failure) 5988.796: [DefNew: 370112K->4856K(411584K), 0.1383424 secs]5988.934: [Tenured: 963046K->553136K(983272K), 1.8268052 secs] 1264069K->553136K(1394856K), [Metaspace: 185005K->185005K(1222656K)], 1.9710281 secs] [Times: user=1.54 sys=0.43, real=1.97 secs] 
5992.154: [GC (Allocation Failure) 5992.154: [DefNew: 368960K->662K(415040K), 0.0680225 secs] 922096K->622888K(1336936K), 0.0683050 secs] [Times: user=0.05 sys=0.01, real=0.06 secs] 
5993.121: [GC (Allocation Failure) 5993.121: [DefNew: 369622K->799K(415040K), 0.0690239 secs] 991848K->692116K(1336936K), 0.0692696 secs] [Times: user=0.04 sys=0.02, real=0.07 secs] 
5994.520: [GC (Allocation Failure) 5994.520: [DefNew: 369759K->5217K(415040K), 0.0838226 secs] 1061076K->765624K(1336936K), 0.0840447 secs] [Times: user=0.06 sys=0.02, real=0.09 secs] 
5996.017: [GC (Allocation Failure) 5996.017: [DefNew: 374177K->9746K(415040K), 0.0879409 secs] 1134584K->839242K(1336936K), 0.0881429 secs] [Times: user=0.06 sys=0.02, real=0.09 secs] 
5999.217: [GC (Allocation Failure) 5999.218: [DefNew: 378706K->10227K(415040K), 0.1710344 secs] 1208202K->908814K(1336936K), 0.1714577 secs] [Times: user=0.11 sys=0.05, real=0.17 secs] 
6002.421: [GC (Allocation Failure) 6002.421: [DefNew: 322546K->10714K(415040K), 0.0816380 secs] 1221133K->909300K(1336936K), 0.0821488 secs] [Times: user=0.06 sys=0.02, real=0.09 secs] 
6003.099: [GC (Allocation Failure) 6003.099: [DefNew: 379674K->11385K(415040K), 0.2083919 secs]6003.308: [Tenured: 967676K->564245K(990988K), 2.1042674 secs] 1278260K->564245K(1406028K), [Metaspace: 185018K->185018K(1222656K)], 2.3169234 secs] [Times: user=1.92 sys=0.40, real=2.32 secs] 
6007.577: [GC (Allocation Failure) 6007.578: [DefNew: 376320K->2193K(423360K), 0.1099151 secs] 940565K->635529K(1363772K), 0.1101776 secs] [Times: user=0.05 sys=0.06, real=0.11 secs] 

6014.209: [GC (GCLocker Initiated GC) 6014.209: [DefNew: 381118K->5451K(423360K), 0.0785015 secs] 1152634K->846057K(1363772K), 0.0787623 secs] [Times: user=0.05 sys=0.03, real=0.08 secs] 
6014.736: [GC (Allocation Failure) 6014.736: [DefNew: 381771K->6281K(423360K), 0.0715430 secs] 1222377K->915977K(1363772K), 0.0717758 secs] [Times: user=0.05 sys=0.02, real=0.07 secs] 
6014.918: [GC (Allocation Failure) 6014.918: [DefNew: 382601K->6293K(423360K), 0.0177022 secs] 1292297K->915989K(1363772K), 0.0178470 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] 

6016.417: [GC (Allocation Failure) 6016.417: [DefNew: 381527K->4686K(423360K), 0.0162314 secs] 1294566K->918412K(1363772K), 0.0164098 secs] [Times: user=0.01 sys=0.00, real=0.02 secs] 
6016.543: [GC (Allocation Failure) 6016.543: [DefNew: 381006K->4546K(423360K), 0.0150262 secs] 1294732K->918321K(1363772K), 0.0151928 secs] [Times: user=0.02 sys=0.00, real=0.01 secs] 
6018.243: [GC (Allocation Failure) 6018.243: [DefNew: 365758K->6625K(423360K), 0.0193289 secs] 1279533K->920785K(1363772K), 0.0195451 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] 
6018.406: [GC (Allocation Failure) 6018.407: [DefNew: 382945K->6153K(423360K), 0.0771226 secs]6018.484: [Tenured: 983791K->572329K(1009504K), 1.1978621 secs] 1297105K->572329K(1432864K), [Metaspace: 185178K->185178K(1222656K)], 1.2794009 secs] [Times: user=1.22 sys=0.06, real=1.28 secs] 
6019.811: [GC (Allocation Failure) 6019.811: [DefNew: 381760K->29K(429440K), 0.0100063 secs] 954089K->572359K(1383324K), 0.0101268 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]

保留一下如果堆內存和元空間正常就得去看看這兒寫的東西了。。

https://www.tulingxueyuan.cn/tlzx/jsp/3940.html
https://blog.csdn.net/weixin_45583158/article/details/100143231

如何使用jemalloc跟蹤堆外內存泄漏
http://www.rzrgm.cn/cfas/p/17896371.html
如何使用gdb dump 指令導出JVM native內存
https://www.jianshu.com/p/1083bd433df1

參考

覺的是堆外內存泄漏可以使用GDB手動釋放一下JVM持有的堆外內存(和元空間沒有關系)
https://article.juejin.cn/post/7255634554987020343
native 原生內存泄漏如何追蹤
https://zhuanlan.zhihu.com/p/652545321
https://cloud.tencent.com/developer/article/2002967 這個老師傅寫的不錯
MAT工具的使用和如何查看老年代old gen 的對象是哪些（推薦，非常不錯）
http://www.rzrgm.cn/shangxiaofei/articles/16875215.html
JVM啟動參數大全
http://www.rzrgm.cn/jinghu/p/10892842.html
spring 項目排查內存泄露，老年代內存不斷增長，分區占100%
https://blog.csdn.net/qq_27413937/article/details/122692346
GC優化--老年代使用率過高、Full GC之后老年代使用率仍大于60%、log4j2導致內存泄露等問題排查
https://juejin.cn/post/6856404081830068232
GC原理介紹、排查FGC及線上故障的步驟全套路
http://www.taodudu.cc/news/show-3709099.html?action=onClick
Metaspace 引起的 FullGC 問題排查過程及解決方案
https://blog.csdn.net/j3T9Z7H/article/details/92024567
Druid數據庫連接池引起的FullGC問題排查、分析、解決
https://www.codenong.com/cs107015711/
Druid參數配置導致的內存占用以及線上問題分析的一般方法
https://www.yashinu.com/chengxu/show-50962.html
jpa 中的 findAll() 泄漏排查
https://blog.csdn.net/weixin_30800249/article/details/114762388
jpa 導致內存泄漏
https://zhuanlan.zhihu.com/p/517631094
記解決線上因hibernate導致內存泄漏問題
http://www.rzrgm.cn/dcncy/p/13023045.html
spring boot2 jpa分頁查詢百萬級數據內存泄漏
　　分頁查詢百萬級數據，查詢處理過程中發現內存一直飆升，最終處理程序會掛掉，通過jvisualvm可以發現頻繁ygc 和fgc ,另外通過 jmap -histo:live ${pid} 命令可以看到jpa相關類和查詢出來的對象耗用大量堆空間。
　　解決辦法：在使用完查詢的對象后立即將其evict

entityManager.unwrap(Session.class).evict(myObj);

posted @ 2023-12-05 20:08 方東信閱讀(1527) 評論(0) 收藏舉報

刷新頁面返回頂部

方東信

人無遠慮必有近憂,生于憂患死于安樂
專業，專注，精益求精

老年代一直增大，系統巨慢，內存泄漏

問題

環境

過程

GPT說什么時候發生fullgc

用到的指令

堆外內存泄漏（上圖反應出來的情況，并不是堆外內存泄漏）

開啟GC日志后，重啟服務

截個圖

2小時候GC日志分析

日志片段

來揪出幕后黑手

如何優化

坑點

優化前全部日志

保留一下如果堆內存和元空間正常就得去看看這兒寫的東西了。。

參考

公告

方東信

人無遠慮 必有近憂,生于憂患死于安樂 專業，專注，精益求精

老年代一直增大，系統巨慢，內存泄漏

問題

環境

過程

GPT說什么時候發生fullgc

用到的指令

堆外內存泄漏（上圖反應出來的情況，并不是堆外內存泄漏）

開啟GC日志后，重啟服務

截個圖

2小時候GC日志分析

日志片段

來揪出幕后黑手

如何優化

坑點

優化前全部日志

保留一下如果堆內存和元空間正常 就得去看看這兒寫的東西了。。

參考

公告

人無遠慮必有近憂,生于憂患死于安樂
專業，專注，精益求精

保留一下如果堆內存和元空間正常就得去看看這兒寫的東西了。。