ygc是最頻繁發生的，發生的概率是oldgc和fullgc的的10倍，100倍，甚至1000倍。同時younggc的問題也是最難定位的。這裡給出ygc定位三板斧：
檢視伺服器swap&io情況，如果伺服器發生swap，會嚴重拖慢gc效率，導致stw時間異常長，拉長介面響應時間，從而影響使用者體驗（推薦sar工具）；一般健康的gc狀況給出建議ygc頻率不超過2秒/次，經驗值2秒~10秒/次都是比較合理的ygc頻率；檢視stringtable情況（請參考：探索stringtable提公升ygc效能）
排查每次ygc後倖存物件大小（jvm模型基於分配的物件朝生夕死的假設設計，如果每次ygc後倖存物件較大，可能存在問題）
如果ygc頻率遠高於這個值，例如20秒/次，30秒/次，甚至60秒/次，這種情況下，說明jvm相當空閒，處於基本上無事可做的狀態。建議縮容，減少伺服器浪費；
如果younggc頻率遠低於這個值，例如1秒/次，甚至1秒/好多次，這種情況下，jvm相當繁忙，建議follow如下步驟進行初步症斷：
檢查young區，young區在整個堆佔比在25%~40%比較合理，如果young區太小，建議擴大xmn如果沒有配置檢查survivorratio，保持預設值8即可，eden:s0:s1=8:1:1是乙個比較合理的值；
-xx:+disableexplicitgc，即沒有遮蔽system.gc()觸發fullgc，那麼可以通過jstat -gccause pid 5s來判定，lgcc表示最近一次gc原因，如果為system.gc，表示由system.gc()觸發，gcc表示當前gc原因，如果當前沒有gc，那麼就是no gc。
fullgc觸發條件
mysql調優經驗
訪問量越來越大，mysql自然成為瓶頸，因此最近我一直在研究 mysql 的優化，第一步自然想到的是 mysql 系統引數的優化，作為乙個訪問量很大的 日20萬人次以上 的資料庫系統，不可能指望 mysql 預設的系統引數能夠讓 mysql執行得非常順暢。通過在網路上查詢資料和自己的嘗試，我認為以下...
關於jvm的GC調優的做法
如果不能忍受full gc，預設設定也達不到你的期望值，並且應用停頓時間和你的目標不一致，那麼你需要對gc調優。調優的基本想法如下 1，能在新生eden區代 的資源，盡量不讓資源進入到survivor區。2，能在survivor區 的資源，盡量不讓資源進入old區。其實，我們的最終目的是盡量不讓太多...
C GC 延遲模式 通過API調優GC
使用環境 gc模式是針對程序配置的，程序執行期間不能更改，但是應用程式使用gcsetting類的gclatencymode屬性對垃圾 進行某種程度的控制。若要 物件，垃圾 器 gc 必須停止應用程式中所有正在執行的執行緒。垃圾 器處於活動狀態的時間段稱為延遲 在某些情況下 例如當應用程式檢索資料或顯...