記一次文件句柄泄漏致使的崩潰

最近項目上遇到好幾個崩潰問題，解決過程有點曲折，在此記作個記錄。

項目背景介紹：該項目爲語音識別實時分析系統，整套系統架構以下：

　　 

接連幾回崩潰的是中間的語音流接入系統，崩潰的狀況以下：

　　一、打開文件過多報錯，致使系統直接卡死。

　　二、打開線程過多，致使系統直接崩潰。

　　三、Jetty容器異步支持bug。

 

第一次崩潰：打開文件過多

　　首先在日誌中大量的刷屏，由於咱們的語音流接入系統只是一箇中間轉發的服務，這個服務當時是從實時語音分析服務中剝離出來的，當時剝離出來的主要目的是下降實時語音分析服務的帶寬壓力，因此當出現這個問題後，直接指向的是有網絡鏈接沒有釋放。

　　既然肯定了排查方向，使用lsof命令，好傢伙，該進程直接佔了六萬多個文件句柄，其中eventpoll佔了一萬六千多個，打開的pipe有三萬三千多個，就這兩項就佔了近五萬個句柄。項目上部署的這套系統最高併發爲預計的3000路通話，即便在最高通話併發的狀況下，也不可能佔用這麼多句柄數，因此狀況就是有鏈接沒有釋放，致使句柄泄漏，並逐漸累積到這個數目，驗證這個狀況，使用netstat，果真發現大量的鏈接一直沒有釋放。

　　 

　　好了，鎖定了目標，接下來就是排查代碼中沒有正確釋放的地方。

　　如最上，一通新通話進來時，咱們的語音流接入系統會接入兩個語音流併發送給語音識別服務進行識別，在這個過程當中，語音流發送是一個持續的過程，而且咱們要確保同一個語音流由同一臺機器進行識別。因此在新語音流進來時，咱們的接入系統與識別服務之間會建立一個session，當通話結束時銷燬這個session，這個session在咱們的語音流接入系統（如下簡稱接入系統）中是和語音流ID即streamId一一對應的，在一個流推送結束後咱們要根據streamId進行session的關閉。結果在代碼中有一個地方，原本應該是傳streamId的，可是結果卻傳成了toString（這個錯誤很低級！），好了，找到這個地方修改後，項目從新上線。（但是幸福不會來的這樣忽然！）

 

第二次崩潰：打開線程過多

　　當上面覺得問題解決後，次日線上直接報出進程崩潰的問題，查看崩潰日誌，裏面大量的線程阻塞，一個進程竟然有三萬個線程。

　　 

　　遇到這個狀況也只能結合代碼去分析這些線程是在哪裏起的了。由於這個接入系統只是一箇中間商，因此起線程的地方只有三個，一個是接入語音流的地方，一個是接收識別結果的地方，剩下的就是推送識別結果。查看語音抓包系統併發數正常，而識別結果推送是同步的，可是咱們在接收識別結果的時候採用的是異步接口，而每收到一個識別結果的時候都會看成一個任務加入線程池等待執行。那麼這時，積壓只能是在接收識別結果這裏了。（說明：在前面經過打時間戳的方式已經確認過了接入系統和分析服務之間發送和接收速度不一致，由於分析服務拿到識別結果後還會有後續的模型、流程分析處理，因此這就是一個典型的快生產者慢消費者問題。）

　　針對上面的分析結果，確認是消費者過慢問題，那麼快生產者就應該進行控制，查看代碼，發如今處理接收的識別結果的時候，咱們使用的線程池是newCachedThreadPool，因此由於這個緣由，當分析服務這邊接收過慢時，接入系統在接收識別服務的識別結果時就只能建立大量的線程去等待執行。針對這個狀況，因此改成使用newFixedThreadPool。（還有就是若是消費者過慢的話，提升消費者處理能力纔是正解，因此後面也有對分析服務的優化，提升響應時間。）

　　因此在使用生產者消費者模型的時候，能夠有快生產者慢消費者存在，可是二者之間的處理速度不該該相差過大，更不能說是沒有消費者（當分析服務崩潰或者阻塞就是這種狀況。）

 

第三次崩潰：Jetty容器異步支持bug

　　再通過上面兩次bug修復後，覺得問題完全解決了，可是仍是一樣的到項目上跑上一天後，又出現了崩潰問題。對於這一次從日誌裏面分析，仍是文件句柄佔用耗盡而崩潰，分析這些連接，發現仍是咱們的接入系統和識別服務之間有大量的鏈接沒有釋放。這讓人很疑惑，通過最終的確認，全部的鏈接之間都有獲得正確的釋放。而後注意到了以前一直被忽略的一條錯誤日誌：

　　 

　　最終確認jetty容器在拋出該異常後，會致使異步回調永遠得不到調用，這樣的話就會使得咱們的接入系統和識別服務之間的鏈接可能由於異步回調沒有獲得調用而致使鏈接得不到釋放。（當時使用的jetty版本是9.4.12）

 

　　線上的每一次崩潰都讓個人當心髒跳動加速一倍，活着不易，且行且珍惜！