高性能硬件上的程序部署策略

硬件升级前：1个CPU，32位系统，1.5G堆
硬件升级后：4个CPU，64位系统，16G物理内存，分配12G堆
    管理员为了尽量利用硬件资源，选用了64位JDK，并通过-Xmx和-Xms参数将堆固定在12GB。但是网站经常不定期出现场时间没有相应的现象。
    监控发现，是由于GC停顿造成的，虚拟机运行在server模式，默认是吞吐量优先收集器，回收12G堆，一次Full GC停顿时间高达14秒。由于程序设计的关系，访问文档需要把文档从磁盘提取到内存中导致内存中有很多序列化大对象进入到老年代，没有在minor GC时就被回收。
    升级前，只是感觉系统缓慢，但是不会发生十分明显的停顿。
    在高性能服务器上，通常有2种部署策略
1.通过64位JDK来使用大内存；
2.使用若干个小内存的虚拟机建立逻辑集群来“榨干”硬件资源。
【64位大内存JDK】
    使用64位大内存JDK，应当降低full GC的频率来减少对用户的影响。主要对象的生存周期应该是请求级或者页面级的。全局和会话级的场生命周期的对象相对较少只要代码合理，是可以避免的。
    通过设置合理的垃圾收集器，也可以在一定程度上避免场时间停顿，例如CMS或者目前最先进的G1垃圾收集器。
    另外使用64位大内存JDK的时候需要考虑：
1.内存回收导致场时间的停顿；
2.现阶段，64位JDK性能普遍低于32位JDK；
3.dump的快照文件过大；
4.相同程序在64位JDK里消耗比32位JDK里大，由于指针膨胀等因素造成。
【小内存JDK逻辑集群】
部署方便，可以很容易提高性能，非常适合硬件敏感度较低的场合，尤其是CPU敏感度较低的情况。但是也是有一定缺陷的。
1.资源利用里相对较低，启动的额外“服务”较多；
2.各虚拟节点竞争全局的资源，例如：磁盘IO等；
3.资源池利用率低，不能共享，除非JNDI；
4.大量的本地缓存，重复的对象创建，逻辑想要考虑共享缓存可以得到改善；