一、接口響應時間從100ms飆升至2s，如何排查？

只有調用時間飆升，CPU和內存使用率均正常。

可能的原因：

• 線程池阻塞：導致請求堆積，網關觸發限流
• 外部依賴延遲：第三方接口調用超時
• 資源競爭：死鎖
• 等等等

排查方向：

• 檢查線程的狀態，比如：
  top 命令：找到最耗cpu的進程；
  top -H -p 進程id 命令：找到進程中最耗cpu的線程；
  jstack 命令：查看線程狀態
• 分析依賴服務性能：慢SQL、鎖等待、緩存命中。。。
• 檢查JVM垃圾回收：通過 jstat 查詢GC的頻率和回收時間， 是否頻繁觸發 full gc
• 網絡與連接池的診斷：網絡波動
• 日志分析：數據庫日志、系統日志

二、如何定位線上OOM？

1 原因：

• 一次性申請的太多：更改申請對象數量
• 內存資源耗盡未釋放：找到未釋放的對象進行釋放
• 本身資源不夠：使用 jmap -heap 查看堆信息

2 定位：

系統已經OOM掛了：導出Dump文件

• 提前設置，-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=

系統運行中還未OOM：

• 導出dump文件，jmap -dump:format=b,file=xushu.hprof 14660
• Arthas

結合jvisualvm 進行調試：

• 查看最多跟業務有關對象->找到GCRoot ->查看線程棧

三、如何定位、避免死鎖？

原因：并發下線程因為相互等待對方資源，導致“永久”阻塞的現象；

定位：

• jps 命令：查看正在運行的 Java 進程的進程 ID，查找死鎖的進程 id；
• jstack 命令：查看死鎖的進程；

預防：

• 不使用互斥鎖；
• A 同時鎖住自己和對方的資源，避免互相競爭；
• Lock 的鎖超時機制；

四、