一、排查過程

問題發現是因為當時接到了記憶體UMP報警信息，如下：

通過查看PFinder發現記憶體一直在增長，沒有停止跡象，觸發fullGC也並沒有下降趨勢：

當機立斷，先立即去NP上摘除了此台機器流量，然後繼續觀察，發現記憶體依然在不斷增長。

隨即查看故障分析，並沒有得到有效信息：

因為流量已經摘除，那麼繼續觀察到底哪裡的問題，約半小時後然後接到了機器的宕機告警如下：

由於在應用啟動參數里配置了dump路徑，那麼就馬上去把dump文件下載下來分析。

隨後找到對應IP機器的目錄，下載了dump文件java_pid432.hprof核對時間沒有問題，隨即使用MAT工具開展分析，通過泄露分析結果直接就可以看出problem1與problem2都是一個同一個問題，2個線程分別占用1.8G、1.5G：

通過查看問題對應的代碼類方法，發現該方法功能是"導出WMS保質期商品數據"，該方法會調用庫存分頁介面查詢保質期商品，大致如下：

1、查詢無數據直接導出空表；

2、第一頁查詢總量小於1000的話直接把數據寫入第一個sheet並導出表格；

3、第一頁查詢總量大於1000則迴圈分頁查詢，每1000條數據生成一個sheet表格進行導出。

可以看到，org.apache.poi.hssf.usermodel.HSSFWorkbook對象數量已經達到702個了。

翻看具體代碼部分如下：

二、解決思路

經過對該功能代碼分析，本著先解決問題的原則，先將迴圈調用功能進行限制，通過ducc配置導出頁數大小限制，來避免一直迴圈調用。

至此，問題初步解決完畢，調整後沒有出現問題。

但是，這個功能的優化並沒有結束，隨後將該問題及功能邏輯反饋給產品及庫存相關方，一起討論解決商家導出的問題，一方面我們要保障商家體驗，另一方面又要確保系統穩定性。後續要從這2方面入手進行功能的優化，不斷為提升商家體驗而努力。

三、總結分析

回過頭來咱們再分析以下這個功能，通過系統日誌及監控，發現該功能商家日常使用較少，並且大部分商家的保質期商品較少，極少數會存在有非常多保質期商品數據的情況。但是一旦出現這樣的問題就會很致命，所以在導出功能設計之初我們就應該考慮到將來任何可能出現的情況，並做好提前的預防。另外就是要做功能的限制，例如導出次數、導出數據量的限制功能來保障商家體驗及系統的安全穩定。

另外再說一下，對導出功能的理解，對於商家而已，導出需求是正常的。但是過多大批量數據的一起導出無論對哪個系統來說都是非常危險的一個功能。以下列舉了一些個人總結的導出功能設計時的一些常見規則，希望大家一起參與討論分析，拙見如下：

• 明確導出數據的價值分析
• 明確導出數據的使用傾向
• 明確導出數據的安全要求
• 明確導出數據的許可權控制
• 明確需要導出的數據量級
• 明確導出數據的方式方法
• 明確到倉數據的頻率頻次
• 明確導出數據的性能效率
• 明確導出數據的限制方法
• 明確導出功能的隔離及降級方案
• 明確導出數據的格式樣式
• 明確導出數據的下載方案
• 明確導出數據的錯誤監控

以上是個人想到的一些導出設計的簡單規則，需要產研測一起溝通明確，還希望大家多提提意見，一起完善導出規則。

另外我們再從商家角度來考慮一下導出的目的，個人從詢問業務及相關人員，發現商家導出數據有以下一些目的：

• 存儲歸檔方便查歷史資料
• 利用系統業務數據進行數據分析已指導商家業務工作或給領導彙報工作
• 導出來使用表格工具等其他商家熟悉的工具進行查看，更便捷便利
• 對導出的數據進行加工，並用於其他非京東系統的數據輸入
• 無意識的導出並無其他作用

以上是個人總結的一些商家導出的需求目的，其實針對商家導出來說可能還有很多其他目的，我們不能全部都能瞭解。但是可以積極與商家溝通理解商家的真實目的。

另外，我們需要去分析商家的訴求，挖掘商家需求背後的目的。假如有個服裝行業的商家需要做服務訂單業務數據、庫存數據分析，是否我們可以利用數智側的系統能力，為商家打造通用的數據分析能力呢，這樣既可以避免導出數據手動分析的雞肋，同時也提升了商家對京東物流的系統使用體驗。

以上僅僅代表個人觀點，一點愚見，還請大家批評指正！

歡迎大家一起探討！

作者：京東物流 劉鄧忠

來源：京東雲開發者社區 自猿其說Tech 轉載請註明來源