性能优化“三不要”原则

你好，欢迎收听极客视点。

每个程序员都希望自己写出高性能的代码，所以，性能优化这个话题是从来没断绝过。此前，Facebook性能优化和容量管理高级专家庄振运在他的《性能工程高手课》中总结出了性能优化六条原则，并把它们概括为：“三要，三不要”。上一篇文章，我们分享了“三要”，本文继续来了解“三不要”原则有哪些。

性能优化的目标，是追求最合适的性价比或最高的投入产出比，在满足要求的情况下，尽量不要做过度的优化。过度的优化会增加系统复杂度和维护成本，使得开发和测试周期变长。虽然性能上带来了一定程度的提升，但是和导致的缺点来比，孰轻孰重尚不可知，需要仔细斟酌，衡量得失。

一个建议是，根据产品的性能要求来决策。

在设计产品时，我们对产品的性能会有一定的要求，比如吞吐量，或者客户响应时间要达到多少多少。如果达不到这个既定指标，就需要去优化。反之，如果能满足这些指标，那么就不必要花费太多时间精力去优化。

比如，我们要设计一个内部查询系统，预计最多只有一百个人同时在线使用的话，就完全不用按照百万在线用户的目标去过度优化。

更重要的是，多数的优化方法是并不是完美无缺的，是有缺点的，尤其是可能会对系统设计的简化性，对代码的可读性和可维护性有副作用。如果系统简化性和代码可读性更加重要，当然就更不能过度优化。

要体会这一原则，我们先引用著名计算机科学家高德纳（Donald Knuth）的一段话：“现实中的最大问题是，程序员往往花太多时间，在错误的地方和错误的时间来试图提高效率和性能。过早的优化，是编程中所有邪恶和悲剧（或至少是大多数邪恶和悲剧）的根源。”

你只要稍微思考一下高德纳的话，就会发现，这句话在很多场景下都是很有道理的。

比如，在敏捷开发过程中，尤其是在面对一个全新的产品时，在业界没有先例和经验可遵循的情况下，最看重的特点是快速的迭代与试错，“尽快推出产品”是最重要的。这时，过早的优化很可能优化错地方，也就是优化的地方并非真正的性能瓶颈，因此让“优化工作”成为了无用功。而且，越早的优化就越容易造成负面影响，比如影响代码的可读性和维护性。

如果一个产品已经在业界很成熟，大家非常清楚它的生产环境特点和性能瓶颈，那么优化的重要性可以适当提高。否则的话，在没有实际数据指标的基础上，为了一点点的性能提升而进行盲目优化，的确是得不偿失的。

性能优化很忌讳表面和肤浅的优化，也就是那种“头痛医头，脚痛医脚”的所谓“优化”。如果对一个程序和服务没有全局的把握，没有理解底层运行机制，任何优化方案都很难达到最好的优化效果。

比如，如果你发现一个应用程序的CPU使用率并不高，但是吞吐率上不去，表面的优化方式可能是增大线程池来提升CPU使用率。这样的简单“优化”或许当时能马上看到效果，比如吞吐率也上去了，但是如果你仔细想想，就会发现如此的表面优化非常有问题。

这样的情况下，线程池开多大最合适？需不需要根据底层硬件和上层请求的变化而对线程池的大小调优呢？如果需要，那么手工调整线程池大小就是一个典型的“头痛医头”的优化。

为什么呢？

因为部署环境不会一成不变，比如以后CPU升级了，核数变多了，你怎么办？再次手工去调整吗？这样做很快会让人疲于奔命，难以应付，并且很容易出错。

对这样的场景，正确的优化方式，是彻底了解线程的特性，以优化线程为主。至于线程池的大小，最好能够自动调整。千万别动不动就手工调优。如果这样手工调整的参数多了，就会做出一个有很多可调参数的复杂系统，很难用，也很难调优，很不可取。就比如我们都熟悉的JVM调优，有上千个可调参数，非常被人诟病。

以上就是性能优化的“三不要”原则，对现代互联网的服务和系统来说，性能问题是根本的问题。如果不知道系统的性能瓶颈，查不出性能根因，不知道如何解决，无法做合理的优化，这个服务和系统一定不会高效。

《性能工程高手课》为你梳理出性能优化和容量效率方面的核心知识、通用策略和实践经验，通过对每一领域的原则和案例的讲解，带你去掌握必需的软硬技能，让你可以系统地、有条理地根据信息进行性能问题诊断，最终获得解决问题的能力。以下是这个专栏的目录，供你参考。记得使用极客视点专属口令，享受立减优惠。

优惠口令：xingneng1 适用专栏：《性能工程高手课》 适用规则：立减 10 元（满 40 元可用） 有效期：9月24日 - 10月1日