一、排查過程
問題發現是因為當時接到了記憶體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 轉載請註明來源