8. 在GC中CMS总是比Parallel Old更好Oracle JDK默认使用一个并行的，全部停止（stop-the-world STW)垃圾收集器来收集老年代的垃圾。 另外一个选择是并发标记清除（CMS）收集器。这个收集器允许程序线程在大部分的GC周期中仍然继续工作，但它需要付出一些代价和带来一些警告。 允许程序线程和GC线程一起运行不可避免地导致对象表的变异同时又影响到对象的活跃性。这不得不在发生后进行清楚，所以CMS实际上有两个STW阶段（通常非常短）。 这会带来一些后果：
依据程序的情况这些成本或者是值得的或者又不是。但并没有免费的午餐。CMS收集器是一个卓越的工程品，但它不是万能药。 所以在介绍前，CMS是你正确的GC策略，你得首先考虑Parallel Old的STW是不可接收的和不能调和的。最后，（我不能足够地强调），确定所有的指标都从相当的生产系统上得到。 |
9. 增加堆内存会解决你内存溢出的问题当一个应用程序崩溃，GC中止运行时，许多应用组会通过增加堆内存来解决问题。在许多情况下，这可以很快解决问题，并争取时间来考虑出一个更深的解决方案。然而，在没有真正理解性能产生的根源时，这种解决策略实际上会使情况更糟糕。 试想一下，一个编码很烂的应用构造了非常多的领域对象（生命周期大概维持2，3秒）。如果内存分配率足够高，垃圾回收就会很快地执行，并把这些领域对象放到年老代。一旦进入了老年代，对象就会立即死去，但直到下一次完全回收才会被垃圾回收器回收。 如果这个应用增加其堆内存，那么我们能做的是增加空间，为了存放那些相对短期存在，然后消逝的领域对象。这会使得 Stop-The-World 的时间更长，对应用毫无益处。 在改变堆内存和或其他参数之前，理解一下对象的动态分配和生命周期是很有必要的。没做调查就行动，只会使事情更糟。在这里，垃圾回收器的老年分布信息是非常重要的。 |
总结当说道Java性能调优时直觉通常会误导人。我们需要经验数据和工具来帮助我们具象化和了解平台的特性。 垃圾收集也许提供了这方面最好的例子。GC子系统对于调优和生产数据指导调整有惊人的潜力，但对于生产程序它是很难去不借助工具来让产生的数据有意义。 运行任何Java进程，默认都应该最少有这些标记： -verbose:gc(打印GC日志） -Xloggc:（更全面的GC日志） -XX:+PringGCDetail(更详细的输出） -XX:+PrintTenuringDistribution(显示由JVM设定的保有阈值） 然后使用工具来分析日志——手写脚本和一些生成图，或一个可视化工具如（开源的）GCViewer或JClarity Censum。 |
