背景

最近給第三方做了一個接口，接口的作用是接收數(shù)據(jù)對數(shù)據(jù)進(jìn)行驗證之后通過kafka推送到模型進(jìn)行數(shù)據(jù)處理，最終通過kafka接收模型的數(shù)據(jù)，開始只做了一個異步的接口，由于對方業(yè)務(wù)原因需要一個同步的接口傳輸數(shù)據(jù)，但是每當(dāng)運行一段時間之后程序就會進(jìn)入假死狀態(tài)，接口無法正常調(diào)用；

同步接口

同步接口的實現(xiàn)是使用阻塞Map，當(dāng)對方發(fā)送請求時，對數(shù)據(jù)進(jìn)行驗證，然后推送到模型，等待結(jié)果返回之后將處理好的數(shù)據(jù)推送到對方接口，此時這次請求給調(diào)用方返回相應(yīng)信息；

思路

開始認(rèn)為是由于用戶量過大導(dǎo)致內(nèi)存不足引發(fā)的程序假死，使用JMeter進(jìn)行壓力測試異步接口模擬10000個請求同時調(diào)用接口，程序如絲滑般運行，沒有絲毫問題，所有請求都正常返回（這里由于在家里通過VPN連接的公司開發(fā)服務(wù)器，網(wǎng)絡(luò)不穩(wěn)定，所以就拿少量測試用例為例）；

image

然后開始懷疑是不是同步接口出了問題，剛開始模擬少量請求，因為當(dāng)時是在開發(fā)環(huán)境進(jìn)行測試，模型并沒有放上去，所以沒有返回信息，一直在等待模型的返回結(jié)果，也是沒有問題的，這時候調(diào)用異步接口也沒有任何問題；

思考：所有資源都是阻塞狀態(tài)，因為沒有處理結(jié)果，一直沒有釋放進(jìn)程，當(dāng)數(shù)據(jù)過大時會不會造成服務(wù)器資源耗盡，導(dǎo)致程序假死？

image

當(dāng)再次加大同步接口的調(diào)用次數(shù)的時候，再去嘗試請求異步接口，發(fā)現(xiàn)異步接口也沒有了返回信息，這時遍確認(rèn)了問題所在；

線程全部在阻塞狀態(tài)，當(dāng)太多資源沒有釋放掉時，服務(wù)器資源耗盡，導(dǎo)致程序無法正常運行；

解決

找到問題之后就是要解決問題，去掉同步接口是不可能的，所以要給阻塞的線程設(shè)置一個超時時間，當(dāng)長時間沒有等到模型的處理數(shù)據(jù)時，主動放棄監(jiān)聽，釋放掉占用的資源，從而保證服務(wù)器資源充足；

思考

雖然問題解決了，但是模型的數(shù)據(jù)產(chǎn)出最長達(dá)10秒鐘，當(dāng)并發(fā)量過大時還是會出現(xiàn)這種問題，在不動模型的情況下如何解決這種問題？如何一直保證服務(wù)器資源充足？