《深入理解Java虚拟机》第5章调优案例分析与实战

5.2.1高性能硬件上的程序部署策略
监控服务器运行状况发现网站没有响应是由GC停顿导致的，虚拟机运行在Server模式，默认使用吞吐量优先收集器，回收12GB的堆，一次Full GC的停顿时间高达14秒。访问文档把其从磁盘提取到内存中，导致内存中出现很多由文档序列化产生的大对象。这些大对象很多进入了老年代，没有在Minor　GC中被清理掉。

因此内存很快被消耗殆尽。

在高性能硬件上部署程序，目前主要有两种方式：

通过64位JDK使用大内存。
使用若干个32位虚拟机建立逻辑集群利用硬件资源：
在一台物理机器上启动多个应用服务器进程，给每个服务器进程分配不同的端口，然后在前端搭建一个负载均衡器，以反向代理方式分配访问请求。
仍受到32位内存限制：
32位WINDOWS每个进程限制2GB内存，堆一般最多开到1.5G内存。
避免节点竞争全局的资源，IO异常。
大量用本地缓存，在逻辑集群中会造成较大的内存浪费。考虑改为集中式缓存。

控制Full GC频率：大多数对象的生存时间不能太长，保障老年代空间的稳定。
系统的CPU资源敏感度较低时，改为CMS收集器进行垃圾回收。

5.2.2　集群同步导致的内存溢出
JBossCache和MIS（管理信息系统）实现的缺陷。能多读不能多写。服务过程中，一个页面会产生数次乃至数十次的请求，因此这个过滤器导致集群各个节点间的网络交互非常频繁。网络情况不能满足传输要求时，重发数据在内存中不断堆积，内存溢出。
5.2.3 堆外内存导致的溢出错误
为了实现客户端能实时地从服务端接受数据，使用了AJAX技术，服务器是Jetty。
溢出关键：GC时，VM虽然会对直接内存进行回收，但直接内存不像新生代和老年代那样，发现空间不足了就通知收集器进行垃圾回收。它只能等待抛出内存溢出异常时，在cathch字段里请求System.gc()。如果VM不听，我们只能眼睁睁堆还有内存，却抛出溢出。
本案例用到的CometD框架，正好有大量NIO操作用到Direct　Memory。

除了Java堆和永久代外，还有
Direct　Memory
线程堆栈
Socket缓存区
JNI
VM和GC
占用了较多内存
5.2.4 外部命令导致系统缓慢
CPU占用很高，占用多的不是应用本身。是”fork“系统调用（Linux用来产生新进程的）。
应该去掉这个shell脚本执行的语句，改为Java的API去获取这些信息。

5.2.5 服务器JVM进程崩溃
OA（办公自动化门户）
频繁集群节点的VM进程自动关闭的现象。
利用SoapUI两边服务不对等，等待的线程和Socket连接越来越多。超过VM的承受能力。
异步调用改成生产者/消费者模式的消息队列实现

5.3 实战：eclipse运行速度调优
VM的运行数据通过VisualVM及其扩展插件VisualGC进行采集。
得出是永久代的容量问题。
JDK1.5有4个参数，多出XXMaxPernSize这个参数。
JDK1.6的程序提供商由Sun变为Oracle。把默认值64MB改为最大256MB即可。
JDK1.6的类加载速度比1.5慢，但总体仍有优势。

关于虚拟机运行模式

client模式使用的是代号C1的轻量级编辑器，server模式使用C2编译器。

5.3.4 调整内存设置控制垃圾收集频率
每当发生一次GC，所有的用户线程都必须跑到最近的一个安全点，然后挂起线程等待垃圾回收。过于频繁的GC会导致很多没有必要的安全点检测、线程挂起以及恢复操作。
新生代的Minor GC频繁发生，因为VM分配给新生代的空间太小。
Full GC次数少，但占了绝大部分的GC时间。大多数由老年代容量扩展导致的。为了避免，可以把-Xms和-XX:PermSize参数值分别设置为-Xmx和-XX:PermSizeMax参数值。强制VM把老年代和永久代的容量固定下来。避免运行时自动扩展。

5.3.5 选择收集器降低延迟
新生代用ParNew，老年代用CMS(默认老年代使用68%就收集)。避免总体吞吐量下降厉害，用-XX:CMSInitiatingOccupancyFraction=85将GC临界值提升到85%

服务端的调优还有数据库，资源池，磁盘I/O等。
下面是书中的Eclipse配置：

希望这篇能对读者有所启发。