常见问题处理

64位JDK和32最大的不同就是64位可以使用大内存,
但因此造成如果出现问题排查,dump的文件过大,产生快照也无法分析
而且64位因为涉及到指针膨胀和数据类型对齐之内,造成无辜内存损失,
最重要的是性能比32位低

根据运行环境选择适当的位数JDK,以及针对吞吐和并发请求等条件选择垃圾回收器

使用nio时,因为使用的是系统内存,所以jvm运行时候,设置恰当的堆内存,以便保留适当的系统内存给nio调用,避免直接内存溢出

尽量避免使用Runtime.getRuntime().exec()调用外部脚本,这个命令会创建一个和当前运行环境一样的进程,然后执行脚本,在注销进程,尽量采用api执行.

服务器通信,尽量避免一方访问过多,另一方无法处理的问题,可用异步生产者消费者处理

jvm调优

编译时间和类加载时间优化

禁用字节码校验,如果你确信系统可信.-Xverify:none
编译时间:可设置-server或者-client选择编译环境模式,以及-Xint禁止编译器执行,强制使用解释器解析字节码执行,不推荐使用

调整垃圾收集频率

垃圾回收主要是新生代和老年代内存不足造成的,当内存不足,就会频繁GC,每次GC后,如果没设置固定容量就会不停扩容
解决方案:提高堆和方法区大小,且设置固定大小
-XX:PermSize=10M -XX:MaxPermSize=10M
-XX:PermSize:限制方法区大小
-XX:MaxPermSize:最大大小
-Xms20M|-Xmx20M：堆的最小值和最大值设置为一样即可避免堆自动扩展、

jdk8中永久代废除了,采用Metaspace,相应的固定大小命令如下
-XX:MetaspaceSize=N -XX:MaxMetaspaceSize

通过-XX:DisableExplicitGC命令显示屏蔽掉代码中调用System.gc()

设置垃圾收集器降低延迟

根据具体生产情况选择垃圾回收器,比如针对CPU利用率不高的情况,可选择CMS,降低吞吐,提高垃圾回收效率,
-xx:+useConcMarkSweepGC
-xx:+UseParNewGC (默认CMS对应的新生代收集器)
避免吞吐降低过高,可设置老年代回收百分比上限
-XX:CMSInitiatingOccupancyFraction=XX,JDK8中默认值是92