【1】存在大於1s的FullGC

目前有存在大於1s的FullGC，金橋的機器目前是2C4G的，使用的GC方法只能使用單線程進行串行的回收，致使GC比較慢。

建議能夠調整GC參數，改用CMS，可以解決這個問題，

參數修改方法：

在應用 webapp/WEB-INF/tars/prod 文件夾下，建立文件 extraenv.sh

文件內容

#!/usr/bin/env bash

JAVA_OPTS="${JAVA_OPTS} -XX:+UseConcMarkSweepGC"

 

或者升級JAVA8後，默認使用CMS也能解決這個問題。

 

ps：我查的跟上面說的不同（https://zhuanlan.zhihu.com/p/45558897）

jdk1.7 默認垃圾收集器Parallel Scavenge（新生代）+Parallel Old（老年代）
jdk1.8 默認垃圾收集器Parallel Scavenge（新生代）+Parallel Old（老年代）
jdk1.9 默認垃圾收集器G1

實際應該是，機器目前是2C4G，核心數太少，因此採用串行Serial收集器（併發時對CPU資源佔用多，不適合CPU核心數較少的狀況。）

 

Minor GC 和 Full GC

• 新生代GC（Minor GC）：指發生在新生代的垃圾收集動做，由於Java對象大多都具有朝生夕滅的特性，因此Minor GC很是頻繁，通常回收速度也比較快。具體原理見上一篇文章。
• 老年代GC（Major GC / Full GC）：指發生在老年代的GC，出現了Major GC，常常會伴隨至少一次的Minor GC（但非絕對的，在Parallel Scavenge收集器的收集策略裏就有直接進行Major GC的策略選擇過程）。Major GC的速度通常會比Minor GC慢10倍以上。

並行和併發

• 並行（Parallel）：指多條垃圾收集線程並行工做，但此時用戶線程仍然處於等待狀態。
• 併發（Concurrent）：指用戶線程與垃圾收集線程同時執行（但不必定是並行的，可能會交替執行），用戶程序在繼續運行。而垃圾收集程序運行在另外一個CPU上。

老年代收集器中：

Serial Old 在進行垃圾收集時，必須暫停其餘全部的工做線程，直至Serial收集器收集結束爲止（「Stop The World」）。

 CMS（Concurrent Mark Sweep）收集器是一種以獲取最短回收停頓時間爲目標的收集器。從整體上來講，CMS收集器的內存回收過程是與用戶線程一塊兒併發執行的（Parallel是並行）

 

垃圾收集器詳情：https://www.cnblogs.com/twoheads/p/10207573.html