不要被直觉误导 关于Java性能的9个谬论
|
7.手写对象池适合一大类应用 认为Stop-The-World停顿在某种程度上是不好的，应用开发团队的一个常见反应就是在Java堆内实现自己的内存管理技术。这往往会归结为实现一个对象池(甚至是全面的引用计数)，而且需要使用了领域对象的任何代码都参与进来。 这种技术几乎总是具有误导性的。它基于过去的认知，那时对象分配非常昂贵，而修改对象则廉价的多。现在的情况已经完全不同了。 现在的硬件在分配时非常高效;最新的桌面或服务器硬件，内存带宽至少是2到3GB。这是一个很大的数字，除非专门编写的应用，否则要充分利用这么大的带宽还真不容易。 一般来说，正确实现对象池非常困难(尤其是有多个线程工作时)，而且对象池还带来了一些负面的要求，使这种技术不是一个通用的良好选择： • 所有接触到对象池代码的开发者必须了解对象池，而且能正确处理; • 哪些代码知道对象池，哪些代码不知道对象池，其界限必须让大家知道，并且写在文档中; • 这些额外的复杂性要保持更新，而且定期复审; • 如果有一条不满足，悄然出现问题(类似于C 中的指针复用)的风险就又回来了。 总之，只有GC停顿不能接受，而且调校和重构也未能将停顿减小到可以接受的水平时，才能使用对象池。 8.在垃圾收集中，相对于Parallel Old，CMS总是更好的选择 Oracle JDK默认使用一个并行的Stop-The-World收集器来收集老年代，即Parallel Old收集器。 Concurrent-Mark-Sweep (CMS)是一个备选方案，在大部分垃圾收集周期，它允许应用线程继续运行，但这是有代价的，而且有一些注意事项。 允许应用线程与垃圾收集线程一起运行，不可避免地带来一个问题：应用线程修改了对象图，可能会影响对象的存活性。这种情况必须在事后加以清理，因此CMS实际上有两个STW阶段(通常非常短)。 这会带来一些后果： • 必须将所有应用线程带到安全点，每次Full GC期间会停顿两次; • 尽管垃圾收集与应用同时执行，但应用的吞吐量会降低(通常是50%); • 在使用CMS进行垃圾收集时，JVM所用的簿记信息(和CPU周期)远高于其他的并行收集器。 这些代价是不是物有所值，取决于应用的情况。但是天下没有免费的午餐。CMS收集器在设计上值得称道，但它不是万能的。 所以在确定CMS是正确的垃圾收集策略之前，首先应该确认Parallel Old的STW停顿确实不能接受，而且已经无法调校。最后，我重点强调一下，所有指标必须从与生产系统等价的系统中获得。 9.增加堆的大小可以解决内存问题 当应用陷入困境，并且怀疑是GC的问题时，很多应用团队的反应就是增加堆的大小。在某些情况下，这样做可以快速见效，而且为我们留出了时间来考虑更周详的解决方案。然而，如果没有充分理解性能问题的原因，这种策略反而会让事情变得更糟糕。 考虑一个编码非常糟糕的应用程序，它正在产生很多领域对象 (它们的生存时间很有代表性，比如说是2-3秒)。如果分配率高到一定程度，垃圾收集会频繁进行，这样领域对象会被提升到老年代。领域对象几乎是一进入年老代，生存时间就结束了，从而直接死亡，但它们直到下一次Full GC时才会被回收。 如果增加了应用的堆大小，我们所做的不过是增加了相对短命的对象进入和死亡所用的空间。这会导致Stop-The-World停顿时间更长，对应用并无益处。 在修改堆大小或者调校其他参数之前，理解对象的分配和生存时间的动态是很有必要的。没有测量性能数据就盲目行动，只会使情况更糟糕。在这里，垃圾收集器的老年代分布情况特别重要。 结论 当谈到Java的性能调校时，直觉常常起误导作用。我们需要实验数据和工具来帮助我们将平台的行为可视化并加强理解。 垃圾收集就是最好的例子。对于调校或者生成指导调校的数据而言，GC子系统拥有无限的潜力;但是对于产品应用而言，不使用工具很难理解所产生数据的意义。 默认情况下，运行任意Java进程(包括开发环境和产品环境)，应该至少总是使用如下参数： • -verbose:gc(打印GC日志); • -Xloggc:(更全面的GC日志); • -XX:+PrintGCDetails(更详细的输出); • -XX:+PrintTenuringDistribution(显示JVM所使用的将对象提升进入老年代的年龄阈值)。 然后使用工具来分析日志，这里可以利用手写的脚本，可以用图生成，还可以使用GCViewer(开源的)或jClarity Censum这样的可视化工具。 作者：Ben Evans 译者：臧秀涛 原文链接：http://www.infoq.com/articles/9_Fallacies_Java_Performance 译文链接：http://www.infoq.com/cn/articles/9_Fallacies_Java_Performance 关于作者 Ben Evans是jClarity(这是一家创业公司，主要设计辅助开发和运维团队的性能工具)的CEO。他是LJC(伦敦Java用户组)的组织者之一，也是JCP执行委员会的成员之一，JCP执行委员会负责帮助定义Java生态系统中的相关标准。他还是Java Champion和JavaOne Rockstar。他与人合著了《The Well-Grounded Java Developer》一书。此外，他还经常进行公开演讲，探讨Java平台、性能、并发及相关话题。 本文转载自其它媒体，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。 （编辑：西安站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |