背景
最近給第三方做了一個接口腿倚，接口的作用是接收數(shù)據對數(shù)據進行驗證之后通過kafka推送到模型進行數(shù)據處理驮俗，最終通過kafka接收模型的數(shù)據西乖，開始只做了一個異步的接口，由于對方業(yè)務原因需要一個同步的接口傳輸數(shù)據简僧，但是每當運行一段時間之后程序就會進入假死狀態(tài)建椰，接口無法正常調用；
同步接口
同步接口的實現(xiàn)是使用阻塞Map岛马，當對方發(fā)送請求時棉姐，對數(shù)據進行驗證，然后推送到模型啦逆，等待結果返回之后將處理好的數(shù)據推送到對方接口伞矩，此時這次請求給調用方返回相應信息；
思路
開始認為是由于用戶量過大導致內存不足引發(fā)的程序假死蹦浦，使用JMeter進行壓力測試異步接口模擬10000個請求同時調用接口扭吁，程序如絲滑般運行，沒有絲毫問題，所有請求都正常返回（這里由于在家里通過VPN連接的公司開發(fā)服務器侥袜，網絡不穩(wěn)定蝌诡，所以就拿少量測試用例為例）；
然后開始懷疑是不是同步接口出了問題枫吧，剛開始模擬少量請求浦旱，因為當時是在開發(fā)環(huán)境進行測試，模型并沒有放上去九杂，所以沒有返回信息颁湖，一直在等待模型的返回結果，也是沒有問題的例隆，這時候調用異步接口也沒有任何問題甥捺；
思考：所有資源都是阻塞狀態(tài)，因為沒有處理結果镀层，一直沒有釋放進程镰禾，當數(shù)據過大時會不會造成服務器資源耗盡，導致程序假死唱逢？
當再次加大同步接口的調用次數(shù)的時候吴侦，再去嘗試請求異步接口，發(fā)現(xiàn)異步接口也沒有了返回信息坞古，這時遍確認了問題所在备韧；
線程全部在阻塞狀態(tài)，當太多資源沒有釋放掉時痪枫，服務器資源耗盡织堂，導致程序無法正常運行；
解決
找到問題之后就是要解決問題听怕，去掉同步接口是不可能的捧挺，所以要給阻塞的線程設置一個超時時間楼熄，當長時間沒有等到模型的處理數(shù)據時子漩，主動放棄監(jiān)聽蛇摸，釋放掉占用的資源需忿，從而保證服務器資源充足端蛆；
思考
雖然問題解決了刽漂，但是模型的數(shù)據產出最長達10秒鐘眨层，當并發(fā)量過大時還是會出現(xiàn)這種問題锁右，在不動模型的情況下如何解決這種問題疏旨？如何一直保證服務器資源充足很魂？
