本文探讨了在高性能硬件上部署Java程序的策略，分析了不同部署方式的优缺点，并提供了具体的调优案例，如解决集群间同步导致的内存溢出、处理堆外内存问题等。
第五章 调优案例分析与实战
5.1 高性能硬件上的程序部署策略
在高性能硬件部署程序，目前主要有两种方式： 1) 通过64位JDK来使用大内存； 2) 使用若干个32位虚拟机建立逻辑集群来利用硬件资源。
对于第一种方式，需考虑以下可能面临的问题：
- 内存回收导致的长时间停顿；
- 现阶段，64位JDK的性能测试结果普遍低于32位JDK；
- 需要保证程序足够稳定，因为这种应用若产生堆溢出几乎无法产生堆转储快照(因为要产生几十G甚至更大的dump文件)，即使产生了快照也无法进行分析；
- 相同的程序在64位JDK中消耗的内存一般比在32位JDK大，这是由指针膨胀及数据类型对齐补白等因素导致的。
对于第二种方式，也需考虑如下问题：
- 尽量避免节点竞争全局资源，如磁盘竞争，各节点若同时访问某个文件的话，很容易导致I/O异常；
- 很难最高效率地利用某些资源，如连接池，一般都是在各节点建立自己独立的连接池，这可能导致一些节点池满了而另外一些节点仍有较多的空余；
- 各节点不可避免的收到32位的内存限制，32位windows平台每个进程最多只能使用2GB内存；
- 大量使用本地缓存的应用，在逻辑集群中会造成较大的内存浪费，因为每个逻辑节点都有一份缓存，可考虑把本地缓存改为集中式缓存。
5.2 集群间同步导致的内存溢出
使用类似JBossCache集群缓存来进行同步时，可以允许读操作频繁，因为数据在本地内存有一份副本，读取的操作不会耗费多少资源，但不应有过于频繁的写操作，这会带来很大的网络同步开销。
5.3 堆外内存导致的内存溢出错误
虚拟机回收的内存包括堆内存和非堆内存，但是对于非堆内存，只能等到老年代满了后Full GC，然后才会帮它清理掉废弃的对象，否则，就会抛出内存溢出异常。另外，若打开了-XX:+DisableExplicitGC，则虚拟机不会对其进行回收。
从实践经验的角度出发，除了Java堆和永久代之外，我们还应关注以下区域也会占用较多的内存，都受到操作系统的最大内存限制：
- Direct Memory：可通过-XX:MaxDirectMemeorySize调整大小，内存不足时抛出OutOfMemoryError或OutOfMemoryError:Direct buffer memory；
- 线程堆栈：可通过-Xss调整大小，内存不足时抛出StackOverFlowError或StackOverFlowError:unable to create new native thread；
- Socket缓存区：每个Socket连接都Recieve和Send两个缓存区，分别占大约37KB和25KB，无法分配时抛出IOException:Too many open files；
- JNI代码：若代码中使用JNI调用本地库，那本地库使用的内存也不在堆中；
- 虚拟机和GC：虚拟机和GC代码的执行也要耗费一定的内存。
5.4 外部命令导致系统缓慢
通常情况下，用户应用的CPU占用率应该占主要地位，才能说明系统是正常工作的。在Java虚拟机中，用户编写的Java代码最多只有线程的概念，不应当有进程的产生。
5.5 服务器JVM进程崩溃
5.6 实战：Eclipse运行速度调优
- 调优前的程序运行状态：运用VisualVM及其扩展插件VisualGC进行Eclipse运行状态的采集；
- 升级JDK的性能变化及兼容问题：进行Exclipse调优时首先选择升级虚拟机的版本；
- 编译时间和类加载时间的变化：虚拟机在进行类加载时会进行字节码验证，可通过参数-Xverify:none方式禁止掉字节码的验证过程以提高加载性能；对于编译时间可通过参数-Xint禁止编译器动作，这虽然提高了编译效率，但是却降低了运行效率；
- 调整内存设置控制垃圾收集频率：Eclipse启动时Full GC大多数是由于老年代容量扩容而导致的，由永久代空间扩展而导致的也有一部分，为了避免因扩展带来的性能浪费，可以把-Xms和-XX:PermSize的参数值分别设置为-Xmx和-XX:PermSizeMax参数值，强制虚拟机在启动时把老年代和永久代的容量固定下来，避免运行时自动扩展；
- 选择收集器降低延迟。
核心内容出处：《深入理解Java虚拟机:JVM高级特性与最佳实践》
扫一扫
1511
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
