### 垃圾收集器
> 基于分代收集
#### Serial收集器
> Serial(串行)收集器收集器是最基本、歷史最悠久的垃圾收集器了。大家看名字就知道這個收集器是一個單線程收集器了。它的 **“單線程”** 的意義不僅僅意味著它只會使用一條垃圾收集線程去完成垃圾收集工作,更重要的是它在進行垃圾收集工作的時候必須暫停其他所有的工作線程( **"Stop The World"** ),直到它收集結束。
**新生代采用復制算法,老年代采用標記-整理算法。**
#### ParNew收集器
> **ParNew收集器其實就是Serial收集器的多線程版本,除了使用多線程進行垃圾收集外,其余行為(控制參數、收集算法、回收策略等等)和Serial收集器完全一樣。**
**新生代采用復制算法,老年代采用標記-整理算法。**
#### Parallel Scavenge收集器
> **Parallel Scavenge收集器關注點是吞吐量(高效率的利用CPU)。CMS等垃圾收集器的關注點更多的是用戶線程的停頓時間(提高用戶體驗)。所謂吞吐量就是CPU中用于運行用戶代碼的時間與CPU總消耗時間的比值。** Parallel Scavenge收集器提供了很多參數供用戶找到最合適的停頓時間或最大吞吐量,如果對于收集器運作不太了解的話,手工優化存在的話可以選擇把內存管理優化交給虛擬機去完成也是一個不錯的選擇。
**新生代采用復制算法,老年代采用標記-整理算法。**
#### CMS收集器
> CMS收集器是一種**“標記-清除”算法**實現的
* **初始標記:** 暫停所有的其他線程,并記錄下直接與root相連的對象,速度很快 ;
* **并發標記:** 同時開啟GC和用戶線程,用一個閉包結構去記錄可達對象。但在這個階段結束,這個閉包結構并不能保證包含當前所有的可達對象。因為用戶線程可能會不斷的更新引用域,所以GC線程無法保證可達性分析的實時性。所以這個算法里會跟蹤記錄這些發生引用更新的地方。
* **重新標記:** 重新標記階段就是為了修正并發標記期間因為用戶程序繼續運行而導致標記產生變動的那一部分對象的標記記錄,這個階段的停頓時間一般會比初始標記階段的時間稍長,遠遠比并發標記階段時間短
* **并發清除:** 開啟用戶線程,同時GC線程開始對為標記的區域做清掃。
缺點:
* **對CPU資源敏感;**
* **無法處理浮動垃圾;**
* **它使用的回收算法-“標記-清除”算法會導致收集結束時會有大量空間碎片產生。**
#### G1收集器
* **并行與并發**:G1能充分利用CPU、多核環境下的硬件優勢,使用多個CPU(CPU或者CPU核心)來縮短Stop-The-World停頓時間。部分其他收集器原本需要停頓Java線程執行的GC動作,G1收集器仍然可以通過并發的方式讓java程序繼續執行。
* **分代收集**:雖然G1可以不需要其他收集器配合就能獨立管理整個GC堆,但是還是保留了分代的概念。
* **空間整合**:與CMS的“標記--清理”算法不同,G1從整體來看是基于“標記整理”算法實現的收集器;從局部上來看是基于“復制”算法實現的。
* **可預測的停頓**:這是G1相對于CMS的另一個大優勢,降低停頓時間是G1 和 CMS 共同的關注點,但G1 除了追求低停頓外,還能建立可預測的停頓時間模型,能讓使用者明確指定在一個長度為M毫秒的時間片段內。
> **G1收集器在后臺維護了一個優先列表,每次根據允許的收集時間,優先選擇回收價值最大的Region(這也就是它的名字Garbage-First的由來)**。這種使用Region劃分內存空間以及有優先級的區域回收方式,保證了GF收集器在有限時間內可以盡可能高的收集效率(把內存化整為零)。
- 虛擬機
- JVM內存結構
- JVM調優手段
- java對象生命周期
- 垃圾回收判斷對象死亡
- 垃圾回收算法
- 垃圾收集器
- JAVA基礎知識
- java事件機制
- java反射機制
- jvm創建對象
- java異常
- finally語句一定會執行嗎?
- 集合類介紹
- ArrayList
- LinkedList
- HashMap
- ConcurrentHashMap
- 多線程
- 為什么要使用線程池
- 線程死鎖
- 死鎖檢測和解除
- jstack
- jconsole
- 死鎖預防
- 常見線程池
- 線程池參數
- 工作隊列介紹
- 拒絕策略
- ThreadLocal
- CAS
- ReentrantLock
- AQS
- CountDownLatch
- Spring
- spring中bean的作用域
- REDIS
- redis數據結構
- redis hash實現
- redis rehash與hashmap擴容的區別
- Redis使用場景
- Redis為何這么快
- redis連接數不足導致錯誤
- 分布式
- 分布式事務
- ACID
- CAP
- BASE
- 事務隔離性
- 一致性哈希算法
- 負載均衡算法
- Hystrix 信號量和線程池隔離的差異
- Spring Cloud
- eureka
- MYSQL
- mysql優化經驗
- undo redo binlog
- web
- http協議
- http和https區別
- Cookie和session
- TCP三次握手、4次揮手
- TCP的time_wait和close_wait
- 算法問題
- 編輯距離算法
- MQ
- RabbitMq
- Kafka
- 安裝教程
- Win ELK安裝