多執行緒引發的血案

我們的微服務閘道器執行出現了兩次的自動下線，然後看日誌並沒有報錯資訊。所以我們初步懷疑是linux自己把這個程序給殺掉了。

我們剛開始使用下面的命令，並沒有發現有kill的日誌

dmesg | egrep -i -b100 '

killed process
'# 或者
egrep -i '
killed process
' /var/log/messages
egrep -i -r '
killed process
' /var/log
# 或者
journalctl -xb | egrep -i '
killed process
'

ps p 516866 -l -o pcpu,pmem,pid,tid,time,tname,cmd

然後使用

jstack -l 516866 > jstack.log

可以看到 有很多my-thread-1的執行緒在waiting，這樣的話我們就可以通過我們的**尋找可能導致問題的原因

因為執行緒有相應的名字，那麼我們就可以通過這個名字定位到相應的**

我們可以看到這段**是消費kafka的資料，然後對資料進行乙個處理。其中使用了執行緒池。

這段**的問題出在了，沒來一條資料就會建立乙個執行緒池，所以導致建立了大量的執行緒，最後導致cpu暴增。

後來對**的修改

我們把建立執行緒池的**使用靜態**塊的方式，然後來一條資料需要處理的時候，去執行緒池中獲取就行。

我們將**重新部署後，再使用

signed unsigned 引發的血案

bug描述 問題產生於區域網傳輸一幅。服務端負責傳送，是由另乙個同事用c 寫的，我用c 寫接收客戶端。我們約定在傳輸一幅前，先傳固定4個位元組的size資訊，然後傳資料。結果發現有些總是末尾壞掉一截或是乾脆就傳不過來。bug原因 在我接收到size 4 後，我採用了size size 3 256 2...

merge all引發的血案

在訓練深度神經網路的時候，我們經常會使用dropout，然而在test的時候，需要把dropout撤掉.為了應對這種問題，我們通常要建立兩個模型，讓他們共享變數。詳情.為了使用tensorboard來視覺化我們的資料，我們會經常使用summary，最終都會用乙個簡單的merge all函式來管理我們...

parseInt引發的血案

今天做了個專題活動,頁面頭上有個倒計時 專題做完後上線了,沒發現有什麼問題,結果,運營mm突然和我說 技術哥哥出問題了,360瀏覽器在秒數從10到09的時候直接變成 00 了 一看我去真的,該死的360 還有ie7 這個倒計時的原理是先獲取系統時間.分鐘,秒,毫秒賦值在span上面 span id ...