線上服務穩定了好幾個月，這兩天抽風，總是有mysql資料行被鎖，update會報錯（lock wait timeout exceeded; try restarting transaction）
導致系統無法使用，害得我得一直在後台給使用者解鎖（通過mysql的kill命令）/(ㄒoㄒ)/~~
極光sdk版本（接入sdk時從官方文件複製的，一直沒更新，可誰沒事會去更新這個呢）：
cn.jpush.api
jpush-client
3.2.15
cn.jpush.api
jiguang-common
1.0.1
io.netty
netty-all
4.1.6.final
由於之前一直後台功能一直正常，並沒有往**方面想，找了一天資料庫原因未果（尼瑪的）！
經過一天觀察，發現只有遇到極光推送的地方才會加鎖，而且是不定時出現，故重點觀察極光推送**（為log4j新增了列印執行緒id的配置）！
第一步：通過觀察log，發現極光推送之後該執行緒在log中再也不出現了（只列印了關鍵**3中lasthttpcontent判定邏輯中的語句，死鎖的原因）
通過jps和jstack定位到了極光sdk的死鎖問題（真坑）:
第二步：分析原因
關鍵**1：cn.jiguang.common.connection.nettyhttpclient.sendhttprequest:158
countdownlatch latch = new countdownlatch(1);// 注意此處例項化了乙個countdownlatch 並傳遞給了nettyclientinitializer
latch.await();// 等待繼續執行，這個地方使用countdownlatch的作用就是等待netty非同步網路呼叫返回結果後繼續執行，所以此處等待，如果netty執行完後不countdown執行緒將永遠等待在這個地方
} catch (interruptedexception e)
}關鍵**2：cn.jiguang.common.connection.nettyclientinitializer.initchannel:25
關鍵**3:cn.jiguang.common.connection.httpresponsehandler
此段**在異常時（
exceptioncaught）也未進行countdown呼叫，也會死鎖！！！著實讓人堪憂啊！
最後通過公升級了極光的sdk解決了死鎖問題！！！
總結：countlatchdown一定要注意countdown，否則就會死鎖，掛住執行緒不提交事務，造成資料庫行鎖。
並且查詢資料庫事務表看到的執行sql是null，並沒有正在執行的sql，應該就可以判定是事務未提交，分析為什麼未提交就好了！
記一次mysql死鎖問題排查
2019.10.05 15 20 16字數 543閱讀 7 隔壁同事大佬 專案用的mysql資料庫引擎是innodb，資料庫的行鎖 表鎖是通過innodb使用表的索引來實現的。那麼就先查詢一下innodb的狀態 show engine innodb status 只擷取有用資訊 latest det...
記錄排查一次公司OOM的過程
公司新上線一次，引發oom，增大記憶體，重啟。未發生，然後又重啟，一天之後又發生了。根據上次上線的內容去挨個功能順藤摸瓜。發現了這個地方。根據日誌,發現是oom的問題.從大的方面來講,主要採取了兩個步驟 1.讓gc日誌跑起來,觀察到馬上進行fullgc之前,執行命令進行dump命令 jmap dum...
記錄第一次排查ANR經歷
第一步 找到logcat中的報錯記錄 第二步 拿到 檢視traces檔案 data anr traces.txt 1 人家說在這個目錄下，但是我不知道怎麼找，搜到取這個檔案的文章 adb pull data anr traces.txt users atom downloads 2 adb指令不會用...