JVM——JAVA服务器应用故障处理与调优案例简要总结

一、大内存硬件上的程序部署

问题：网站不定期出现长时间失去响应

原因：垃圾收集停顿

解决：

1：单个虚拟机实例管理大内存，给堆分配足够大的堆内存，将Full GC频率控制足够低，可以通过定时任务触发Full GC

2：使用若干个虚拟机建立逻辑集群，在前端搭建一个负载均衡器，以反向代理的方式分配访问请求

二、集群间同步导致的内存溢出

问题：不定期出现多次内存溢出问题

原因：有一个负责安全校验的全局过滤器，导致各个节点之间网络交互过于频繁，重发数据在内存中堆积，产生内存溢出

解决：JBossCache的缺陷，MIS系统实现方式的缺陷

三、堆外内存导致的溢出错误

问题：服务端不定时抛出内存溢出异常，垃圾收集不频繁

原因：直接内存只能等Full GC时顺带回收

四、外部命令导致系统缓慢

问题：大并发压力测试时，发现请求响应时间慢

原因：用户请求的处理需要执行一个外部shell脚本，执行这个脚本需要创建进程，系统消耗大，内存负担重

解决：去掉脚本执行的语句，改为使用Java的API去获取这些信息

五、服务器虚拟机进程崩溃

问题：运行期间频繁出现集群节点的虚拟机进程自动关闭

原因：与一个OA门户集成后导致两边服务速度不对等，积累Web服务没有调用完成，等待的线程和Socket连接越来越多，超过虚拟机的承受能力后导致虚拟机进程崩溃

解决：通知OA门户方修复无法使用的集成接口，将异步调用改为生产者/消费者模式的消息队列

六、不恰当数据结构导致内存占用过大

问题：加载数据文件到内存进行数据分析时，minor GC停顿时间长

原因：存活对象更多，且主要HashMap<Long,Long>结构存储数据文件空间效率太低

七、由Windows虚拟内存导致的长时间停顿

问题：偶尔出现间隔约一分钟的时间无日志输出，处于停顿状态

原因：程序最小化时工作内存被自动交换到磁盘的页面文件中，发生垃圾收集时因为恢复页面文件的操作导致了不正常的收集停顿

解决：加入参数Dsun.awt.keepWorkingSetOnMinimize=true，保证程序在恢复最小化时能够立即响应

八、由安全点导致长时间停顿

问题：垃圾收集的停顿时间长，但是实际垃圾收集器进行回收的动作只占其中的几百毫秒

原因：部分线程已经走到了安全点，还有一些慢的线程并没有到

具体原因：虚拟机认为int类型或范围更小的数据类型作为索引值的可数循环不用设置安全点，但实际上这里的可数循环特别慢，所以大家都在等循环跑完才能进入安全点

解决：HotSpot原本提供了-XX：+UseCountedLoopSafepoints参数去强制在可数循环中也放置安全点，不过这个参数在JDK 8下有Bug[2]，有导致虚拟机崩溃的风险，所以就不得不找到RpcServer线程里面的缓慢代码来进行修改