一般瓶頸分以下五種情況：
1. 硬件上的性能瓶頸
一般指的是CPU，內存，磁盤I/O方面的問題，分爲服務器硬件瓶頸，網絡瓶頸（對局域網可以不考慮），服務器操作系統瓶頸（參數配置），中間件瓶頸（參數配置，數據庫，web服務器等），應用瓶頸（sql語句，數據庫設計，業務邏輯，算法等）。
(1) 磁盤I/O：磁盤的讀寫速度遠慢於內存的讀寫速度，系統運行時如果需要等待磁盤I/O的完成，將導致整個系統的性能下降；
(2) CPU性能：應用對CPU的佔用時間不同，應用時間對CPU的搶佔也將導致系統性能受到影響；
(3) 網絡狀態：網絡本身存在不確定性，其讀寫速度可能比磁盤I/O還要慢，所以網絡狀態也可能成爲系統性能的一個瓶頸；
(4) 異常的處理：Java對異常的捕獲和處理是一項非常消耗資源的操作；
(5) 數據庫的讀寫：當應用可能進行海量數據的讀寫時，數據庫操作將帶來想不到的時間消耗，可能影響整個系統的響應；
(6) 鎖競爭：在高併發的程序中，對鎖的競爭必將產生很大的上下文切換開銷，對系統造成的性能影響也是不可小覷的；
(7) 負載承受能力：一個應用可能同時會接收到上百萬的訪問請求，這時應用將面臨巨大的響應壓力，可能導致服務器宕機；
(8) 內存大小：有時候內存過小可能導致一些操作無法完成，導致系統崩潰，這時也可能爲了解決內存不足問題採用分佈加載資源到內存中，這又導致了磁盤I/O問題。
2. 應用軟件上的性能瓶頸
一般指的是應用服務器，web服務器等應用軟件，還包括數據庫系統；
例：中間件weblogic平臺上配置的JDBC連接池的參數設置不合理，造成的瓶頸。
3. 應用程序上的性能瓶頸
一般指的是開發人員新開發出來的應用程序；
例：程序架構規劃不合理，程序本身設計有問題（串行處理，請求的處理線程不夠）造成系統在大量用戶訪問時性能低下而造成的瓶頸。
4. 操作系統上的性能瓶頸
一般指的是windows，UNIX，Linux等操作系統；
例：在進行性能測試，出現物理內存不足時，虛擬內存設置也不合理，虛擬內存的交換效率就會大大降低，從而導致行爲的響應時間大大增加，這時認爲操作系統上出現性能瓶頸。
5. 網絡設備上的性能瓶頸
一般指的是防火牆，動態負載均衡器，交換機等設備；
例：在動態負載均衡器上設置了動態分發負載的機制，當發現某個應用服務器上的硬件資源已經達到極限時，動態負載均衡器將後續的交易請求發送到其他負載輕的應用服務器上，在測試時發現，動態負載均衡器沒有起到相應的作用，這時可以認爲網絡瓶頸。
性能瓶頸的具體表現：
| 性能瓶頸出現頻次 | 具體表現 |
|---|---|
| 高 | TPS波動較大 |
| 高 | 高併發下大量報錯 |
| 中 | 集羣類系統，各服務節點負載不均衡 |
| 中 | 併發數不斷增加，TPS上不去，CPU耗用不高 |
| 低 | 壓測過程中TPS不斷下降，CPU使用率不斷降低 |
1. TPS波動較大
原因分析：出現TPS波動較大問題的原因一般有網絡波動、其他服務資源競爭以及垃圾回收問題這三種。
性能測試環境一般都是在內網或者壓測機和服務在同一網段，可通過監控網絡的出入流量來排查；
其他服務資源競爭也可能造成這一問題，可以通過Top命令或服務梳理方式來排查在壓測時是否有其他服務運行導致資源競爭；
垃圾回收問題相對來說是最常見的導致TPS波動的一種原因，可以通過GC監控命令來排查，命令如下：
#實時打印到屏幕
jstat -gc PID 300 10
jstat -gcutil PID 300 10
#GC信息輸出到文件
jstat -gc PID 1000 120 >> /path/gc.txt
jstat -gcutil PID 1000 120 >> /path/gc.txt
調優方案：
網絡波動問題，可以讓運維同事協助解決（比如切換網段或選擇內網壓測），或者等到網絡較爲穩定時候進行壓測驗證；
資源競爭問題：通過命令監控和服務梳理，找出壓測時正在運行的其他服務，通過溝通協調停止該服務（或者換個沒資源競爭的服務節點重新壓測也可以）；
垃圾回收問題：通過GC文件分析，如果發現有頻繁的FGC，可以通過修改JVM的堆內存參數Xmx，然後再次壓測驗證（Xmx最大值不要超過服務節點內存的50%！）
2. 高併發下大量報錯
原因解析：出現該類問題，常見的原因有短連接導致的端口被完全佔用以及線程池最大線程數配置較小及超時時間較短導致。
短連接問題：修改服務節點的tcp_tw_reuse參數爲1，釋放TIME_WAIT socket用於新的連接。
線程池問題：修改服務節點中容器的server.xml文件中的配置參數，主要修改如下幾個參數：
#最大線程數，即服務端可以同時響應處理的最大請求數
maxThreads = "200"
#Tomcat的最大連接線程數，即超過設定的閾值，Tomcat會關閉不再需要的socket線程
maxSpareThreads = "200"
#所有可用線程耗盡時，可放在請求等待隊列中的請求數據，超過該閾值的請求將不予處理，返回Connection refused錯誤
acceptCount = "200"
#等待超時的閾值，單位爲毫秒，設置爲0時表示永不超時
connectionTimeout = "20000"
3. 併發數不斷增加，TPS上不去，CPU使用率較低
原因分析：SQL沒有創建索引/SQL語句篩選條件不明確，代碼中設有同步鎖，高併發時出現鎖等待
SQL問題：沒有索引就創建索引，SQL語句篩選條件不明確就優化SQL和業務邏輯
同步鎖問題：是否去掉同步鎖
4. 集羣類系統，各服務節點負載不均衡
原因分析：出現這類問題的原因一般是SLB服務設置了會話保持，會導致請求只分發到其中一個節點。
調優方案：如果確認是如上原因，可通過修改SLB服務（F5/HA/Nginx）的會話保持參數爲None，然後再次壓測驗證；
5. 壓測過程中TPS不斷下降，CPU使用率不斷降低
原因分析：一般來說，出現這種問題的原因是因爲線程block導致，當然不排除其他可能；
調優方案：如果是線程阻塞問題，修改線程策略，然後重新驗證即可；
參考博客：https://www.cnblogs.com/imyalost/p/10850811.html