FullGC的STW停頓時間長
單體應用一臺硬件上的jvm的部署策略
單獨的jvm管理堆內存
對于用戶停頓時間敏感的系統，并不是必須使用Shenandoah或者ZGC這些明確以控制延遲為目標的垃圾回收器才能解決問題（當然，這是最好的方法），使用Parallel Scavenge/Old收集器，并且給java堆分配大內存空間也可以，但是必須把FullGC的頻率調整得夠低，比如，一天一次FullGC，可以在深夜執行定時任務觸發FullGC。
控制FullGC的關鍵是保證老年代的穩定，即要保證對象進入老年代是極少部分，大部分網站對象的生成周期都是請求級或者頁面級別的，會話級別和全局的長周期比較少，只要代碼寫的好，就可以減少FullGC。
回收大內存導致的長時間停頓，G1的增量回收可以緩解
大jvm堆分析困難，需要借助工具
使用若干個jvm建立集群邏輯來利用硬件
啟動多個jvm項目然后注冊在不同端口，在前端搭建一個負載均衡器反向代理來分配訪問（比如SessionId）
并發問題，訪問磁盤io，可能會導致IO異常
各個節點自己建立獨立的線程池，負載均衡必須弄得好，或者使用中央式的線程池
更換垃圾回收器減少GC時延
修改堆區域內存大小減少GC頻率
升級JDK
進入安全點耗時太長
啟動時間長（類加載耗時長）
異步調用的雙方的服務速率不匹配導致超過了虛擬機的承受能力
導致等待的Socket連接太多，線程太多，最終超過虛擬機的承受能力。
元空間大小的配置
可能調用外部命令導致耗時長
比如在java中調用shell
直接內存的回收
虛擬機雖然會對直接內存進行回收但是直接內存卻不能像新生代老年代那樣，發現空間不足就主動通知垃圾回收器進行GC，他只能等FULLGC時對其順便GC。
)
