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。
)
