1. 生成數據源，上傳到ATP

假設某應用對接口的響應時間要求較高，超過1秒就判定為超時。某天發現線上接口時不時出現超時，懷疑是GC暫停導致的。

這時，我們可以找到應用的GC日志，并將它上傳到ATP，然后開始分析（具體操作參見開始使用ATP）。

2. 使用ATP GC日志分析

分析結果界面如下。通常我們會先查看GC類型，GC線程數，日志覆蓋的時間段等信息，排除誤操作，確認該文件和我們要分析的應用匹配。

接下來可以調整一下【分析配置】，選擇出現超時問題的時段。由于對暫停時間要求較高，可以把長暫停時間閾值設置到200ms。

接下來看一下【問題診斷】視圖，在這里ATP會根據日志的情況自動幫發現較為嚴重的問題并給出部分調優建議。發現大約在4點左右有一次Final Remark的時間較長。

看一下【暫停信息】視圖，能確認最長的一次暫停來自一次Final Remark導致的暫停，長達442ms，可能是導致超時的元兇。

用戶可以在【日志詳情】視圖中通過暫停時間搜索來找到這次Final Remark事件，還能看出其時間主要由Rescan和Class Unloading組成。

然后再看一下【內存統計】視圖，發現每次Old gc后內存使用率都較低，對象創建和晉升速度都較低，不需要做額外的堆分析來排查內存問題。

3. 結論

根據以上收集到的信息，我們可以大致確認應用出現超時的原因是CMS Final Remark，需要優化其暫停時間，可以考慮通過優化JVM參數或者升級到G1 GC來解決。