排查步驟：
使用jstack檢查進程的線程狀態，發現fullgc線程很忙。
查看gc日誌,發現full-gc頻繁執行，每秒一次。出現fullgc只能是內存達到預設大小.由此可以斷定是內存的問題。
查看系統堆轉儲快照，除了char和String之外，排名第三的就是ConcurrentHashMap類型的數據，而這部分幾乎都是用來緩存全局變量用的。
結合代碼和之前打印的日誌，發現有一部分內存數量比較可觀。
這部分內存存儲的是承上啓下的數據，並且在數據結構完整處理之後會清理。注意是數據結構完整的前提下才會處理。
分析日誌發現上游數據質量差強人意，數據的完整率只有70%。這就意味着每次有30%的緩存數據得不到釋放，長此以往必會達到內存瓶頸。
解決辦法：
對需要緩存的靜態變量進行控制，設置存儲大小上限。實時監測存儲數量，一旦達到上線就清理10%，程序自動判斷自動處理，避免fullgc他老人家出面。