性能調優 -- 哪些計算機資源有可能成爲系統的性能瓶頸？

• CPU

　　有些應用須要大量計算，會長時間、不間斷地佔用CPU資源，致使其餘資源沒法爭奪到CPU而響應緩慢，從而帶來系統性能問題。好比：代碼遞歸致使的無限循環，正則表達式引發的回溯，JVM頻繁的FULL GC，以及多線程編程形成的大量上下文切換等等，這些都有可能致使CPU資源繁忙。

• 內存   

 　　Java程序通常經過JVM對內存進行分配管理，主要是用JVM中的堆內存來存儲Java建立的對象。系統堆內存的讀寫速度很是快，因此基本不存在讀寫性能瓶頸。可是因爲內存成本比磁盤高，相比磁盤，內存的存儲空間很是有限。因此當內存空間被佔滿時，對象沒法回收，就會致使內存溢出、內存泄漏等問題。

• 磁盤I/O　　

　　磁盤相比內存來講，存儲空間要大不少，但磁盤I/O讀寫速度要比內存慢，雖然目前引入的SSD固態硬盤已經有所優化，但仍然沒法與內存的讀寫速度相提並論。

• 網絡

　　網絡對於系統性能來講，也起着相當重要的做用。若是你購買過雲服務，必定經歷過，選擇網絡帶寬大小這一環節。帶寬太低的話，對於傳輸數據比較大，或者是併發量比較大的系統，網絡就很容易成爲性能瓶頸。　　

• 異常

　　Java應用中，拋出異常須要構建異常棧，對異常進行捕獲和處理，這個過程很是消耗系統性能。若是在高併發的狀況下引起異常，持續地進行異常處理，那麼系統的性能就會明顯地受到影響。　　

• 數據庫

　　大部分系統都會用到數據庫。而數據庫地操做每每是涉及到磁盤I/O的讀寫。大量的數據庫讀寫操做，會致使磁盤I/O性能瓶頸，進而致使數據庫操做的延遲性。對於有大量數據庫讀寫操做的系統來講，數據庫的性能優化是整個系統的核心。　

• 鎖競爭

　　在併發編程中，咱們常常會須要多個線程，共享讀寫操做同一個資源，這個時候爲了保持數據的原子性(即保證這個共享資源在一個線程寫的時候，不被另外一個線程修改），咱們就會用到鎖。鎖的使用可能會帶來上下文切換，從而給系統帶來性能開銷。JDK1.6以後，Java爲了下降鎖競爭帶來的上下文切換，對JVM內部鎖已經作了屢次優化，好比：新增了偏向鎖、自旋鎖、輕量級鎖、鎖粗化、鎖消除等。如何合理地使用鎖資源，也是性能優化時須要注意的一點。

• 響應時間　　

 　　響應時間是衡量系統性能的重要指標之一，響應時間越短，性能越好，通常一個接口的響應時間是在毫秒級。在系統中，咱們能夠把響應時間自下而上細分爲如下幾種：

1. 數據庫響應時間：數據庫操做所消耗的時間，每每是整個請求鏈中最耗時的；
2. 服務端響應時間：服務端包括nginx分發的請求所消耗的時間以及服務端程序執行所消耗的時間；
3. 網絡響應時間：這是網絡傳輸時，網絡硬件須要對傳輸的請求進行解析等操做所消耗的時間；
4. 客戶端響應時間：對於普通的Web、App客戶端來講，消耗時間是能夠忽略不計的，但若是你的客戶端嵌入了大量的邏輯處理，消耗的時間就有可能變長，從而成爲系統的瓶頸。

• 吞吐量

　　在測試中，咱們每每會比較注重系統接口的TPS(每秒事務處理量)，由於TPS體現了接口的性能，TPS越大，性能越好。在系統中，咱們也能夠把吞吐量自下而上地分爲兩種：磁盤吞吐量和網絡吞吐量