不羨鴛鴦不羨仙，一行代碼調半天。原創：小姐姐味道（微信公衆號ID：xjjdog），歡迎分享，轉載請保留出處。
在介紹性能優化的軍火庫之前，先來扯幾句題外話。希望這些題外話，能打消你追求卓越性能的理想，來甘心當一枚圓滑的釘子。
我是非常不推薦程序員，對公司的業務，進行性能優化的。說這話，純粹是基於個人自身安全考慮。因爲性能優化，在大多數公司，屬於費力不討好的工作項。
追求極簡的代碼，性能卓越的代碼，是有追求的程序員的目標。但隨着經歷了大大小小的公司，我發現很多優秀的程序員，在經受着這種追求的反嗜，以至於痛不欲生。
有下面幾點原因，雖然我們知道它肯定是錯的，但我們無能無力：
公司按照完成的功能，對程序員進行考覈。性能優化屬於額外的工期，也就是浪費成本的一種存在。
團隊不Care程序運行的效率，慢一點無所謂，等出問題了再救火就行。
性能優化的風險大，通常要調整代碼結構，甚至修改代碼邏輯。不優化可能沒事，一優化可能出事，沒人願意碰。
就一句話，整個團隊深陷進行時泥潭，沒有展望性思想，大家就那麼漿糊着，得過且過。
以上是很多公司的現狀，尤其集中在中小型公司。在這種公司裏，除非系統慢到極點，優化之後有效果，或者領導要求你這麼做，否則我都不建議你去碰。如果你執意如此，惹火燒身的時候不要後悔。
當然，有很多團隊的技術氛圍還是很nice的，甚至在代碼review的時候，都會提出一些更優的建議。遇到這樣的團隊，就要珍惜，我們的軍火庫，毫無疑問是爲了這些團隊而準備的。
Brendan D. Gregg大叔，天馬行空過《性能之巔》這本書。但這本書的內容有點深，很多工具都是從資源層面進行分析的。他更廣爲人知的一張圖，就是下面這張工具的集合。當然還有現在無處不在的火焰圖。
這密密麻麻的工具，都是偏低層的，大多數時候，我們用不到。所以xjjdog整理了一個稍微上層的，靠近平常使用習慣的軍火庫。大多數工具，你不需要再使用yum或者apt安裝，都是自帶的。
通用問題發現
如上圖，就是xjjdog平常所使用的性能問題排查工具集合，可以排查一些通用的性能問題，比如CPU、內存、網絡、I/O等。
大多數監控系統，抓取的也都是這些指標。由於這些性能數據都是發生在某一時間的，所以都只能排查問題發生當時的一些性能數據。強烈建議使用監控系統保存這些歷史數據，可以進行問題追隨，不用再傻乎乎等着問題復現了。
專用工具
不過，再怎麼看，上面的這些工具也太零散了，學習的成本比較大，還需要記憶很多參數配置，才能再救火的環境中反應靈敏。
比較幸運的是，有一些可以獲取性能概覽的工具可以幫助我們減少腦細胞的損耗。
就拿top來說，有經驗的同學，僅憑這一個命令，就能夠判斷系統中的資源，是否達到了瓶頸。這樣的工具還有vmstat、sar、nmon等。尤其是nmon，是一個老牌的性能彙總工具，能夠自動生成壓測期間所產生的性能報告。
這裏面的幾個性能深挖工具，學習曲線有點陡峭，但一旦掌握必使你產生主宰的感覺。但很多時候輪不到它們上場，因爲總有一種大炮打蚊子的感覺。
Java專用工具
但是不要忘了，我們是搞Java的，碰到的性能問題，多屬於JVM層面的。就拿perf這個工具來說，很強大，可以追蹤到每一個c語言的函數調用的次數和耗時，但對Java來說是沒用的，它生成的火焰圖也沒用。
所以Java自有一套這樣的解決方案。
不僅有，而且更強大。尤其推薦jmc集成的JFR功能，這個記錄的信息可真是太詳細了。
單機環境下，arthas是調試單機調用耗時的好工具，我不止一次使用它的trace命令完成了性能調優。在分佈式環境下，skywalking類似的分佈式調用鏈工具，也能助我們一臂之力。
END
有人可能覺得，我們上面列出的這些工具命令，實在是太多了，學不完，其實不是這樣的。
在遇到性能問題，想要找到它的具體原因之時，你纔會恨手頭的工具太少，以至於期望有更加強勁的工具。
書到用時方恨少，事非經過不知難。
作爲工程師，我們的工作，就是從這諸多的工具裏，選擇合適的組合，直搗黃龍。
當然，如果你搗的不太對，那後果就不太好了。參考文章開頭的題外話，永遠不要搶着去做這種費力不討好的事情。性能優化這個東西，是一把雙刃劍。可能會讓你扶搖直上，也可能會讓跌入谷底，一切和你所處的團隊有關。