我查看我们服务器的状态，半个月发生了900+次full gc，大约20分钟一次full gc，这是正常的吗？或者说优化到多久一次会比较合理？
欢迎选择我的课程，让我们一起见证您的进步~~
雖然沒有優化過。不過覺得這個需要按照實際的業務需求和業務能力去做支撐.才好優化。
看java應用的heap大小以及qps，不過初步看20分鐘一次的full gc，貌似不大正常
jvm的優化談起來可以講幾個小時，這裡簡單的給你點意見，不繫統的展開說。
其一 ：你的問題是full gc 頻繁，看下總內存和老年代設定的是否太小了。 主要是看參數 -Xmx , -Xmn. 若是太小的話，必然會gc頻繁。
其二：新增下列參數 -verbose.gc -XX:+PrintGC -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -XX:+PrintXX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -XX:+Printed Xloggc:/data/log/xxx/xxx-gc.log -XX:+PrintGCDetails查看每次gc ，老年代還剩餘多少空間，一般來說，老年代的空間設定為gc後記憶體的2-2.5倍是一個較為合理的數值。 同時透過這個日誌可以看到是否大量的物件沒有在新生代充分的gc掉就進入老生代。原本可以透過新生代回收的對象進入老年代的話必然會full gc 頻繁
其三： 程式碼原因dump 記憶體 jmap -dump:live,format=b,file=xx.bin ［pid］然後透過MAT（http://www.eclipse.org/mat/）工具來看具體是哪塊大記憶體沒有被釋放
雖然沒有優化過。不過覺得這個需要按照實際的業務需求和業務能力去做支撐.才好優化。
看java應用的heap大小以及qps，不過初步看20分鐘一次的full gc，貌似不大正常
jvm的優化談起來可以講幾個小時，這裡簡單的給你點意見，不繫統的展開說。
其一 ：你的問題是full gc 頻繁，看下總內存和老年代設定的是否太小了。
主要是看參數 -Xmx , -Xmn. 若是太小的話，必然會gc頻繁。
其二：新增下列參數
-verbose.gc -XX:+PrintGC -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -XX:+PrintXX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -XX:+Printed Xloggc:/data/log/xxx/xxx-gc.log -XX:+PrintGCDetails
查看每次gc ，老年代還剩餘多少空間，一般來說，老年代的空間設定為gc後記憶體的2-2.5倍是一個較為合理的數值。
同時透過這個日誌可以看到是否大量的物件沒有在新生代充分的gc掉就進入老生代。原本可以透過新生代回收的對象進入老年代的話必然會full gc 頻繁
其三： 程式碼原因dump 記憶體
jmap -dump:live,format=b,file=xx.bin ［pid］
然後透過MAT（http://www.eclipse.org/mat/）工具來看具體是哪塊大記憶體沒有被釋放