对于Java程序，优化的重点集中在内存分配和GC策略调整上。JVM垃圾回收会不同程度的导致程序中断。
JVM垃圾回收性能主要有两个度量指标：
- 吞吐量：工作时间（不包含GC时间）占总时间的百分比。工作时间包括 运行时间+内存分配时间
- 暂停：测试时间内，有垃圾回收导致的程序停止响应次数。
- FootPrint决定扩展性。分布式系统中，Promptness及时性（对象死亡到内存被释放的时间）需要重点考虑
垃圾收集器
官方的JVM（Oracle/SUN发布的）主要有一下三种垃圾收集器
串行收集器（Serial Collector）
采用单线程执行所有的垃圾回收工作，适用于单核的服务器或者多核服务器上数据集小于100MB的应用
并行收集器（Parallel Collector）
吞吐量收集器，以并行方式执行Monitor回收（年轻代垃圾回收），可以显著降低垃圾回收的开销。适用于多处理器或多线程硬件上运行中型或大型应用。通过并行压缩的特性，可以使并行收集器以并行的方式执行Major回收（整个堆的垃圾回收），如果不启用并行压缩，Major回收将使用单线程执行，会降低扩展性
并发收集器（Concurrent Collector）
并发的方式执行大部分垃圾回收，缩短垃圾回收的暂停时间。适用于响应时间优先于吞吐量的应用。该收集器虽然最小化暂停时间，但是会降低应用性能
JDK 8中新增加的并发收集器
CMS收集器（Concurrent Mark Sweep Collector，并发标记收集器）
适用于缩短垃圾回收暂停时间并且负担得起与垃圾回收共享处理器资源的应用
G1收集器（Garbage-First Garbage Collector）
适用于大容量内存的多核服务器
总结
如果应用程序的数据集小于100MB，选择串行收集器
如果应用运行于单核系统并没有暂停时间的要求，可以由JVM自行选择收集器或者使用串行收集器
如果优先考虑应用程序峰值性能，没有暂停时间要求或者可以接受1秒甚至更长时间的暂停，可以由JVM自行选择或者选择并行收集器
如果应用程序响应时间比整体吞吐量重要，垃圾回收暂停时间必须小于1秒，可以用并发收集器