在介绍性能优化的军火库之前，先来扯几句题外话。希望这些题外话，能打消你追求卓越性能的理想，来甘心当一枚圆滑的钉子。

我是非常不推荐程序员，对公司的业务，进行性能优化的。说这话，纯粹是基于个人自身安全考虑。因为性能优化，在大多数公司，属于费力不讨好的工作项。

追求极简的代码，性能卓越的代码，是有追求的程序员的目标。但随着经历了大大小小的公司，我发现很多优秀的程序员，在经受着这种追求的反嗜，以至于痛不欲生。下

有下面几点原因，虽然我们知道它肯定是错的，但我们无能无力：

1. 公司按照完成的功能，对程序员进行考核。性能优化属于额外的工期，也就是浪费成本的一种存在。
2. 团队不Care程序运行的效率，慢一点无所谓，等出问题了再救火就行。
3. 性能优化的风险大，通常要调整代码结构，甚至修改代码逻辑。不优化可能没事，一优化可能出事，没人愿意碰。

就一句话，整个团队深陷进行时泥潭，没有展望性思想，大家就那么浆糊着，得过且过。

以上是很多公司的现状，尤其集中在中小型公司。在这种公司里，除非系统慢到极点，优化之后有效果，或者领导要求你这么做，否则我都不建议你去碰。如果你执意如此，惹火烧身的时候不要后悔。

当然，有很多团队的技术氛围还是很nice的，甚至在代码review的时候，都会提出一些更优的建议。遇到这样的团队，就要珍惜，我们的军火库，毫无疑问是为了这些团队而准备的。

Brendan D. Gregg大叔，天马行空过《性能之巅》这本书。但这本书的内容有点深，很多工具都是从资源层面进行分析的。他更广为人知的一张图，就是下面这张工具的集合。当然还有现在无处不在的火焰图。

这密密麻麻的工具，都是偏低层的，大多数时候，我们用不到。所以我整理了一个稍微上层的，靠近平常使用习惯的军火库。大多数工具，你不需要再使用yum或者apt安装，都是自带的。

通用问题发现

如上图，就是我平常所使用的性能问题排查工具集合，可以排查一些通用的性能问题，比如CPU、内存、网络、I/O等。

大多数监控系统，抓取的也都是这些指标。由于这些性能数据都是发生在某一时间的，所以都只能排查问题发生当时的一些性能数据。强烈建议使用监控系统保存这些历史数据，可以进行问题追随，不用再傻乎乎等着问题复现了。

专用工具

不过，再怎么看，上面的这些工具也太零散了，学习的成本比较大，还需要记忆很多参数配置，才能再救火的环境中反应灵敏。

比较幸运的是，有一些可以获取性能概览的工具可以帮助我们减少脑细胞的损耗。

就拿top来说，有经验的同学，仅凭这一个命令，就能够判断系统中的资源，是否达到了瓶颈。这样的工具还有vmstat、sar、nmon等。尤其是nmon，是一个老牌的性能汇总工具，能够自动生成压测期间所产生的性能报告。

 这里面的几个性能深挖工具，学习曲线有点陡峭，但一旦掌握必使你产生主宰的感觉。但很多时候轮不到它们上场，因为总有一种大炮打蚊子的感觉。

Java专用工具

但是不要忘了，我们是搞Java的，碰到的性能问题，多属于JVM层面的。就拿perf这个工具来说，很强大，可以追踪到每一个c语言的函数调用的次数和耗时，但对Java来说是没用的，它生成的火焰图也没用。

所以Java自有一套这样的解决方案。

不仅有，而且更强大。尤其推荐jmc集成的JFR功能，这个记录的信息可真是太详细了。

 单机环境下，arthas是调试单机调用耗时的好工具，我不止一次使用它的trace命令完成了性能调优。在分布式环境下，skywalking类似的分布式调用链工具，也能助我们一臂之力。

END

有人可能觉得，我们上面列出的这些工具命令，实在是太多了，学不完，其实不是这样的。

在遇到性能问题，想要找到它的具体原因之时，你才会恨手头的工具太少，以至于期望有更加强劲的工具。

书到用时方恨少，事非经过不知难。

作为工程师，我们的工作，就是从这诸多的工具里，选择合适的组合，直捣黄龙。

当然，如果你捣的不太对，那后果就不太好了。参考文章开头的题外话，永远不要抢着去做这种费力不讨好的事情。性能优化这个东西，是一把双刃剑。可能会让你扶摇直上，也可能会让跌入谷底。，一切和你所处的团队有关。

可关注我的B站账号→→→→B站账号

学习交流群→→→→交流群