程序员必须掌握的性能调优 X Y Z

时间 2020-01-12

原文原文链接

热评好文：如何设计出优美的Web API？，现阅读量超过了2500，小伙伴们不要错过哦！
思否地址：如何设计出优美的Web API？，坚持技术写做不易，小伙伴们记得点个赞哦！html

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

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

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

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

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

性能调优，是从开发岗跃迁至架构岗的拦路虎。升级思惟的过程是痛苦的，尤为是在背负压力下的被动升级，跳出原先的温馨区，进入更大的温馨区，这样才能站上新平面。记得当时老兵哥我还有很多负面情绪，回顾过往才懂得要感谢当时的领导给我这份压力，逼迫我高强度学习并突破了旧的思惟，机会和挑战是并存的。缓存

性能优化是一个不断迭代、持续进行的过程，涉及软件开发生命周期的全部阶段，对于某款采用 Hibernate 做为持久层框架的 Java EE 典型应用程序，性能优化会涉及如下几个方面：性能优化

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

若是对上述性能优化方向作些分类归并，咱们能够采用下列分类维度来看：服务器

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

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

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

今天先分享到这里，后续老兵哥我把这些调优经验和架构视角梳理出来供你们参考。坚持技术写做不容易，若是你以为有价值，麻烦动动手指点下文「点赞」按钮，让更多小伙伴能够看到，我也会更加有动力坚持分享。另外，老兵哥我后续还会分享职业规划、应聘面试、技能提高、影响力打造等经验，欢迎关注本专栏或公众号「IT老兵哥」，赋能程序人生！

软技能-热点文章：（均发布于公众号）

“花式”裁人套路深，你知道吗？
遭遇裁人，如何渡过心理危机？
如何在寒冬中找到好工做？
2C 仍是 2B，跟找工做有什么关系？
大公司 vs 小公司，你会选哪一个？
记住这一点，不怕找不到好工做！
跳槽，跳仍是不跳，该怎么跳？
程序员“求包养”攻略揭秘
很努力了，为何我还在原地踏步？
如何写出好的产品帮助文档？

硬技能-热点文章：