【JVM】【调优案例】案例

高性能硬件程序部署策略

参数配置

-Xmx 和-Xms设定为12G 64位系统

现象

经常不定期出现长时间无响应

原因

GC导致的系统停顿

高性能硬件通用部署方式两种

1. 64位JDK来使用大内存。对于32为OS，理论上地址总线寻址为2的32次方即4G，但是通常OS会分用户空间和系统空间各占2G，因此，32位OS理论上最大的堆内存为2G；但是由于64位占用更大的内存因此DUMP文件会超级大，另外性能也没有32位的好，因此，采用第二种方式
2. 利用若干个32虚拟机建立逻辑集群，利用硬件资源。

处理方案

1. 采用5个32位JDK集群；
2. 由于关注用户的响应，采用CMS垃圾收集器

总结

1. 尽量避免FULLGC,根本是代码中对象生存时期不能太长，即绝大多数对象应该是"朝生夕灭"；
2. 如果FULLGC确实无法降低，则可以降低FULLGC的次数，譬如十几个小时执行一次，这样可以通过深夜执行定时任务出发GC或者重启服务器；

堆外内存导致溢出错误

现象

GC并不频繁、Eden区、survior区，老年代均正常，但系统依旧抛出内存溢出，最后从系统日志中找到异常堆栈，是因为java中使用直接内存导致溢出；

原因

32位的OS用户空间最大内存为2G,1.6G给java的堆，而DirectMemory并不直接算入这里面，而是剩余的0.4G给它。还有很关键的是，垃圾收集器进行时候并不是像新生代老年代那样发现空间不足的时候立马去回收，而是在老年代FullGC的时候，顺便的帮他清理下内存。

处理方案

配置MaxDirectMemorySize参数值内存不足时候抛出堆栈异常，方便查询，其实也并没有解决问题，堆外内存只能这样处理

类似堆外内存溢出

1. 线程堆栈：可以通过-Xss调整堆栈大小
2. Socket缓冲区：每个SOCKET都有received和send两个缓冲区，分别为37和25KB，连接过多的时候，就会抛出“Too many opne files”