JVM调优方案对比

liubulong

场景：
服务器更换了高性能的硬件资源：4CPU，16GB物理内存，64位CentOS。
     选用64位的JDK，将Java堆大小固定为12GB，发现不定期出现长时间失去响应的情况。

调优方案：
     通过监控服务器发现是由于GC导致的。虚拟机默认使用吞吐量优先收集器，回收12GB大小的堆，一次FULL GC大约需要14s左右。服务中由于需要缓存大量文档对象，这些对象都直接进入了老年代，无法通过Mimor GC清理，所以需要解决FULL GC发生频率过高的问题。

在高性能硬件上部署程序，主要有两种方式：
1、通过64位JDK来使用大内存
2、使用若干个32位虚拟机建立逻辑集群

第一种方案：
      适合交互性强，对停顿时间敏感的系统中，给JAVA虚拟机分配超大堆的前提是能够控制FULL GC的频率，尽量控制在24小时左右，通过在深夜不影响业务的情况下手动触发FULL GC。
      降低FULL GC的频率，需要控制进入老年代的对象，尽量不能有大量长生存时间的大对象产生。此为其一，还面临其他的问题，比如：
1、64位JDK的性能并不优于32位JDK
2、如果产生堆溢出，几乎无法产生堆转储快照，因为要产生十几GB的Dump文件，无法分析
3、相同程序在64位JDK消耗的内存一般比32位JDK大，这是由于指针膨胀，以及数据类型对齐补白等因素导致的。

第二种方案：
      在一台物理机中启动多个32位虚拟机建立逻辑集群，在前端搭建一个负载均衡，反向代理的方式分配请求。考虑在一台物理机上建立集群目的是为了尽可能利用硬件资源，并不需要关心状态保留、热转移之类的高可用性要求，也不需要保证每个虚拟机进程有绝对准确的负载均衡，因此使用无Session复制的亲合式集群比较合适。也就是在负载均衡器中选择SessionID分配的规则算法，将固定的用户一直分配到同一台机器上处理。
      当然，这种方案也有下面的问题：
1、尽量避免全局资源的竞争，比如磁盘竞争，当多个节点同时访问同一个文件的话，容易导致IOException
2、很难高效率的利用某些资源池，比如说连接池。一般是每个节点建立自己的连接池，所以如果可能的话尽量选用集中式的JNDI连接，但同时会带来一定的复杂性和额外的性能开销。
3、32位JDK在linux或UNIX系统中有最高4G的内存限制，而在windows系统中只能使用2GB内存。
4、大量使用本地缓存的应用，在逻辑集群中会造成较大的内存浪费，每个节点都需要缓存一份，所以需要选用集中式缓存来解决。