鑽石舞台

一 背景1 多模態知識圖譜

一 前言

一 引言

前言

閒魚服務端應用廣泛使用 Java 技術棧，基於JVM提供的託管式堆內存管理，開發者無需過多關心對象創建/回收時的內存分配/釋放動作，垃圾回收器（Garbage Collector）會在需要的時候自動清理堆內不再使用的對象，保證有可用空間用於新對象分配。開發者在享受到自動內存管理的便利時，也不可避免的需要承擔垃圾回收器在進行死亡對象清理時的一些開銷，例如機器資源利用率上升，應用線程被短暫暫停等。根據JVM使用的垃圾回收算法的不同以及回收的堆區域的不同，GC過程中用戶線程的暫停時間、完成一次GC的耗時、也有所不同。其中，全堆內存清理（Full GC，下稱FGC）會掃描整個堆空間，清理掉所有死亡對象，而FGC是Stop the world（下文簡稱STW）的，也就是意味着會暫停全部的用戶線程直到GC結束。一趟FGC的停頓時長視堆空間大小和存活對象數量多少而定，通常從幾秒到幾十秒不等。在這期間，應用無法對外提供任何服務，表現為接口超時，成功率下降，上游依賴線程池打滿等，十分影響用戶體驗，甚至可能出現訪問壓力轉移到其他健康機器上，使得健康機器對象分配壓力增大，最終產生FGC而導致集群雪崩。對於前台業務應用而言，正常承接業務流量的過程中產生的對象大部分都為朝生夕滅的對象，理論絕大部分對象上應該能通過新生代GC（YGC）被清理掉；而大部分GC算法，都是在老年代占用空間超過一定閾值時，才會觸發FGC。因此，一旦出現了FGC，通常意味着這個應用的對象分配或垃圾回收相關的JVM參數存在問題，是業務運行時的重大隱患，需要儘快排查並根治。本文通過三則前台應用FGC調優案例，分別介紹了由於JVM參數、中間件配置、業務代碼層面引起的FGC的現象、分析過程及對應解法。希望能起到拋磚引玉的作用，以及給有同樣疑惑的讀者朋友們帶來一些啟發。

前言

作者介紹：文景睿，花名幕辰，Github名luckysmg，一名來自哈爾濱工業大學軟件工程系的大四學生，在閒魚技術團隊實習了三個月。先後參與了閒魚音視頻編輯器，圖片編輯器的改版升級，以及Flutter Engine優化等相關工作，這篇文章主要是個大家分享一下我來實習的這段時間的一些心得體會。