1.. jstact 命令先分析一下

一次fullgc之後 old 老年代使用比例 只降低2% 應該有什麽大的對象常駐內存。

2.可以使用jmap 命令查看對象大小 (這裏後面使用jprofiler 就沒用這個命令)

jmap -histo:live 72947 | more

3 .dump 線上文件棧

[root@yszyz10a153 ~]# jmap -dump:live,format=b,file=heap201712.hropf 72947
Dumping heap to /root/heap201712.hprof ...

4

使用jprofiler 加載dump文件 (jprofiler版本9.1.1)

點擊菜單biggst object 發現大對象是arrayblockingqueue 占用400M 點擊show in graph 圖形展示對象

發現關聯的可能問題來自 logback

繼續查看

也是指向logback

查看logback的配置文件 info級別

1. <!-- 異步輸出，異步的log片段必須在同步段後面，否則不起作用 -->
2. <appender name="ASYNC_INFO" class="ch.qos.logback.classic.AsyncAppender">
3. <!-- 不丟失日誌.默認的,如果隊列的80%已滿,則會丟棄TRACT、DEBUG、INFO級別的日誌 , 保持INFO的events，設置該值為0。 -->
4. <discardingThreshold>0</discardingThreshold>
5. <!-- 更改默認的隊列的深度,該值會影響性能.默認值為256 -->
6. <queueSize>100000000</queueSize> <!-- 設置太大 ，系統可能跑步起來 0<queueSize<1個億 -->
7. <!-- 添加附加的appender,最多只能添加一個 -->
8. <appender-ref ref="INFO" />
9. </appender>

queuesize 設置的太大了 調小該值即可 是個初始的blockingqueue

使用jprofiler分析dump文件一個實例