JVM之优化（部署模型和Runtime）
选择JVM部署模型
JVM部署模型的选择总体来说就是决定应用是部署在单个JVM实例还是多个JVM实例上（这里简单举例说明一下JVM实例，比如：我们常用eclipse开发，启动一个eclipse就是启动了一个JVM实例，然后在JVM中运行一个main程序，又会启动一个JVM实例，两个JVM实例是隔离开的）。哪一个是最适合你的应用的呢？这个是前面说到系统需求和潜在规则来决定的。比如说:假如你要部署您的应用在一个64位的机器上面，可以支持更大Java堆，如果应用依赖第三方的本地代码组件，而且这个第三方暂时不支持64位机器，那么你就必须要强制使用32位的JVM而且要使用更小优化的Java堆。
单实例JVM模型
在单实例的JVM上部署应用，有一个好处，就是可以减低管理成本，毕竟有更少的JVM需要去维护嘛。应用能够使用的总内存更小，由于每一个单独部署的JVM有能够使用的内存上限。
注意：部署应用在单个JVM上存在的挑战是应用的可用性存在极高的风险，比如：JVM失败或者应用灾难性错误。
多实例JVM模型
部署Java应用在多个JVM上面有提高可用性和能够间接降低延迟的好处，由于应用部署在多个JVM上，某一个JVM出错，只会导致应用某部分无法使用，不会导致整个应用无法使用。多JVM部署可以提供低延迟，在多JVM部署中，Java堆的大小倾向于更小，更小Java堆可以允许有更小的垃圾回收暂停，垃圾回收器的暂停是明显影响延迟。另外，如果应用存在明显瓶颈，多个JVM部署可能帮助提升吞吐量，把压力分布到多个JVM上面，可以让用承受更大的压力。
使用多个JVM，JVM可能会和处理器绑定。把JVM和处理器绑定在一起，可以避免应用和JVM的线程在多个CPU上切换，提升CPU cache的命中率。
注意：部署多JVM的挑战在于管理、监控和维护需要更多的努力。
一般建议
- 没有最好的部署模型，只有更合适的，主要还是看需求和资源
- JVM需要大量内存占用，64位JVM可以提供比32位更大的JVM
- 要保证第三方组件支持64位，不管是第三方组件或自己开发的程序，必须在64位环境下编译
选择Runtime
- Client：启动块，占用内存小，32位，例如：eclipse
- Server：启动慢，启动后性能好，32位和64位
- Tiered：更快的启动时间，更高性能的生成代码，java 7 新增
注意：如果不是道使用什么Runtime，就使用Server，对启动时间有限制就用 Client 或 Tiered。
32位或者64位JVM
除了client和server runtime的选择，还需要在32位或者64位之间做出选择，HotSpot VM的默认配置是32位的。做出32位和64位的选择取决于应用需要的内存占用以及依赖的第三方库是否支持64位系统——如果有通过JNI使用本地接口。决定应用需要消耗的内存占用，会在下节中介绍。下面的表格列出了一些指导帮助在32位JVM或者64位JVM之间做出选择。注意的是HotSpot VM还没有64位的client runtime。
选择垃圾回收器
- Serial、Serial old：串行垃圾回收，简单，但是慢
- Parallel、Parallel old：并行垃圾回收，面向吞吐量，适合小内存
- CMS：适用低延迟，但是有内存碎片
- G1：使用大内存的JVM，分块垃圾回收，能保证吞吐量的前提下，控制延迟