當經歷了無數的日日夜夜，朝九晚九，攻克了無數難關，終于將系統預定功能開發完成，通過測驗，部署上線后，你是否會感覺志得意滿，到達了人生巔峰，高唱無敵是多么寂寞，
現實情況是，如果你這個系統，業務沒有做起來，沒啥人用，huan則罷liao，如果有越來越多的人，持續使用，隨著用戶增多，業務資料增多，那系統一定會暴露一些性能問題，而對這些問題的優化解決，以及監測，往往需要比開發具體功能，更高更全面的技術素質及能力，
一、性能問題監控
鍋叔云：性能問題是具有隱蔽性能，服務器硬體性能良好不等于系統服務性能良好，這么說可能經驗欠缺的同學難于理解，不就是系統慢么，用戶會告訴我們啊？ 我們有服務器監控啊，如果cpu，或者記憶體滿了，會有監控報警啊？
首先，系統慢用戶未必會告訴你，如果比你的競品慢太多，用戶會用腳投票，然后，如果你開發的系統在把硬體跑到瓶頸之前都快如閃電，請收下鍋叔的膝蓋-_-|| ，
常見的性能問題，往往是欠缺性能考慮引起的，回應巨慢的同時，硬體利用率可能5%不到，這類問題也是此次鍋叔主要討論的，
經驗上來說，對于性能問題的監控預警是難于解決具體的性能問題的，實踐中我們需要一些日常機制來篩查系統性能問題，避免病入膏肓，
資料庫慢查詢日志——是一個重要的監控途徑，其中記錄了耗時較長的資料庫操作記錄，可以通過手動或自動分析慢查詢日志，篩查可能存在的性能問題，主流資料庫都支持慢查詢日志生成，具體的配置方式此處不做贅述，非統計類的資料操作通常應該在100ms以下，
介面性能監控——后臺系統通常是通過服務介面向外提供服務的，前端頁面或者移動設備是通過呼叫服務端介面來完成對應操作的，介面的粒度是大于資料庫操作的，一個介面呼叫可能包含很多個資料庫呼叫，介面性能更接近于用戶體驗，因為多數時候用戶的一個操作動作會對應一個服務介面（如保存，確認），在不存在慢查詢的時候，介面性能可能也會不滿足要求，可能的原因如，一個介面回圈呼叫了1000次資料庫操作，或者呼叫了一些第三方介面等，對介面的性能監測原理上就是用呼叫結束的時間減去進入的時間點計算總耗時，并把這個耗時記錄下來，以便時候篩查，Spring的切片能力可以方便的實作該需求，非報表，匯出類介面，鍋叔認為應當在1秒內完成為佳，
訊息佇列——如果你的系統中使用到了類似訊息佇列的機制，對佇列中排隊的訊息數，同樣應當進行監測，訊息如果發生了堆積，說明在這個階段內，系統的整體消費能力已經不能滿足輸出要求了，
以上三個監控維度是互不重疊的，應該同時進行，
二、性能問題的定位
除了資料庫慢查詢日志可以明確提示具體SQL緩慢外，上面另外兩種情況所能直接提示定位到的粒度都比較大，對應一個介面或者一段處理程序代碼，
定位更細問題的具體方法也很容易想到，即分段輸出各階段的耗時，如對于一個100行的方法，可以在第30，60，100，分別計算并日志輸出這3段執行耗費的時間，重復進行，就最終可以定位到將問題所在，
性能問題的定位需要有一些性能常識，所謂性能常識即，通常做一件事情需要完成的時間，不用很準確，但量級要清楚，比如一次資料庫操作，一般在數十毫秒，與記憶體的互動在納秒或者微秒間，與第三方系統的介面可能在數百毫秒到幾秒之間，有了這些經驗我們才能夠對耗時是否合理有個基本判斷，比如對于一個50毫秒的資料庫操作，回圈100次就是5秒，已經很慢了，可以考慮是不是可以合并成一次批量操作，
三、應用性能優化方法
合并遠程呼叫——根據經驗，實踐中因為回圈進行資料庫操作，或對第三方系統介面進行回圈呼叫，是引起性能問題的非常非常常見的原因，對于此類問題的優化方式通常就是優化呼叫的方式，使用批量操作，例如，如果需要去資料庫中查詢鍋叔近一年的打卡記錄，可以用準確日期，查詢365次，也可以用時間范圍一次查詢出365條，后面的方法肯定比前面的快很多，如果方法比較復雜，冗長，可以從中抽取所需的公共資料，進行統一的批量查詢取出，放入記憶體備用，會比哪里用到哪里查要快很多，同樣寫入，修改操作，也盡量批量進行，
使用快取——對于訪問頻率較高的資料，可以在記憶體中存盤，利用記憶體存取要快于硬碟很多的特性，來進行訪問加速，常見的場景如各種計數——鍋叔的文章有多少次瀏覽之類，
多執行緒并行——通過多執行緒把串行修改為并行，例如與設備通信查詢狀態，逐個查詢和并行同時向設備查詢，后者要快得多，現實中多數的操作耗時是在IO上，因此多執行緒方式可以有效提高性能，避免“空”等，多執行緒并行需要注意做好執行緒同步，
四、資料庫性能優化
資料庫是一個現代系統都會依賴的組件，對他的性能問題解決也是開發人員需要掌握的，
增加索引——加索引，是資料庫優化的首選方案，原理是利用空間換時間，現在存盤的成本下降非常快，基本上可以做到常規業務資料查詢都可以走索引，對于復雜的sql 有時需要分析下怎么加索引，可以通過執行計劃來分析，
鎖等待——資料庫是有鎖概念的，一個事務占有X鎖未提交前，其他事務是不能夠對該記錄進行操作的，只能等待，未使用唯一索引的資料庫寫操作，可能會對全表加寫鎖，在提交前，全表記錄無法操作，因此對資料庫鎖，應當有所認識，盡量晚上鎖，盡快解鎖，盡量小范圍上鎖，推論可得，實踐中，如果是長事務，盡量把更新操作后移，把耗時的非事務性操作（如無依賴的第三方介面等），設法從事務中移除，
事務隔離級別——選擇合適的事務隔離級別，事務隔離級別與資料庫鎖有關，如最嚴格的串行隔離級別，所有的事務將串行進行，廣泛使用的資料庫MYSQL，其默認隔離級別為"可重復讀"，但帶來了間隙鎖的限制，增加了鎖搶占的概率，如無特別，可以根據實際情況調整為“讀提交”
中間結果——本質可以理解為資料庫層次的快取，如果一些結果從全量記錄中計算資料量巨大，耗時必然很長，可以分批計算，存盤中間結果，以加速資料取得，如計算鍋叔家近一年的總支出，可以通過每筆記錄加起來，也可以每個月算一次，這樣只需要查詢近12個月的支出加起來就可以啦，
本文來自博客園，作者：鍋叔
轉載請注明原文鏈接：https://www.cnblogs.com/uncleguo/p/16106699.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/456982.html
標籤：Java
下一篇：Java基礎——位元組緩沖流