ZGC以被動回收為主隧土，即由后臺線程控制何時(shí)啟動垃圾回收。 ZGC的觸發(fā)時(shí)機(jī)在
jdk11/src/hotspot/share/gc/z/zDirector.cpp
ZDirector決定是否要執(zhí)行GC的后臺線程
線程出發(fā)的條件是根據(jù)一個自定義的時(shí)鐘轻局。
void ZDirector::run_service() {
// Main loop
while (_metronome.wait_for_tick()) {
sample_allocation_rate();
const GCCause::Cause cause = make_gc_decision();
if (cause != GCCause::_no_gc) {
ZCollectedHeap::heap()->collect(cause);
}
}
}
GCCause::Cause ZDirector::make_gc_decision() const {
// Rule 0: Timer
if (rule_timer()) {
return GCCause::_z_timer;
}
// Rule 1: Warmup
if (rule_warmup()) {
return GCCause::_z_warmup;
}
// Rule 2: Allocation rate
if (rule_allocation_rate()) {
return GCCause::_z_allocation_rate;
}
// Rule 3: Proactive
if (rule_proactive()) {
return GCCause::_z_proactive;
}
// No GC
return GCCause::_no_gc;
}
目前有4種情況可以自動的觸發(fā)ZGC.
1,基于一個固定時(shí)間觸發(fā)
這個時(shí)間可以通過ZCollectionInterval，來控制屡谐，缺省值為0魂爪，表示不需要。
product(uint, ZCollectionInterval, 0, \
"Force GC at a fixed time interval (in seconds)") \
bool ZDirector::rule_timer() const {
if (ZCollectionInterval == 0) return false;
// Perform GC if timer has expired.
const double time_since_last_gc = ZStatCycle::time_since_last();
const double time_until_gc = ZCollectionInterval - time_since_last_gc;
return time_until_gc <= 0;
}
2,預(yù)熱規(guī)則觸發(fā)
指的是當(dāng)Hotspot剛啟動時(shí)哩盲，當(dāng)發(fā)現(xiàn)heap使用率達(dá)到整個堆的10/20/30%前方，并且其他類型的GC都還沒執(zhí)行時(shí)狈醉，會主動地觸發(fā)GC。當(dāng)其他類型的GC出發(fā)后惠险，會判斷是否還需要預(yù)熱舔糖，如果需要繼續(xù)執(zhí)行，不需要則不再執(zhí)行莺匠。預(yù)熱的的條件是 GC發(fā)生的次數(shù)不超過3次。
bool ZDirector::is_warm() const {
return ZStatCycle::ncycles() >= 3;
}
bool ZDirector::rule_warmup() const {
if (is_warm()) {
// Rule disabled
return false;
}
// Perform GC if heap usage passes 10/20/30% and no other GC has been
// performed yet. This allows us to get some early samples of the GC
// duration, which is needed by the other rules.
const size_t max_capacity = ZHeap::heap()->current_max_capacity();
const size_t used = ZHeap::heap()->used();
const double used_threshold_percent = (ZStatCycle::ncycles() + 1) * 0.1;
const size_t used_threshold = max_capacity * used_threshold_percent;
log_debug(gc, director)("Rule: Warmup %.0f%%, Used: " SIZE_FORMAT "MB, UsedThreshold: " SIZE_FORMAT "MB",
used_threshold_percent * 100, used / M, used_threshold / M);
return used >= used_threshold;
}
3,根據(jù)分配速率
在這里使用到正態(tài)分布十兢，我們在代碼里面能看到兩個相關(guān)的應(yīng)用：根據(jù)內(nèi)存分配的情況估算內(nèi)存被消耗完還可能要多長時(shí)間趣竣；根據(jù)垃圾回收的時(shí)間估算進(jìn)行一次垃圾回收的時(shí)間。
在G1中我們介紹到垃圾回收時(shí)間的估算使用的是衰減平均（Decaying Average）旱物，它是一種簡單的數(shù)學(xué)方法遥缕，用來計(jì)算一個數(shù)列的平均，核心是給近期的數(shù)據(jù)更高的權(quán)重宵呛，即強(qiáng)調(diào)近期數(shù)據(jù)對結(jié)果的影響单匣。衰減平均計(jì)算公式如下：
式中 ɑ 為歷史數(shù)據(jù)權(quán)值，1?ɑ 為最近一次數(shù)據(jù)權(quán)值宝穗。即 ɑ 越小户秤，最新的數(shù)據(jù)對結(jié)果影響越大，最近一次的數(shù)據(jù)對結(jié)果影響最大逮矛。不難看出鸡号，其實(shí)傳統(tǒng)的平均就是 ɑ 取值為 (n?1)/n 的情況。具體可以參考《JVM G1源碼分析和調(diào)優(yōu)》
ZGC中主要是基于正態(tài)分布來估算须鼎，學(xué)過概率論的同學(xué)大都知道這一概念鲸伴。為了讀懂這段代碼，我們先來回顧一下正態(tài)分布晋控。首先它是一條中間高汞窗，兩端逐漸下降且完全對稱的鐘形曲線。圖形形狀為：
正態(tài)分布也非常容易理解赡译，它指的大多數(shù)數(shù)據(jù)應(yīng)該集中在中間附近仲吏，少數(shù)異常的情況才會落在兩端。
對于垃圾回收算法中的數(shù)據(jù)：內(nèi)存的消耗時(shí)間捶朵，垃圾回收的時(shí)間也應(yīng)該符合這樣的分布蜘矢。注意，并不是說G1中的停頓預(yù)測模型不正確或者效果不好综看；而是說使用正態(tài)分布來做預(yù)測有更強(qiáng)的數(shù)學(xué)理論支撐品腹。在使用中ZGC還是對這個數(shù)學(xué)模型做了一些改變。
通常使用N表示正態(tài)分布红碑，假設(shè)X符合均值為μ方差為σ2的分布舞吭，做數(shù)學(xué)變換令Y = （X - μ）/ σ則它符合N(0, 1)分布泡垃。如下所示：
假設(shè)已知內(nèi)存分配的時(shí)間符合正態(tài)分布，我們可以獲得抽樣數(shù)據(jù)羡鸥，從而估算出內(nèi)存分配所需時(shí)間的均值和方差蔑穴。這個均值和方差是我們基于樣本數(shù)據(jù)估算得到的，它們可能和實(shí)際真實(shí)的均值和方差有一定的誤差惧浴。所以如果我們直接使用這個均值和方差可能由樣本數(shù)據(jù)波動導(dǎo)致不準(zhǔn)確存和，所以在概率論中引入了置信度和置信區(qū)間。簡單的說置信區(qū)間指的是這個參數(shù)估計(jì)的一段區(qū)間衷旅，它是這個參數(shù)的真實(shí)值有一定概率落在測量結(jié)果的周圍的程度捐腿。而置信度指的是就是這個概率。
假定給定一個內(nèi)存分配花費(fèi)的時(shí)間X1柿顶， X2茄袖， …, Xn，我們想要知道在99.9%的情況下內(nèi)存分配花費(fèi)的時(shí)間嘁锯。點(diǎn)估計(jì)量符合：
其中μ為樣本均值宪祥，σ樣本標(biāo)準(zhǔn)差。
對應(yīng)99.9%置信度家乘，查標(biāo)準(zhǔn)正態(tài)分布表得到統(tǒng)計(jì)量為3.290527蝗羊。
。所以可以得到最大的內(nèi)存消耗在滿足99.9%的情況下不會超過
烤低。在ZGC中對這個公司又做了一點(diǎn)修改肘交，實(shí)際上是把這個值變得更大：
。Tolerance缺省值為2扑馁，這樣的結(jié)果使得置信度更高涯呻，即遠(yuǎn)大于99.9%。同理對于垃圾回收的時(shí)間也類似處理腻要。理解了置信區(qū)間和置信度下面的代碼非常簡單复罐。
bool ZDirector::rule_allocation_rate() const {
if (is_first()) {
// Rule disabled
return false;
}
// Perform GC if the estimated max allocation rate indicates that we
// will run out of memory. The estimated max allocation rate is based
// on the moving average of the sampled allocation rate plus a safety
// margin based on variations in the allocation rate and unforeseen
// allocation spikes.
// Calculate amount of free memory available to Java threads. Note that
// the heap reserve is not available to Java threads and is therefore not
// considered part of the free memory.
const size_t max_capacity = ZHeap::heap()->current_max_capacity();
const size_t max_reserve = ZHeap::heap()->max_reserve();
const size_t used = ZHeap::heap()->used();
const size_t free_with_reserve = max_capacity - used;
const size_t free = free_with_reserve - MIN2(free_with_reserve, max_reserve);
// Calculate time until OOM given the max allocation rate and the amount
// of free memory. The allocation rate is a moving average and we multiply
// that with an allocation spike tolerance factor to guard against unforeseen
// phase changes in the allocate rate. We then add ~3.3 sigma to account for
// the allocation rate variance, which means the probability is 1 in 1000
// that a sample is outside of the confidence interval.
const double max_alloc_rate = (ZStatAllocRate::avg() * ZAllocationSpikeTolerance) + (ZStatAllocRate::avg_sd() * one_in_1000);
const double time_until_oom = free / (max_alloc_rate + 1.0); // Plus 1.0B/s to avoid division by zero
// Calculate max duration of a GC cycle. The duration of GC is a moving
// average, we add ~3.3 sigma to account for the GC duration variance.
const AbsSeq& duration_of_gc = ZStatCycle::normalized_duration();
const double max_duration_of_gc = duration_of_gc.davg() + (duration_of_gc.dsd() * one_in_1000);
// Calculate time until GC given the time until OOM and max duration of GC.
// We also deduct the sample interval, so that we don't overshoot the target
// time and end up starting the GC too late in the next interval.
const double sample_interval = 1.0 / ZStatAllocRate::sample_hz;
const double time_until_gc = time_until_oom - max_duration_of_gc - sample_interval;
log_debug(gc, director)("Rule: Allocation Rate, MaxAllocRate: %.3lfMB/s, Free: " SIZE_FORMAT "MB, MaxDurationOfGC: %.3lfs, TimeUntilGC: %.3lfs",
max_alloc_rate / M, free / M, max_duration_of_gc, time_until_gc);
return time_until_gc <= 0;
}
ZAllocationSpikeTolerance是一個修正系數(shù)，
product(double, ZAllocationSpikeTolerance, 2.0, \
"Allocation spike tolerance factor") \
4,自行控制進(jìn)行GC
heap距離上次GC發(fā)生后使用增長率超過10%雄家，或者距離上次GC發(fā)生后超過5min效诅。這個參數(shù)是彌補(bǔ)第三個條件中沒有覆蓋的場景，從上述分析可以得到第三個條件更多的覆蓋分配速率比較高的場景趟济。
diagnostic(bool, ZProactive, true, \
"Enable proactive GC cycles") \
bool ZDirector::rule_proactive() const {
if (!ZProactive || !is_warm()) {
// Rule disabled
return false;
}
// Perform GC if the impact of doing so, in terms of application throughput
// reduction, is considered acceptable. This rule allows us to keep the heap
// size down and allow reference processing to happen even when we have a lot
// of free space on the heap.
// Only consider doing a proactive GC if the heap usage has grown by at least
// 10% of the max capacity since the previous GC, or more than 5 minutes has
// passed since the previous GC. This helps avoid superfluous GCs when running
// applications with very low allocation rate.
const size_t used_after_last_gc = ZStatHeap::used_at_relocate_end();
const size_t used_increase_threshold = ZHeap::heap()->current_max_capacity() * 0.10; // 10%
const size_t used_threshold = used_after_last_gc + used_increase_threshold;
const size_t used = ZHeap::heap()->used();
const double time_since_last_gc = ZStatCycle::time_since_last();
const double time_since_last_gc_threshold = 5 * 60; // 5 minutes
if (used < used_threshold && time_since_last_gc < time_since_last_gc_threshold) {
return false;
}
const double assumed_throughput_drop_during_gc = 0.50; // 50%
const double acceptable_throughput_drop = 0.01; // 1%
const AbsSeq& duration_of_gc = ZStatCycle::normalized_duration();
const double max_duration_of_gc = duration_of_gc.davg() + (duration_of_gc.dsd() * one_in_1000);
const double acceptable_gc_interval = max_duration_of_gc * ((assumed_throughput_drop_during_gc / acceptable_throughput_drop) - 1.0);
const double time_until_gc = acceptable_gc_interval - time_since_last_gc;
return time_until_gc <= 0;
}
