优化代码时做出正确的决定

您手头有一项优化任务。 太好了–您终于有可能做一些有趣的事情，而不用执行另一个发票处理屏幕。
优化任务（希望）与某些非功能性要求相关联，例如应用程序每秒必须处理的事务数或允许的每个事务的最大时间。

现在，您已经确定了应用程序中导致性能问题的部分。 您的应用程序的这一部分使用特定的算法。 您正在考虑将解决方案切换到另一种实现方式，并希望评估性能影响。 正如我们在前一篇文章中所讨论的那样 ，您明智地选择了每秒的用户事务数作为度量标准。 您使用旧的实现来运行压力测试，写下每秒实现的操作数，然后使用新的实现来运行相同的压力测试，写下每秒的新操作数。

接下来，您比较数字并做出一些决定。 这些决策中的一些可能包括对新的实施方案进行进一步的性能测量和/或优化的要求。 让我提出一些非常简单的示例：

• 使用旧算法，需要1,000笔交易，耗时100秒
• 使用改进的算法，相同的1,000个事务耗时90秒

大！ 新版本更快！ 您对该算法所做的更改使您的性能提高了10％。 现在，您可能需要在优化算法的基础上，根据有关后续步骤的信息做出进一步的决策。 但是，让我们考虑更多的信息：花费在垃圾收集上的时间。 您可以从GC日志中提取总的GC暂停时间。 那是您的应用程序停止进行世界各地的GC工作所花费的时间。 然后我们可以得到以下图片：

• 使用旧算法，需要1,000笔事务处理100秒，其中GC暂停使用了20秒
• 使用改进的算法，1,000个事务花费了90秒，而GC暂停花费了27秒

我们可以从这些信息中得出什么？ 首先，算法的运行时间从100 – 20 = 80秒减少到90 – 27 = 63秒，加快了21％。 其次，GC占用您大约30％的CPU时间。 基于此，您的进一步算法的优化计划不仅应着眼于运行速度，还应着重于减少内存使用量和GC时间。

您应该如何决定选择哪个方向？ 为了回答这个问题，我们应该调查您的性能要求。 也许您已经满足了您每秒需要处理多少个事务的要求。 但是所有交易是否都在短时间内处理？ 也许您最初只测量每秒事务数的明智想法可能不是最好的想法？

这些技术要求可以转化为两个不同的方面，即吞吐量和延迟。 您当前的工作已提高了吞吐量，但可能会由于引入更多和/或更长的GC暂停而延迟了延迟。

NFR将指导您算法的进一步优化。 假设您仍未达到吞吐量要求。 您接下来的步骤是什么？

考虑到您的实现在GC暂停上花费了30％的时间 ，仅这个事实就应该引起危险。 在典型情况下（是的，我知道这就像测量医院的平均温度并据此做出决定）， GC暂停时间不应超过总时间的5％ 。 而且，如果您超过10％，则极有可能您应该对此采取某些措施。

减少GC暂停的第一步是调查JVM配置。 也许您只需要增加最大堆大小(-Xmx)? 也许您应该调整世代大小（ -XX:NewRatio ， -XX:SurvivorRatio …）？ 也许您应该尝试使用其他垃圾收集器（ -XX:+UseConcMarkSweepGC ， -XX:+UseParallelGC …）？ 根据您的应用程序，正确的答案可能是更改以上各项的组合，或者对其中一些进行更改，或者根本不提供任何帮助。

当配置JVM无法提供足够的结果时，下一步就是调查您的数据结构。 也许可以通过更改源代码来减少GC暂停。 也许您可以摆脱原语周围的所有包装器类，并显着减少开销？ 也许您可以看看所使用的Collection类并减少造成的开销？ 还是对于某些特殊情况，当您的算法不断地创建和销毁相同的对象时，也许对象池化是一个好主意？

并且在上述情况下，仅在此之后，您才可能真正想开始减少算法本身带来的开销。 在某些特殊情况下，这可能会导致您发现划分速度太慢。 而且，您需要找到一种巧妙的方法，用数据结构所支持的更便宜的操作来代替它。 否则每次写入java.util.concurrent.atomic.AtomicBoolean所伴随的内存障碍太昂贵了。 但是，让我将这些情况留给另一个故事，当我描述我一生中处理过的一些最奇怪的CPU浪费时。

结论–如果您要优化代码，请确保已对吞吐量和延迟的要求进行了仔细考虑。 而且您不会只坚持一种优化技术。 希望阅读本文后，您现在可以在自己的武器库中使用更多工具。

参考： Plumbr Blog博客上的JCG合作伙伴 Nikita Salnikov Tarnovski 优化代码时做出正确的决定 。

翻译自: https://www.javacodegeeks.com/2012/12/making-the-right-decisions-when-optimizing-code.html