前因：本人目前從事雲計算後端應用開發，一次大批量創建虛擬機，發現隨着機器量越來越多，我負責的java應用處理同一個方法越來越慢，通過日誌輸出時間，高的長達30分鐘，我去，還不瘋掉。。。於是一開始藉助java本身的Jconsole進行監控，但是效果不直觀，不能追蹤我想要監控的方法執行哪個步驟導致處理慢，於是硬着頭皮直接用JProfiler進行分析，這個工具熟悉了使用真的很不多，廢話不多說，接下來具體說說如何使用以及注意事項。
步驟：因爲我是windows開發，應用部署在linux上，所以我做的是本地監控遠程linux服務器上的java應用，進行監控。
1、首先windows本地需要安裝一個JProfiler客戶端，下載鏈接：https://www.ej-technologies.com/download/jprofiler/files，圖如下：
大家各自按照自己系統版本進行選擇，我本地是64位的。沒錢就選擇先試用體驗下，哈哈。。。
下載好後按照提示進行安裝即可，沒啥複雜度，就不截圖演示。
2、由於需要監控的是linux上的應用，所以需要安裝它的服務端，圖如下：
這裏選擇linux上的TAR.GZ進行下載，下載後，需要上傳到linux上，並進行解壓，上傳目錄隨意定。以下是我解壓後的截圖：
3、如何啓動服務端
首先進入到上圖的bin目錄下，即： cd 你解壓開來的文件夾/bin, 找到jpenable這個程序
然後執行 ./jpenable, 這時候會出現讓你選擇分析模型，我們輸入1選擇界面模型，
然後會提示輸入一個分析端口，注意這個端口就是我們接下來要本地windows進行遠程連接的端口號，我們照着輸入一遍即可，圖如下：
到此，我們的服務端已經啓動好了，還等什麼呢，接下里打開客戶端，進行連接吧
4、客戶端如何遠程連接服務端
首先打開客戶端程序，第一次打開如下：
點擊圖示的按鈕，會出現圖如下，我們按照圖示步驟執行即可：
第1步我們選擇Quick Attach 快速連接
第2步選擇連接另一臺電腦，即我們上面所說的linux電腦，當然也可以選擇第一個按鈕，監控本地電腦運行的應用
第3步我們下拉框選擇直接連接
第4步我們需要輸入我們要監控應用所在的服務器地址
第5步我們輸入我們在上面第3點安裝服務端時， 輸入的端口號
第6步我們點擊start按鈕，即可開始監控了
5、開始分析
連接上打開如圖：
可以看到左邊樹形菜單還是有很多內容項的，別怕，我們看幾個主要的性能指標：cpu、memory、threads、GC Activity、Databases
5.1 cpu性能分析
我們點擊左邊的CPU Load, 打開如圖：
從趨勢圖看，我們的cpu負載一直沒有超過20%，最高峯的有兩個參數，綠色的代表進行佔用的負載爲17.7%，系統佔用的爲18.45%，兩者相差不大，可以說明目前我們的應用cpu負載沒問題.
5.2 memory性能分析
我們點擊左邊的Memory, 打開如圖：
我們可以看到藍色和藍色高度相差很多，看數字表明，綠色是空閒的大小，藍色是已使用的大小，一半藍和一半綠代表已經提交的內存大小，我們可以得出，如果綠色和藍色相差高度越多，說明內存性能很好，反之，內存使用率較高，這時候我們需要看下我們應用所在的機器物理內存是否需要增加內存以及看下我們是否設置了應用啓動時候分配過初始內存或者最大內存限制，比如我的內存就根據實際物理內存做了分配大小限制，如：java -Xms1024m -Xmx4000m -jar xxxx.jar，至於參數以及如何設置，不在這裏討論，可以看看java參數優化文章，這裏提供一個僅做參考：https://blog.csdn.net/u013068377/article/details/78613645
5.3 threads性能分析
我們點擊左邊的Threads, 打開如圖：
我們從白框中可以得知，當前線程狀況，一目瞭然，我們可以判斷出，當前是否因爲線程很忙還是線程不夠，導致程序變慢等因素產生。
5.4 GC Activity性能分析
我們點擊左邊的GC Activity, 打開如圖：
我們可以看出，系統應用執行GC的情況，有時候因爲頻繁執行GC會導致應用暫停，如果是這樣，我們需要看下堆棧信息，是否因爲設置的堆太小，導致GC發現空間不夠，頻繁執行回收內存了
5.5 Databases性能分析
我們點擊左邊的Databases, 打開如圖：
因爲我的是jdbc，如果你是其他數據庫連接，點擊Databases下面相應數據庫即可。由圖可知我們當前應用連接的所有數據庫連接信息
5.5.1數據庫連接數量性能分析
我們點擊Connections,查看當前的連接數，如圖：
由圖可知，我們看出當前一個數據庫是6個連接，一個是20個數據庫連接，這裏需要注意下，如果我們有大批量併發，那麼這麼點連接數是不夠的，一旦數據庫獲取不到連接，就會處於等待，這樣就會導致應用執行變慢，所以這時候我們應該查看下，我們應用設置的數據庫連接池大小，一般看三個參數設置，min.idle（最小空閒等待數）、max.idle（最大空閒等待數）、max.active（最大連接數），因爲我們知道，數據庫連接資源很寶貴，頻繁的創建銷燬是需要消耗性能的，這裏的大小數我們需要根據我們的應用併發量進行響應設置，如果我們的應用併發量在100，那麼我們的max.idle和max.active就不能設置太小，一般設置150就可以了，設置小了，就會導致批量創建會耗時，因爲等待獲取數據庫連接。
5.5.2 數據庫執行語句性能分析
我們點擊Hot Spots,查看當前應用執行sql語句的頻率以及耗時情況，如圖：
由圖我們可以看出，sql執行耗時情況一目瞭然，Time：總耗時時間，Average Time：平均耗時，Events：執行總數
通過對此進行分析，我們可以知道我們的程序對數據庫執行情況，通過對慢語句發分析，一我們可以優化語句，二針對業務進行相應優化調整等等
好了，本次先說這麼多，因爲此工具真的很強大，有太多東西，下次再分享，如果哪裏有不妥之處，歡迎不吝指教。
寫此內容一記錄下自己的歷程，方便以後回顧，二分享出來希望幫到有此問題需要分析的同學，謝謝！