緩存之王 Caffeine 中，涉及到100w級、1000W級、甚至億級元素的過期問題，如何進行高性能的定時調度，是一個難題。

注： 本文從 對 海量調度任務場景中， 高性能的時間輪算法， 做了一個 系統化、由淺入深的 穿透式介紹， 幫助大家徹底掌握 這個高性能的算法。
另外
本文以 PDF 持續更新，最新尼恩 架構筆記、面試題 的PDF文件，請從下面的鏈接獲取：語雀 或者 碼云

海量定時任務管理的問題

下面的問題，來自互聯網：

一個大型內容審核平時，在運營設定審核了內容的通過的時間，到了這個時間之后，相關內容自動審核通過，

本是個小的需求，但是考慮到如果需要定時審核的東西很多，這樣：

海量的定時任務調度，帶來的一系列性能問題。

海量定時任務管理的場景非常多，在實際項目中，存在大量需要定時或是延時觸發的任務，

比如電商中，延時需要檢查訂單是否支付成功，是否配送成功，定時給用戶推送提醒等等

方案一 單定時器方案

描述：

把所有需要定時審核的資源放到redis中，例如sorted set中，需要審核通過的時間作為score值。

后臺啟動一個定時器，定時輪詢sortedSet，當score值小于當前時間，則運行任務審核通過。

問題

這個方案在小批量數據的情況下沒有問題，

但是在大批量任務的情況下就會出現問題了，因為每次都要輪詢全量的數據，逐個判斷是否需要執行，

一旦輪詢任務執行比較長，就會出現任務無法按照定時的時間執行的問題。

方案二 一個任務一個定時器的方案

描述

每個需要定時完成的任務都啟動一個定時任務，然后等待完成之后銷毀

問題

這個方案帶來的問題很明顯，定時任務比較多的情況下，會啟動很多的線程，這樣服務器會承受不了之后崩潰。

基本上不會采取這個方案。

方案三 redis的過期通知功能

描述

和方案一類似，針對每一個需要定時審核的任務，設定過期時間，

過期時間也就是審核通過的時間，訂閱redis的過期事件，當這個事件發生時，執行相應的審核通過任務。

問題

這個方案來說是借用了redis這種中間件來實現我們的功能，這中實際上屬于redis的發布訂閱功能中的一部分，

針對redis發布訂閱功能是不推薦我們在生產環境中做業務操作的，

通常redis內部（例如redis集群節點上下線，選舉等等來使用），我們業務系統使用它的這個事件會產生如下兩個問題

1、redis發布訂閱的不穩定問題

2、redid發布訂閱的可靠性問題

具體可以參考 https://my.oschina.net/u/2457218/blog/3065021 (redis的發布訂閱缺陷)

方案四 分層時間輪方案

這個東西就是專為大批量定時任務管理而生。

具體論文詳見參考文獻

http://www.cs.columbia.edu/~nahum/w6998/papers/sosp87-timing-wheels.pdf

緩存之王 Caffeine 中的時間輪

緩存之王 Caffeine 中，涉及到100w級、1000W級、甚至億級元素的過期問題，

緩存之王 Caffeine 中，涉及到100w級、1000W級、甚至億級元素的過期問題，如何進行高性能的定時調度，是一個難題。

Caffeine 使用時間輪解決這個問題，

時間輪的大致結構：

Caffeine 對時間輪的實現在TimerWheel，它是一種多層時間輪（hierarchical timing wheels ）。

Caffeine 的時間輪，有五級。

看看元素加入到時間輪的schedule方法：

/*** Schedules a timer event for the node.** @param node the entry in the cache*/ public void schedule(@NonNull Node<K, V> node) {Node<K, V> sentinel = findBucket(node.getVariableTime());link(sentinel, node); }/*** Determines the bucket that the timer event should be added to.** @param time the time when the event fires* @return the sentinel at the head of the bucket*/ Node<K, V> findBucket(long time) {long duration = time - nanos;int length = wheel.length - 1;for (int i = 0; i < length; i++) {if (duration < SPANS[i + 1]) {long ticks = (time >>> SHIFT[i]);int index = (int) (ticks & (wheel[i].length - 1));return wheel[i][index];}}return wheel[length][0]; }/** Adds the entry at the tail of the bucket's list. */ void link(Node<K, V> sentinel, Node<K, V> node) {node.setPreviousInVariableOrder(sentinel.getPreviousInVariableOrder());node.setNextInVariableOrder(sentinel);sentinel.getPreviousInVariableOrder().setNextInVariableOrder(node);sentinel.setPreviousInVariableOrder(node); }

如果看不懂這些源碼，沒有關系，咱們由淺入深，慢慢道來。

時間輪的基本概念

時間輪這個技術其實出來很久了，在kafka、zookeeper、Netty、Dubbo等高性能組件中都有時間輪使用的方式。

如圖，時間輪，從圖片上來看，就和手表的表圈是一樣，所以稱為時間輪.

時間輪其實就是一種環形的數據結構,其設計參考了時鐘轉動的思維,

可以想象成時鐘，分成很多格子，一個格子代表一段時間

時間輪是由多個時間格組成，下圖中有8個時間格，每個時間格代表當前時間輪的基本時間跨度（tickDuration），其中時間輪的時間格的個數是固定的。

圖中，有8個時間格（槽），假設每個時間格的單位為100ms，那么整個時間輪走完一圈需要800ms。

每100ms指針會沿著順時針方向移動一個時間單位，

這個單位可以代表時間精度

這個單位可以設置，

比如以秒為單位，也可以以一小時為單位。

通過指針移動，來獲得每個時間格中的任務列表，然后遍歷這一個時間格中的雙向鏈表來執行任務，以此循環。

時間輪是以時間作為刻度, 組成的一個環形隊列，這個環形隊列采用數組來實現，

數組的每個元素稱為槽 Bucket，

每個槽位可以放一個定時任務列表，叫HashedWheelBucket，

每個槽位可以是一個雙向鏈表，其中可以設置一個 sentinel 哨兵節點， 作為添加任務和刪除任務的起始節點。

槽位鏈表的每一項表示一個定時任務項（HashedWhellTimeout），其中封裝了真正的定時任務TimerTask。

簡單來說：

時間輪是一種高效利用線程資源進行批量化調度的一種調度模型。

把大批量的調度任務全部綁定到同一個調度器上，使用這一個調度器來進行所有任務的管理、觸發、以及運行。

時間輪的模型能夠高效管理各種任務:

• 延時任務、
• 周期任務、
• 通知任務。

時間輪算法在很多框架中都有用到，比如 Dubbo、Netty、Kafka 等。

時間輪算法也是一個比較經典的設計。

時間輪和hashmap的類比

更通用的情況, 同一時刻可能需要執行多個任務，比如:

• 每天上午九點除了生成報表之外，
• 執行發送郵件的任務，
• 執行創建文件的任務，
• 執行數據分析的任務
• 等等，

為了存儲這些任務，如果有多個任務需要執行呢？

一個槽位可以指向一個數組或者鏈表，用來存放該刻度需要執行的任務，

所以，本質上，

時間輪的數據結構, 其實類似hashmap，

時間輪每一個時間刻度，可以理解為一個槽位，同一時刻存在多個任務 ，放在雙向鏈表中。

如下圖所示：

和hashmap不同的是，時間輪的key，是時間刻度值，并且，時間輪不做hash運算

時間輪在同一時刻存在多個任務時，只要把該刻度對應的鏈表全部遍歷一遍，執行其中的任務即可。

當然， 時鐘調度的線程，和 執行任務的線程，一般是需要解耦的。

所以，一般來說，具體的任務，會扔到線程池中異步執行。

時間刻度不夠用怎么辦？

如果任務不只限定在一天之內呢？

比如我有個任務，需要每周一上午九點執行，我還有另一個任務，需要每周三的上午九點執行。

大概的解決辦法是：

• 增大時間輪的刻度
• 列表中的任務中添加round屬性
• 分層時間輪

增大時間輪的刻度

一個刻度一小時， 一天24個小時，一周168個小時，為了解決時間刻度不夠用的問題，

我可以把時間輪的刻度（槽）從12個增加到168個，

這樣的話，一周的所有時間，都可以用一個時間輪來管理。

比如，現在是星期二上午10點，

那么，下周一上午九點，就是時間輪的第9個刻度，

那么，下周三上午九點就是時間輪的第57個刻度，

示意圖如下：

單級時間輪的問題

仔細思考一下，會發現單級時間輪方式存在幾個缺陷：

• 時間刻度太多會， 導致時間輪走到的多數刻度沒有任務執行，

  比如一個月就2個任務，我得移動720次，其中718次是無用功。

• 時間刻度太多會導致存儲空間變大，利用率變低

  比如一個月就2個任務，我得需要大小是720的數組，如果我的執行時間的粒度精確到秒，那就更恐怖了

所以，在實際應用中，一般單時間輪無法滿足需求。

例如我們需要秒級的精度，最大延遲可能是10天，那我們時間輪就要至少864000個格子，這就產生了如下幾個問題：

占用存儲過大

利用率太低，比如我們只有1秒一個任務，而7天若干任務，那大部分時間，整個輪子都是在空轉。

如何解決單級時間輪的問題呢？

方案1：任務中添加round屬性

方案2：多級時間輪

任務中添加round屬性

這次，不增加時間輪的刻度了，時間輪的刻度還是24個，而是按照任務的時間間隔，給任務增加一個 round屬性。

一個round的單位，單表間隔為一輪。

假設：現在有三個任務需要執行：

任務一每周二上午九點。

任務二每周四上午九點。

任務三每個月12號上午九點。

比如現在是9月11號星期二上午10點，時間輪轉一圈是24小時，到任務一下次執行（下周二上午九點）,

需要時間輪轉過6圈后，到第7圈的第9個刻度開始執行。

任務二下次執行第3圈的第9個刻度，任務三是第2圈的第9個刻度。

示意圖如下：

時間輪每移動到一個刻度時，遍歷任務列表，對每個task 進行分開處理：

• 把round值-1，
• 如果 round=0，則任務執行，從列表中移除。

這樣做能解決時間輪刻度范圍過大造成的空間浪費，但是卻帶來了另一個問題：

• 時間輪每次都需要遍歷任務列表，耗時增加，當時間輪刻度粒度很小(秒級甚至毫秒級)，
• 任務列表又特別長時，這種遍歷的辦法是不可接受的。

當然，對于大多數場景，這種方法還是適用的。

有沒有既節省空間，又節省時間的辦法呢？

答案是有的，正如《Hashed and Hierarchical Timing Wheels》標題中提到的，有一種分層時間輪，可以解決做到既節省空間，又節省時間：

分層時間輪

分層時間輪是這樣一種思想：

針對時間復雜度的問題：

不做遍歷計算round，凡是任務列表中的任務，都應該被執行的，直接全部取出來執行。

針對空間復雜度的問題：

分層，每個時間粒度對應一個時間輪，多個時間輪之間進行級聯協作。

第一點很好理解，第二點有必要舉個例子來說明。

比如有三個任務：

• 任務一 ：間隔30s。
• 任務二 ：間隔1分鐘30s。
• 任務三：間隔1小時1分鐘30s。

三個任務涉及到三個時間單位：秒、分鐘、小時。

按照分層時間輪來設計，我們可以設置三個時間輪：秒輪、分輪、小時輪。

時間刻度先得來到12號這一天，然后才需要關注其更細一級的時間單位：上午9點。

基于這個思想，我們可以設置三個時間輪：月輪、周輪、天輪。

• 秒輪的時間刻度 tick duration 是秒。span 跨度為 一分鐘，60秒。
• 分輪的時間刻度 tick duration 是分。span 跨度為 一小時，60分。
• 小時輪的時間刻度是 tick duration 是小時。span 跨度為 一天，24小時。

初始添加任務時：

• 任務一添加到秒輪上，
• 任務二添加到分輪上
• 任務三添加到時輪上。

三個時間輪以各自的時間刻度不停流轉。

當時輪移動到刻度2(第1小時)時，取出這個刻度下的任務三，丟到分輪上，分輪接管該任務。

當分輪移動到刻度2(第1分鐘)時，取出這個刻度下的任務二，丟到秒輪上，秒輪接管該任務。

當秒輪移動到刻度30(第30秒)時，取出這個刻度下的任務一，移除該任務，然后執行該任務。

整體的示意圖如下所示：

分層時間輪的時間復雜度分析

分層時間輪算法是為了更高效的實現定時器而設計的一種數據格式，

定時器的核心需求

新增（初始化一個定時任務）

移除（過期任務）

任務到期檢測

定時器的實現方式，大概有那些呢？

方式一：基于小頂堆實現的PriorityQueue

內部的結構，按照到期時間，維護了**一個優先隊列 PriorityQueue **，

優先隊列的插入和刪除的時間復雜度是O(logn)，

當數據量大的時候，頻繁的入堆出堆，總體性能有待考慮。

Timer、DelayQueue 和 ScheduledThreadPool

方式二：帶round屬性的單級時間輪

由于時間的跨度都比較長，單級時間輪一般會帶著round屬性。 沒有round屬性的單級時間輪，生產場景基本不用，這里不做時間復雜度的考慮。

帶round屬性的單級時間輪的本質就是一個數組，它的時間跨度就是一個時間循環

同時，每一個槽位，會維護一個 任務鏈表，每一個任務帶著 round 數量

時間輪會以時間刻度 tick duration 間隔為單位，開始每一個最小時間間隔步進一個單位，然后檢查當前時間輪節點上是否有任務

• 如果有任務，就直接執行
• 沒有任務，就等待下一個時間間隔步進1，重復進行檢測

時間輪每移動到一個刻度時，遍歷任務列表，對每個task 進行分開處理：

• 把round值 減去1，
• 如果 round=0，則任務執行，從列表中移除。

時間復雜度：純粹的時間輪-新增O（1），移除O（1），檢測O（N）

總體而言，時間復雜度O(N)

缺點：時間復雜度高

方式三：分層時間輪實現定時器

本質就是多個時間輪共同一起作用，分時間層級！

以上述圖片為樣例，當時輪上有任務時，那么就將該任務轉移到對應的分鐘時間輪上；

當分輪上有任務時，那么就將該任務轉移到對應的秒鐘的秒輪上；

當秒輪上有任務時，那么就將該任務移除；

時間復雜度：新增O(1)，移除O(1)，檢測O(1)

Caffeine 中的TimerWheel的使用

除了支持expireAfterAccess和expireAfterWrite之外（Guava Cache 也支持這兩個特性），Caffeine 還支持expireAfter。

因為expireAfterAccess和expireAfterWrite都只能是固定的過期時間，一般情況而已，這個已經夠用了。

但還是有些特殊場景，譬如記錄的過期時間，是需要根據某些條件而不一樣的，這就需要用戶自定義過期時間。

先看看expireAfter的用法

package com.github.benmanes.caffeine.demo;import com.github.benmanes.caffeine.cache.Cache; import com.github.benmanes.caffeine.cache.CacheLoader; import com.github.benmanes.caffeine.cache.Caffeine; import com.github.benmanes.caffeine.cache.Expiry; import org.checkerframework.checker.index.qual.NonNegative; import org.checkerframework.checker.nullness.qual.NonNull; import org.checkerframework.checker.nullness.qual.Nullable;import java.util.concurrent.TimeUnit;public class ExpireAfterDemo {static System.Logger logger = System.getLogger(ExpireAfterDemo.class.getName());public static void hello(String[] args) {System.out.println("args = " + args);}public static void main(String... args) throws Exception {Cache<String, String> cache = Caffeine.newBuilder()//最大個數限制//最大容量1024個，超過會自動清理空間.maximumSize(1024)//初始化容量.initialCapacity(1)//訪問后過期（包括讀和寫）//5秒沒有讀寫自動刪除 // .expireAfterAccess(5, TimeUnit.SECONDS)//寫后過期 // .expireAfterWrite(2, TimeUnit.HOURS)//寫后自動異步刷新 // .refreshAfterWrite(1, TimeUnit.HOURS)//記錄下緩存的一些統計數據，例如命中率等.recordStats().removalListener(((key, value, cause) -> {//清理通知 key,value ==> 鍵值對 cause ==> 清理原因System.out.println("removed key="+ key);})).expireAfter(new Expiry<String, String>() {//返回創建后的過期時間@Overridepublic long expireAfterCreate(@NonNull String key, @NonNull String value, long currentTime) {System.out.println("1. expireAfterCreate key="+ key);return 0;}//返回更新后的過期時間@Overridepublic long expireAfterUpdate(@NonNull String key, @NonNull String value, long currentTime, @NonNegative long currentDuration) {System.out.println("2. expireAfterUpdate key="+ key);return 0;}//返回讀取后的過期時間@Overridepublic long expireAfterRead(@NonNull String key, @NonNull String value, long currentTime, @NonNegative long currentDuration) {System.out.println("3. expireAfterRead key="+ key);return 0;}}).recordStats()//使用CacheLoader創建一個LoadingCache.build(new CacheLoader<String, String>() {//同步加載數據@Nullable@Overridepublic String load(@NonNull String key) throws Exception {System.out.println("loading key="+ key);return "value_" + key;}//異步加載數據@Nullable@Overridepublic String reload(@NonNull String key, @NonNull String oldValue) throws Exception {System.out.println("reloading key="+ key);return "value_" + key;}});//添加值cache.put("name", "瘋狂創客圈");cache.put("key", "一個高并發 研究社群");//獲取值@Nullable String value = cache.getIfPresent("name");System.out.println("value = " + value);//removecache.invalidate("name");value = cache.getIfPresent("name");System.out.println("value = " + value);}}

通過自定義過期時間，使得不同的 key 可以動態的得到不同的過期時間。

需要把expireAfterAccess和expireAfterWrite注釋了，因為這兩個特性不能跟expireAfter一起使用。只能做二選一，從源碼中，也可以看到這點：

當使用了expireAfter特性后，Caffeine 會啟用一種叫“時間輪”的算法來實現這個功能。

為什么Caffeine 要用時間輪

好，重點來了，為什么要用時間輪？

對expireAfterAccess和expireAfterWrite的實現是用一個AccessOrderDeque雙端隊列，它是 FIFO 的

因為它們的過期時間是固定的，從時間維度而言，而最早進入隊列的緩存記錄Node節點，在頭部。

最新的節點、或者最晚進入的緩存記錄Node節點，在尾部。

由于每次插入都在尾部，可以理解為這個隊列，暗含了一個規律：

元素是按照過期時間有序的

所以, 結論是：

在隊列頭的數據肯定是最早過期的，在隊列尾部的數據肯定是最晚過期的，

要處理過期數據時，只需要首先看看頭部是否過期，然后再挨個檢查就可以了。

但是，這個隊列有個要求：

各個節點的過期時間，要求是一樣的

如果過期時間不一樣的話，怎么做過期時間檢查呢？

這就需要遍歷，還有一種方式是，對這個雙端隊列accessOrderQueue進行排序&插入，這個時間復雜度就不說O（1）了。

于是，Caffeine 用了一種更加高效、優雅的算法-時間輪。

Caffeine 的五級時間輪的源碼分析

重要屬性與方法

時間輪的具體實現為一個二維數組，其數組的具體位置存放的則為一個待執行節點的鏈表。

時間輪的二維數組的第一個維度則是具體的時間間隔，分別是秒，分鐘，小時，天，4天，但但并沒有嚴格按照時間單位來區分單位，而是根據以上單位最接近的2的整數次冪作為時間間隔，因此在其第一個維度的時間間隔分別是1.07s，1.14m，1.22h，1.63d，6.5d。

static final int[] BUCKETS = { 64, 64, 32, 4, 1 };static final long[] SPANS = {ceilingPowerOfTwo(TimeUnit.SECONDS.toNanos(1)), // 1.07sceilingPowerOfTwo(TimeUnit.MINUTES.toNanos(1)), // 1.14mceilingPowerOfTwo(TimeUnit.HOURS.toNanos(1)), // 1.22hceilingPowerOfTwo(TimeUnit.DAYS.toNanos(1)), // 1.63dBUCKETS[3] * ceilingPowerOfTwo(TimeUnit.DAYS.toNanos(1)), // 6.5dBUCKETS[3] * ceilingPowerOfTwo(TimeUnit.DAYS.toNanos(1)), // 6.5d};

當具體的時間事件要加入到時間輪時，將會根據該事件距離當前時間的最接近的單位，首先定位到二維數組的第一個維度，具體后面會解釋。

為什么要選擇最接近的2的整數而不是選擇具體的時間整數，是為了可以通過移位比較快速得到時間滾動在二維數組的第一個維度的變動。

在時間輪中，具體記錄了以上時間間隔的偏移量，在時間輪中，將當前時間與上一次時間求差并不斷右移SHIFT的位數，便可以快速定位到時間的變動。

//Long.numberOfTrailingZeros(value1) 返回最左側之后的0位數, 10100010000 》》》 4static final long[] SHIFT = {Long.numberOfTrailingZeros(SPANS[0]),Long.numberOfTrailingZeros(SPANS[1]),Long.numberOfTrailingZeros(SPANS[2]),Long.numberOfTrailingZeros(SPANS[3]),Long.numberOfTrailingZeros(SPANS[4]),};final Node<K, V>[][] wheel;long nanos;

用簡單的數字舉個例子，第一個維度分別為1s，10s，100s，1000s，

那么具體的第一維存在四個槽位，分別存放10s以內的，10s到100s以內的，100s到1000s以內的，1000s以后的，當一個300s之后發生的時間事件進入后，首先得到差值300，依次比較，顯然300大于100小于1000，那么這個300s以后發生的事件在時間輪上的二維數組的第一個維度的第三個位置上。

其中1s則是用來標志過期操作之間的最小的時間刻度，并沒有參與到時間事件的定位中，類比時間輪中的1.07s。

請參見視頻《第25章：穿透Caffeine 的架構和源碼分析》

構造函數

初始化五級時間輪，每個時間輪，都是一個數組。

@SuppressWarnings({"rawtypes", "unchecked"})TimerWheel() {wheel = new Node[BUCKETS.length][];for (int i = 0; i < wheel.length; i++) {wheel[i] = new Node[BUCKETS[i]];for (int j = 0; j < wheel[i].length; j++) {wheel[i][j] = new Sentinel<>();}}System.out.println("BUCKETS = " + Arrays.toString(BUCKETS));System.out.println("SPANS = " +Arrays.toString( SPANS));System.out.println("SHIFT = " + Arrays.toString(SHIFT));System.out.println("Long.toBinaryString(SPANS[0]) = " + Long.toBinaryString(SPANS[0]));System.out.println("wheel = " + wheel);}

請參見視頻《第25章：穿透Caffeine 的架構和源碼分析》

時間步進

/*** Advances the timer and evicts entries that have expired.** @param cache the instance that the entries belong to* @param currentTimeNanos the current time, in nanoseconds*/public void advance(BoundedLocalCache<K, V> cache, long currentTimeNanos) {long previousTimeNanos = nanos;nanos = currentTimeNanos;// If wrapping then temporarily shift the clock for a positive comparison. We assume that the// advancements never exceed a total running time of Long.MAX_VALUE nanoseconds (292 years)// so that an overflow only occurs due to using an arbitrary origin time (System.nanoTime()).if ((previousTimeNanos < 0) && (currentTimeNanos > 0)) {previousTimeNanos += Long.MAX_VALUE;currentTimeNanos += Long.MAX_VALUE;}try {for (int i = 0; i < SHIFT.length; i++) {long previousTicks = (previousTimeNanos >>> SHIFT[i]);long currentTicks = (currentTimeNanos >>> SHIFT[i]);long delta = (currentTicks - previousTicks);if (delta <= 0L) {break;}expire(cache, i, previousTicks, delta);}} catch (Throwable t) {nanos = previousTimeNanos;throw t;}}

任務調度

首先找到對應的 時間輪，和時間輪里邊的槽位

然后通過哨兵，插入任務

* @param node the entry in the cache*/public void schedule(Node<K, V> node) {Node<K, V> sentinel = findBucket(node.getVariableTime());link(sentinel, node);}

找到對應的 時間輪，和時間輪里邊的槽位

* @param time the time when the event fires* @return the sentinel at the head of the bucket*/Node<K, V> findBucket(long time) {long duration = time - nanos;int length = wheel.length - 1;for (int i = 0; i < length; i++) {if (duration < SPANS[i + 1]) {long ticks = (time >>> SHIFT[i]);int index = (int) (ticks & (wheel[i].length - 1));return wheel[i][index];}}return wheel[length][0];}

請參見視頻《第25章：穿透Caffeine 的架構和源碼分析》

Dubbo源碼中的時間輪

后面會對照 Caffeine 的時間輪，分析Dubbo源碼中的時間輪

未完待續

XXL-Job源碼中的時間輪

后面會對照 Caffeine 的時間輪，分析XXL-Job源碼中的時間輪

未完待續

參考文獻

https://www.likecs.com/show-204434429.html

http://www.cs.columbia.edu/~nahum/w6998/papers/sosp87-timing-wheels.pdf

https://blog.csdn.net/xinzhongtianxia/article/details/86221241

https://blog.csdn.net/m0_37039331/article/details/87401758

https://blog.csdn.net/qq924862077/article/details/112550085

https://baijiahao.baidu.com/s?id=1714290103234167995

https://www.cnblogs.com/smileIce/p/11156412.html

https://blog.csdn.net/bz120413/article/details/122107790

https://blog.csdn.net/Javaesandyou/article/details/123918852

https://blog.csdn.net/Javaesandyou/article/details/123918852

https://blog.csdn.net/FreeeLinux/article/details/54897192

https://blog.csdn.net/weixin_41605937/article/details/121972371

推薦閱讀：

• 《尼恩Java面試寶典》

• 《Springcloud gateway 底層原理、核心實戰 (史上最全)》

• 《Flux、Mono、Reactor 實戰（史上最全）》

• 《sentinel （史上最全）》

• 《Nacos (史上最全)》

• 《分庫分表 Sharding-JDBC 底層原理、核心實戰（史上最全）》

• 《TCP協議詳解 (史上最全)》

• 《clickhouse 超底層原理 + 高可用實操 （史上最全）》

• 《nacos高可用（圖解+秒懂+史上最全）》

• 《隊列之王： Disruptor 原理、架構、源碼 一文穿透》

• 《環形隊列、 條帶環形隊列 Striped-RingBuffer （史上最全）》

• 《一文搞定：SpringBoot、SLF4j、Log4j、Logback、Netty之間混亂關系（史上最全）

• 《單例模式（史上最全）

• 《紅黑樹（ 圖解 + 秒懂 + 史上最全）》

• 《分布式事務 （秒懂）》

• 《緩存之王：Caffeine 源碼、架構、原理（史上最全，10W字 超級長文）》

• 《緩存之王：Caffeine 的使用（史上最全）》

• 《Java Agent 探針、字節碼增強 ByteBuddy（史上最全）》

• 《Docker原理（圖解+秒懂+史上最全）》

• 《Redis分布式鎖（圖解 - 秒懂 - 史上最全）》

• 《Zookeeper 分布式鎖 - 圖解 - 秒懂》

• 《Zookeeper Curator 事件監聽 - 10分鐘看懂》

• 《Netty 粘包 拆包 | 史上最全解讀》

• 《Netty 100萬級高并發服務器配置》

• 《Springcloud 高并發 配置 （一文全懂）》

總結

以上是生活随笔為你收集整理的时间轮 （史上最全）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。