1.请简述 JVM 垃圾回收原理。

• 將 JVM 堆中已經不再被使用的對象清理掉，釋放內存資源

• 通過一種可達性分析算法進行垃圾對象識別

• 垃圾對象 - 沒有被引用的對象

標示過程

• 從線程棧幀中的局部變量，或方法區中的靜態變量出發

• 將這些變量所引用的對象進行標記

• 若引用的對象內部引用了其他對象，繼續進行標記

• 被標記的對象都是被使用的對象

• 沒有被標記的對象就是可回收的垃圾對象

回收方法

清理

• 將垃圾對象佔據的內存清理

• JVM 將所占內存空間

• 標示為空閒

• 記錄在一個空閒列表

• 下次創建新對象時，從列表中找一個適合大小的空閒空間分配給新對象

• 會產生碎片的空閒空間

• 回收幾次後，碎片會越來越多

壓縮

• 從堆空間頭部開始

• 將存活的對象拷貝放在一段連續的內存空間中

• 其餘空閒空間也是連續的空閒空間

複製

• 將堆空間分成兩部分

• 只在其中一部分創建對象

• 當這一部分空間用完時，將標記可用對象複製到另外一個空間中

回收策略 - 分代回收



• Java 對象大部分生存時間很短暫

• 將生存時間很短的對象，創建在較小的區域

• 回收範圍小

• 可快速回收

分成新生代、老年代

• 新生代

• Eden 區

• 初始對象創建區

• From 區

• 若Eden 區滿了進行垃圾回收

• 將可用對象複製至此區

• To 區

• 若 From 滿了，連同 Eden 區與 From 區進行垃圾回收

• 將可用對象複製至此區

• 在 From 與 To 區交叉進行回收與複製

• 老年代

• 在新生代交叉回收與複製後，會產生一些生命周期很長的對象

• 將這些對象複製至此區

• Young GC

• 對新生代進行回收

• Full GC

• 全量垃圾回收

• 新生代、老年代一起回收

回收器算法



串行回收器

• 所有應用程序線程停止

• 對應用線程影響很大

• stop-the-world 時間也算進響應時間內

• 啟動一個垃圾回收線程

• 標記對象

• 回收

• 早期 Java 運行在單核 CPU 使用

並行回收器

• 所有應用程序線程停止

• 對應用線程影響很大

• stop-the-world 時間也算進響應時間內

• 針對多核 CPU ，啟動多個垃圾回收線程

並發回收器 (CMS)

• 初始化標記

• 所有應用線程停下

• 啟動標記線程

• 並發標記

• 標記線程與應用線程一起執行

• 重標記

• 所有應用線程停下

• 啟動重新標記線程

• 因為前一個並發標記時，應用程序可能改變物件引用狀態

• 並發清理

• 清理線程與應用線程一起執行



• stop-the-world 時間比較短，對應用線程影響比較小

G1回收器



• 將內存空間分成更小的區域

• 默認為2000個區域

• 區域越小，垃圾對象標記、清理也越快

• 每個區域也區分不同的分代角色，進行分代回收

• 利用 -XX:MaxGCPauseMillis 進行 stop-the-world暫停時間控管

• 期望 GC 暫停時間的最大值

• G1 回收器根據這個時間，動態調整回收策略

设计一个秒杀系统，主要的挑战和问题有哪些？核心的架构方案或者思路有哪些？

技術挑戰

• 瞬間高並發

• 帶寬耗盡

• 服務器崩潰，猶如 DDOS 攻擊

• 確保使用戶遵循秒殺規則

• 第一類秒殺器: 秒殺前不斷刷新頁面

• 第二類秒殺器: 跳過秒殺頁面，直接進入下單頁面

核心架構方案思路

與原系統隔離

• 避免修改影響原系統

• 部屬一個新的秒殺服務器集群

• 避免對原系統重構，增加新功能開發難度及時間

• 根據新的秒殺系統需求，進行最適化設計

簡單化設計

• 避免複雜的業務流程

• 用戶端流程簡化

• 砍掉不重要的分枝流程

• 如開通支付接口

• 延遲部分流程，分散並發

• 如訂單完成之後的支付流程

• 使用原有支付及訂單管理系統

• 經過層層篩減，秒殺成功後對支付及訂單管理系統的並發量不大

• 避免重新驗證金流正確性

降低高並發影響

• 利用緩存 (CDN，反向代理)，降低對系統的負載

• 將動態頁面轉成靜態頁面

• 也可減少數據庫存取

• 規範商品圖片大小

• 降低帶寬需求

• 精簡優化頁面

• 減少 HTTP 請求數

• 精簡 CSS，JS

• 圖片合併

• HTML 內容壓縮

• 設置閥門，控制訪問流量，降低後端系統負擔

防止秒殺器干擾

• 閥門可有效防止第一類秒殺器

• 最後一刻動態生成 URL，可防止第二類秒殺器

降低運營複雜性

• 依秒殺商品列表，定時自動產生靜態頁面