背景
該項目是利用vue框架開發(fā)的內(nèi)部異常監(jiān)控系統(tǒng)，用于顯示java程序運行時的異常信息，包括執(zhí)行棧、代碼、變量等信息的顯示。
測試過程中，部門同事反映多次在不同異常信息之間切換會導(dǎo)致網(wǎng)頁崩潰。在犯罪現(xiàn)場打開chrome的任務(wù)管理器，看到這個頁面的內(nèi)存占用已經(jīng)達到9.7G，初步懷疑頁面有漏洞。
驗證猜測
打開 devtool -> performance，開始記錄頁面性能執(zhí)行頁面上切換其它異常信息的操作（頁面最有可能引起內(nèi)存泄漏的操作）查看性能分析結(jié)果去掉beforeDestroy鉤子后，業(yè)務(wù)層看起來好多了。
驗證 利用 performance 功能，多次進行之前導(dǎo)致內(nèi)存溢出的操作，得到結(jié)果如下
這里的每個峰值都是剛執(zhí)行操作時內(nèi)存分配的結(jié)果，每次執(zhí)行后沒有內(nèi)存、節(jié)點、Listensers的積累
再次修正前比較性能分析結(jié)果
可怕的樓梯。。。
順便再 memory 面板中出現(xiàn)了什么變化
還有一個StackFrameVar和一些額外的事件偵聽器和觀察器來呈現(xiàn)這個StackFrameVar對象。這是由于兩次呈現(xiàn)的數(shù)據(jù)不同，這是正常情況
例外等。許多對象的增量已經(jīng)是0(與增量的順序相反)
其他說明
上面的分析圖是在寫這篇文章的過程中寫回一些代碼后實時分析的，相對沒有實際調(diào)試的詳細。在實際調(diào)試過程中還進行了其他操作:
隱私窗口，禁用所有擴展（避免影響內(nèi)存分析）關(guān)閉開發(fā)模式HMR功能，因為 VUE_HOT_RELOAD 也會產(chǎn)生一層引用，我并不能完全信任它使用模擬數(shù)據(jù)，每次執(zhí)行操作，都會渲染一樣的可被人工計算清楚(知道哪個類會產(chǎn)生多少實例)的數(shù)據(jù)performance 過程中手動GC以上方法是為了提供一個完全純凈可控的分析環(huán)境。
1.《內(nèi)存溢出 記一次網(wǎng)頁內(nèi)存溢出分析及解決實踐》援引自互聯(lián)網(wǎng)，旨在傳遞更多網(wǎng)絡(luò)信息知識，僅代表作者本人觀點，與本網(wǎng)站無關(guān)，侵刪請聯(lián)系頁腳下方聯(lián)系方式。
2.《內(nèi)存溢出 記一次網(wǎng)頁內(nèi)存溢出分析及解決實踐》僅供讀者參考，本網(wǎng)站未對該內(nèi)容進行證實，對其原創(chuàng)性、真實性、完整性、及時性不作任何保證。
3.文章轉(zhuǎn)載時請保留本站內(nèi)容來源地址，http://f99ss.com/fangchan/702612.html
卡槍 
