三萬字盤點 Spring 九大核心基礎功能
大家好，我是三友~~今天來跟大家聊一聊Spring的9大核心基礎功能。話不多說，先上目錄：圖片友情提示，本文過長，建議收藏，嘿嘿嘿！一、資源管理資源管理是Spring的一個核心的基礎功能，不
垃圾回收對于Javaer來說是一個繞不開的話題，工作中涉及到的調優工作也經常圍繞垃圾回收器展開。面對不同的業務場景沒有一個統一的垃圾回收器能保證可GC性能。因此對程序員來說不僅要會編寫業務代碼，同時也要卷一下JVM底層原理和調優知識。這種局面可能因為ZGC的出現而發生改變，新一代回收器ZGC幾乎不需要調優的情況下GC停頓時間可以降低到亞秒級。
Oracle從JDK11開始正式引入ZGC，ZGC設計三大目標：
ZGC是如何設計怎么達到這個目標的呢？本文將從ZGC算法的關鍵特性入手，通過分析ZGC周期處理過程來理解這些特性，探索ZGC設計思想。
非分代：將對內存劃分為新生代和老年代 (G1已經邏輯分代) ，ZGC取消分代設計，每個GC周期都將標記整個堆中的所有活動對象。
頁面：ZGC將堆空間分解成一塊塊區域，這些區域叫做頁面，ZGC通過頁面來回收內存。
并發性：GC和線程和業務線程同時運行。ZGC的高度并發設計，幾乎所有GC工作、標記和堆碎片整理都是和業務線程 (mutators) 同時運行的，只包含了短暫的STW同步暫停。
并行：多個線程進行GC線程同時工作，加快回收速度。
標記-復制算法：標記-復制算法主要包括以下3個過程。
標記-復制算法的最大優勢就是防止堆內存碎片化的出現，復制的過程就可以對堆內存進行整理。ZGC、CMS和G1都是采用了標記-復制算法，但是不同的實現導致了很大的性能差異。
ZGC設計致力于提供幾毫秒的最大暫停時間，同時保證吞吐量不受影響。下面是SPECjbb2015針對OpenJDK中的不同收集器運行的性能測試數據。在128G堆內存下，無論是延遲還是吞吐量上面ZGC的性能表現都高于其他收集器。
ZGC的周期是高度并發的，并發性越高意味著GC工作時對業務線程的影響越小，SPECjbb2015的性能報告可以看出ZGC在延遲上比G1低10倍以上，ZGC的工作周期只有三個階段是STW的，其他階段完全并發。這得益于ZGC在堆視圖并發一致性設計上的改進。我們都清楚在并發的場景下需要協調各個線程對共享資源達成一致性，常用的手段就是對資源加鎖，而在垃圾回收器下的思路也是類似，如果GC線程工作是需要鎖定對象資源進行處理，業務線程則需要全部暫停，這就產生了STW (Stop The Word) 。以往的垃圾回收器都是讓GC線程和業務線程就堆中對象地址達成一致，對象在發生轉移時業務線程是不能訪問的 (因為對象的地址發生了變化) ，無論G1還是CMS對象在進行復制時都是需要STW。ZGC使用到的著色指針（Colored Pointer）和讀屏障（Load Barrier）技術，可以讓所有線程在并發的條件下就指針的顏色 (狀態) 達成一致，而不是對象地址。因此，ZGC可以并發的復制對象，這大大的降低了GC的停頓時間。我們先對著色指針和讀屏障有個初步的理解，然后在通過ZGC回收周期來看這2項技術的具體運用。
著色指針(Colored Pointer)
在指針中嵌入元數據（使用地址中的高階位來實現），這種通過在指針存儲元數據的技術就叫做著色指針 (Colored Pointer) 。ZGC中指針始終是64位結構，由元位（指針的顏色）和地址位組成。地址位數決定了理論上支持的最大堆大小，ZGC使用42位存儲地址也就意味著ZGC最大支持4TB堆內存。如圖所示，低42位是地址位，中間4位是元位，高18位未使用。四個元位是Finalized ( F )、Remapped ( R )、Marked1 ( M1 ) 和Marked0 ( M0 )。
ZGC中將指定上的標記通過顏色來表示，顏色可以是“good” (地址有效) 或“bad” (地址可能無效) 。指針的顏色由其元位的狀態決定：F、R、M1和M0。“good”是R、M1、M0元位中的一個被設置，另外三個未設置，比如0100、0010和 0001屬于“good”顏色。通過在指針上的顏色就能區分出對象狀態，不用額外做內存訪問，這使得ZGC在標記和轉移階段會更快。
通過設置地址元位的狀態，可以形成不同地址視圖，ZGC同一物理堆內存被映射到虛擬地址空間三次，從而產生同一物理內存的三個“視圖”，GC活動的不同時期會只存在一個活躍視圖，根據垃圾回收的周期ZGC通過切換不同視圖標來記出對象的顏色。
下圖是虛擬地址的空間劃分：
[0~4TB) 對應Java堆；
[4TB ~ 8TB) 稱為M0地址空間；
[8TB ~ 12TB) 稱為M1地址空間；
[12TB ~ 16TB) 預留未使用；
[16TB ~ 20TB) 稱為Remapped空間。
ZGC是不分代的，這意味著垃圾回收是需要掃描整個堆空間，地址視圖將整個Java堆分成多個部分，并為每個部分分配一個虛擬內存段。在垃圾回收時，ZGC只需要掃描其中一個虛擬內存段，并將其作為當前視圖映射到實際的內存位置。同時，ZGC會將其他虛擬內存段映射到虛擬地址上，這些內存段不會被收集器掃描。
讀屏障(Load Barrier)
ZGC 通過利用讀屏障而不是寫入屏障，與HotSpot JVM中以前的GC (CMS，G1等) 算法顯著不同。讀屏障解決了并發轉移時對象指針更新問題：在轉移期間，如果移動對象而不用更新引用對象的傳入指針（移動的對象可能被堆中的任何其他對象所引用），就會產生懸空指針 (已經被釋放的內存空間或者無效的內存地址，訪問懸空指針會出現問題) 。通過讀屏障技術能夠捕獲此類懸空指針對象，并觸發代碼，更新對象的新位置，從而“修復”懸空指針。為了跟蹤對象如何移動，以便在加載時固定懸空指針，ZGC中使用轉發表 (forwarding tables ) 來將重定位前（舊）地址映射到重定位后（新）地址。無論是業務線程作為使用者訪問對象，還是GC線程遍歷堆中的所有活動對象（在標記期間）都有可能會觸發讀屏障。
ZGC讀屏障如何實現呢？舉個例子，代碼 var x = obj.field。x是一個位于堆棧上的局部變量，field是一個位于堆上的指針。業務線程在操作堆對象時觸發讀屏障。讀屏障的執行路徑有快 (fast path) 和慢 (slow path) 兩種，如果正在加載的指針有效狀態 (good color) ，則采用加載屏障的快速路徑，否則，采用慢速路徑。快速路徑實際上是空的，而慢速路徑包含計算有效狀態指針的邏輯：檢查對象是否已經（或即將）重新定位，如果是，則查找或生成新的地址。讀屏障除了能讓觸發讀屏障的線程讀取到最新地址，同時還具有自我修復指針（self-healed）的功能，這意味著讀屏障會修改指針的狀態，以便后續其他線程訪問時能執行快速路徑。無論采用哪條路徑，都會返回正確狀態的地址。下面用偽代碼表示ZGC在執行讀屏障時的大體邏輯：
/**slot 是值線程棧中的局部變量，也就是屏障要操作的目標對象*/unintptr_t barrier(unintptr_t *slot,unintptr_t addr){ //快速路徑,fast path if(is_good_or_null(addr))return addr; //慢速路徑,slow path good_addr = process(addr); //自我修復 self_heal(slot,addr,good_addr); return good_addr;}/*自我修復，將指針恢復到正常狀態*/void self_heal(unintptr_t *slot,unintptr_t old_addr,unintptr_t new_addr){ if(new_addr == 0)return; while(true){ if(CAS(slot,&old_addr,new_addr) return; if(is_good_or_null(old_addr)) return; }}ZGC的讀屏障可能被GC線程和業務線程觸發，并且只會在訪問堆內對象時觸發，訪問的對象位于GC Roots時不會觸發，這也是掃描GC Roots時需要STW的原因。
下面是一個簡化的示例代碼，展示了讀屏障的觸發時機。
Object o = obj.FieldA // 從堆中讀取引用，需要加入屏障<Load barrier>Object p = o // 無需加入屏障，因為不是從堆中讀取引用o.dosomething() // 無需加入屏障，因為不是從堆中讀取引用int i = obj.FieldB //無需加入屏障，因為不是對象引用如下圖 所示，ZGC 周期由三個 STW 暫停和四個并發階段組成：標記/重新映射( M/R )、并發引用處理( RP )、并發轉移準備( EC ) 和并發轉移( RE )。為了讀者能快速理解，下面對ZGC執行過程進行了大量簡化。
初始標記(STW1)
ZGC 初始標記執行包含三個主要任務。
GC周期中地址視圖窗口
并發標記(M/R)
并發標記的任務有2個：
第一，并發標記線程從待標記的對象列表出發，根據對象引用關系圖遍歷對象的成員變量，遞歸進行標記。
第二，計算，并更新關聯頁面的活躍度信息。活動信息是頁面上的活動字節數，用于選擇將要回收的頁面，這些對象將作為堆碎片整理的一部分進行重新定位。
下面偽代碼是并發標記的主要過程：
while(obj in mark_stack){ //標記存活對象,當且僅當該對象未被標記并且當前線程成功標記該對象時才返回true success = mark_obj(obj); if(success){ for(e in obj->ref_fields()){ MarkBarrier(slot_of_e,e); } }}//GC線程調用//EC是待回收頁面的集合void MarkBarrier(uintptr_t *slot,unintptr_t addr){ if(is_null(addr))return; //判斷是否在待回收集合內 if(is_pointing_into(addr,EC)){ //地址重映射到當前GC視圖 good_addr = remap(addr); } else { good_addr = good_color(addr); } //訪問的對象添加到標記棧 mark_stack->add(good_addr); self_heal(slot,addr,good_addr);}//讀屏障前面有介紹過，由業務線程調用void LoadBarrier(uintptr_t *slot,unintptr_t addr){ if(is_null(addr))return; if(is_pointing_into(addr,EC)){ good_addr = remap(addr); } else { good_addr = good_color(addr); } mark_stack->add(good_addr); self_heal(slot,addr,good_addr); return good_addr;}再標記階段(STW2)
再標記階段的主要任務有3個：
并發轉移準備(EC)
并發轉移準備任務：
初始轉移(STW3)
初始轉移主要以下過程：
初始轉移是STW的，其處理時間和GC Roots的數量成正比，一般情況耗時非常短。
并發轉移（RE）
初始轉移完成了GC Roots對象重定位，在并發轉移階段將對前面步驟確定的轉移集 (EC) ，對轉移集的每一頁執行轉移。
并發轉移的過程可以抽象成如下偽代碼過程：
//GC線程主循環遍歷EC的頁面，將個將EC集頁面中對象進行轉移for (page in EC){ for(obj in page){ relocate(obj); }}//該方法GC和業務線程都有可能執行,如果是業務線程訪問對象會先進行轉移在進行操作unintptr_t relocate(unintptr_t obj) { //獲取對象的地址轉發表 ft = forwarding_tables_get(obj); if (ft->exist(obj)){ return ft->get(obj); } new_obj = copy(obj); //CAS寫對象轉發表數據 if(ft->insert(obj,new_obj)){ return new_obj; } //CAS發生競爭，寫轉發表失敗，釋放分配的內存 dealloc(new_obj) return ft->get(obj);}轉發表的作用是存儲對轉移后舊地址到新地址的映射，轉發表的數據存儲在頁面中，轉移完成的頁面即可被回收掉。
并發轉移完成之后整個ZGC周期完成。
為了說明ZGC算法，下圖演示了示例中的所有階段。
圖8(1)顯示了堆的初始狀態，應用啟動后ZGC完成了初始化。
在圖8(2)中，選擇M0作為全局標記，并且所有根指針都被標記成M0。然后，所有根都被推送到標記堆棧，該標記堆棧在并發標記 (M/R) 期間由GC線程消耗。
如圖8(3)所示，圖中用合適的顏色繪制對象本身，以表明它們已被標記，即使指針有狀態。
在圖8(4) 中，選擇存活對象最少的頁面（中間的頁面）作為轉移候選集 (EC) 。
隨后，在圖8(5)中，全局標記被設置為Remmaped，并且所有根指針都已更新Remmaped。如果根指向EC，則相應的對象將被重新定位，并且根指針更新為新地址。
在圖8(6)中，EC中的對象被轉移，并且地址記錄被逐出頁面中轉發表上，用于新舊地址轉換。當并發轉移階段結束時，當前GC周期也會結束。當前周期內整個EC都會被回收。這里可能有個疑問，對象的舊地址還沒有更新，頁面如果被回收了如何還能訪問對象呢？原因是回收的是頁面中對象存儲空間，轉發表不會被回收，如果此時業務線程訪問這些對象，會觸發讀屏障的慢路徑位，失效指針會被修復。對于沒有訪問到的失效指針，直到下一個GC并發標記 (M/R) 階段才會被修復。
在圖8(7)中，下一個GC循環開始，M1被選擇為全局狀態（M0 和 M1 之間交替使用）。
在圖8(8)中，并發標記階段 (M/R) 通過查詢轉發表失效的指標被映射到新位置。
最后，在圖8(9)中，上一周期EC頁面的轉發表被回收，為即將到來的并發轉移 (RE) 階段做準備。
ZGC是一個十分復雜的JVM子系統，沒辦法通過一篇文章把所有的細節描述清楚。本文詳細探討了ZGC的著色指針和讀屏障關鍵技術，他們也是ZGC中創新點，最后通過一個示例對ZGC算法過程做了一個簡化版的演示。通過對ZGC這種復雜系統的學習，讓我也體會到分析復雜系統時沒必要一開始就過多的糾結實現細節，可以先從關鍵流程入手再層層深入。
ZGC的高并發設計造就了它的高性能，背后要歸功于著色指針和讀屏障運用，當然除了這2項還有其他精妙的設計比如：內存模型，并發模型，預測算法等這里不展開，讀者可以參考其他文章。了解ZGC的基本原理可以幫助優化應用程序的性能，為應用調優做些知識儲備。最后，ZGC有卓越的性能和穩定性表現，我們在選擇GC選型時可以優先考慮使用ZGC。
參考內容：
[1]彭成寒:《新一代垃圾回收器ZGC設計與實現》.機械工業出版社, 2019.
[2]https://tech.meituan.com/2020/08/06/new-zgc-practice-in-meituan.html
[3]https://www.baeldung.com/jvm-zgc-garbage-collector
[4]https://openjdk.org/projects/zgc/
[5]https://www.jfokus.se/jfokus18/preso/ZGC--Low-Latency-GC-for-OpenJDK.pdf
本文鏈接：http://www.tebozhan.com/showinfo-26-10687-0.htmlZGC關鍵技術分析
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： AR與VR的五大關鍵區別
下一篇： 數據工程中的單元測試完全指南
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號