不要被直觉误导 关于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.增加堆的大小可以解决内存问题

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!