热评博文：《》，现阅读量超 2500，小伙伴们不要错过哦！

2003 ~ 2008 年，这五年老兵哥我在通信行业做实习生和开发岗，主要用 C / C++ / MFC 开发嵌入式 / 服务器 / 桌面等应用程序，期间做过大量代码重构优化，但很少涉及性能调优，要么我负责的局部无需考虑并发访问和海量数据，要么网管平台仅供客户内部人员使用，不存在并发访问和海量数据。2008 年底，老兵哥我跳槽到了移动互联网做技术经理，随后五年主要用 Java / C++ 开发 Web / 服务器等互联网应用。

当时，架构师这个岗位在业界还是很罕见的，不懂预估并发用户、业务数据等规模，自然就预见不到后续并发访问和海量数据会带来巨大的性能挑战。我们赶着工期把功能需求实现、业务流程跑通，然后就上线了，但移动互联网爆发的那些年业务增长非常快，系统上线不久就遇到性能问题了，其现象就是原来耗时很短的操作现在动不动就超时，或者界面刷不出来数据等等，巨大的压力跟着客户投诉一起摆到了我面前。

性能调优任务不像普通开发任务，它需要背负业务、时间和难度等多种压力。罗马不是一天建成的，导致性能问题的原因错综复杂，当时老兵哥我也不知道从何处下手，找不到解决问题的切入点。好性能不是调优出来的，更多是设计出来的。只有经历过性能调优，才能体会这句话的真谛。性能调优，其实就是对承载业务的现网系统做重构优化，就像是边开车边换轮胎，它所需要的技能跟代码重构完全不在一个层级上。

现在老兵哥我知道，性能是系统性问题，性能调优离不开架构视角。不识庐山真面目，只缘身在此山中。当你陷在具体的、局部的问题当中，你是无法找到解决问题的思路的。你必须从实现细节跳脱出来，从更加宏观全局的视角来梳理业务流程，就像文末链接的系列文章《图解 Spring Cloud：HTTP 请求的处理流程与机制》的剖析过程类似，然后以业务流程为线索分析每个环节存在的性能瓶颈原因，这样你就不再困惑了。

当每个环节潜在问题梳理出来之后，根据资源、时间等外部限制，按照帕累托二八原则，你可以决定优先解决哪些问题，从而有条不紊地化解性能压力了。随着在性能调优上的经验不断丰富，你就越来越有信心掌控更大规模的系统了。更值得高兴的是，当你费老牛劲把这些自己挖的巨坑填上后，你就记得下次不要再给自己挖坑了，也就懂得怎样设计一个高性能的互联网系统了，这不就是从开发跃迁至架构的契机吗？

性能调优，是从开发岗跃迁至架构岗的拦路虎。升级思维的过程是痛苦的，尤其是在背负压力下的被动升级，跳出原先的舒适区，进入更大的舒适区，这样才能站上新平面。记得当时老兵哥我还有不少负面情绪，回顾过往才懂得要感谢当时的领导给我这份压力，逼迫我高强度学习并突破了旧的思维，机会和挑战是并存的。性能优化是一个不断迭代、持续进行的过程，涉及软件开发生命周期的所有阶段，对于某款采用 Hibernate 作为持久层框架的 Java EE 典型应用程序，性能优化会涉及以下几个方面：

• 业务规则调优，包括业务流程、交互设计等
• 应用容器调优，包括启动参数、连接数和线程数等
• Spring 调优，包括事务管理、二级缓存等
• Hibernate 调优，包括批量操作、抓取策略和缓存等
• 数据库调优，包括索引、SQL 语句和配置等
• JVM 调优，包括内存、垃圾回收 GC等
• 底层系统调优，包括操作系统、硬件等

如果对上述性能优化方向做些分类归并，我们可以采用下列分类维度来看：

• X 维度，即业务维度，技术始终是服务业务的，任何技术问题的原点就是业务需求。在启动技术层面的性能优化之前，我们有必要先审视一下业务流程是否合理，交互设计上有没有可以优化的空间等。
• Y 维度，待业务维度优化完毕，接下来就是审视技术在实现当前业务流程或交互设计的全链路上有没有可优化的地方，即 HTTP 请求处理全流程，从浏览器到应用容器，再到 Spring、Hibernate、数据库等。

• Z 维度，除了沿着 HTTP 请求的横向链路，我们还要审视支持应用系统的纵向技术栈，从上到下包括 JVM、操作系统和硬件等，这是整套应用系统运行的环境，许多性能问题都跟运行环境存在关系。

XYZ 维度分类是从不同层次梳理性能优化方向，有助于帮我们搭建起了性能优化的框架体系，这三个维度跟应用架构也是一一对应的。除了按照层次、纵横分类之外，我们还可以按性能优化对象的粒度划分，将优化范围分为函数、模块、框架、系统、链路和环境等等，从开发岗到架构师，我们就是要练就从小粒度到大粒度优化的能力，跳脱出原来的思维框架，站到更宽广的视角来选择优化路线。如果你没有精心设计优化方案就开始上述调优，这将会是非常耗时的，而且很可能收效甚微。一个好的优化方案必然要为各种调优任务划分优先级，任何时候都不可能有足够的时间和资金做全面优化，优先级的判断依据是投入产出比。在确定了优先级之后，接下来我们就按照帕累托 Pareto 定律（即 80/20 法则）来选取调优任务，集中百分之八十的力量去改善应用程序中最影响性能的百分之二十的问题。

今天先分享到这里，后续老兵哥我把这些调优经验和架构视角梳理出来供大家参考。坚持技术写作不容易，如果你觉得有价值，麻烦动动手指点下文 「 推荐 」按钮，让更多小伙伴可以看到，我也会更加有动力坚持分享。另外，老兵哥我后续还会分享职业规划、应聘面试、技能提升、影响力打造等经验，欢迎 关注 本专栏或歪信公主号 「 IT老兵哥 」！

关注「 IT老兵哥 」，赋能程序人生

• 软技能-热点文章：