虚拟机（JVM）常见的5个调优问题及解决方案

1. 高性能硬件上JVM运行速度却不够快，有时出现长时间停顿
2. 集群间同步导致的内存溢出
3. 堆外内存导致的溢出错误
4. 外部命令导致的系统缓慢
5. 不恰当的数据结构导致内存占用过大

高性能硬件上JVM运行速度却不够快，有时出现长时间停顿

例如将32为系统的服务器替换为64为操作系统，4CPU，16GB物理内存的新硬件，用以解决用户浏览网页缓慢的问题，第一种方式是通过使用64位JDK来使用大内存，第二中方式是通过使用若干个32位虚拟机建立起逻辑集群来利用硬件资源。

第一种方式的使用前提是需要把Full GC的频率控制的足够好，否则频繁的Full GC会严重影响用户的体验，由于内存较大，一次Full GC的时间也会相当长，十几G的堆内存一次Full GC会长达十几秒，尤其是当系统中存在大量“长命”的大对象时，Full GC会更容易被触发。这就是为啥升级了硬件反而系统变得更糟糕的原因，因此通过这种方式来实现系统响应速度的提升，代码必须要写的合理，尽可能的降低Full GC出现的频率，不仅如此，系统管理者还需要面临如下问题：

• 64为JDK的性能测试结果普遍低于32位JDK
• 需要保证程序足够稳定，因为几乎无法产生十几G的堆转储快照，即便产生了也难以分析问题
• 由于指针膨胀以及数据类型对其补白,导致相同程序消耗的内存，64位JDK大于32位JDK

第二方式的具体做法是在一台物理机上启动多个应用服务进程，每个进程分配不同的端口，然后在前端搭建一个负载均衡器，以反向代理的方式分配访问请求。因为仅仅是为了提高硬件资源利用率，所以不需要关心状态保留，热转移之类的高性能问题。也不需要绝对准确的负载均衡。因此使用无Session复制的亲和式集群是一个不错的选择。这种方式看上去完美解决了我们的问题，但是仍然由不足之处：

• 集群各节点竞争全局资源导致的问题
• 各资源池在各节点单独存在，导致资源浪费
• 单个节点仍受到32位JDK的内存限制
• 若使用本地缓存，会因为各节点都有一份缓存而导致内存浪费，可以改成集中式缓存。

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

在集群环境中，有写需求需要实现节点之间数据共享，如果将共享数据存储在数据库中，由于读写频繁，竞争激烈，对性能的影响较大，如果使用JBossCache构建一个全局缓存，一般情况下不会出现问题，但当网络不稳定时，若进行频繁的写操作，这样会产生很大的网络开销，使得大量数据等待写入而堆积在内存中，最终导致内存溢出。

堆外内存导致的溢出错误

堆外内存的垃圾收集不像新生代和老年代那样，当发现内存不足时触发GC，Direct Momory的内存回收只能在Full GC发生时顺便的帮忙清理掉废弃对象，否则只能当发现内存溢出时先chach，然后再主动提醒GC，若虚拟机还是不能及时回收，只能抛出内存溢出异常。除了Java堆和永久代之外，还有一些区域会占用较多内存，如线程堆栈，Socket缓存区，JNI代码，虚拟机和GC，这额内存的总和受到操作系统进程最大内存的影响。

外部命令导致的系统缓慢

当请求伴随着外部命令的调用时（如Runtime.getRuntime().exec()），Java虚拟机执行这个命令的过程是：首先克隆一个和当前虚拟机拥有相同环境变量的进程，然后用该进程去执行命令，执行完毕后再推出这个进程。对然外部命令能很快执行完毕， 但是频繁的进程创建资源开销很大，不仅是CPU，内存负担也会很重，因此会导致系统运行缓慢。

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

例如加载一个80M的数据文件到内存中解析，如果解析成HashMap数据结构，将会产生100W个HashMap Entry，若采用的是PartNew收集器，由于该收集器是采用复制算法，这个算法的高效时间里再大部分对线故事朝生夕灭的特性上，如果存活对象过多，把这些对象复制到Survivor并维持这些对象的正确引用，就会导致GC时间明显边长。要从根本上解决问题就需要避免使用HashMap这种空间利用率底下的数据结构（空间利用率=有效数据大小/占用总空间）