ArrayList和LinkedList有什么區(qū)別？

這種侮辱人的問題，默認就把這兩者限定在了同一個場景之中，它甚至連八股文都算不上。

一旦你被問到這種問題，也證明面試基本上泡湯了--面試官已經(jīng)實在是找不到其他問題與你交流了。

你Over了。

但當我們細看一下LinkedList的class定義，就會發(fā)現(xiàn)，它并不像是ArrayList的那樣具有純潔的列表精神。

public class ArrayList<E> extends AbstractList<E>
        implements List<E>, RandomAccess, Cloneable, java.io.Serializable

//VS

public class LinkedList<E>
    extends AbstractSequentialList<E>
    implements List<E>, Deque<E>, Cloneable, java.io.Serializable

LinkedList除了能夠當作普通的列表，它還是一個Deque。雙向鏈表，聽著就比較唬人，這就是一個既能當做隊列、又能當做棧的存在。

有了這種雙重Buff的疊加，LinkedList的應(yīng)用場景比ArrayList豐富的多。除了能做最簡單的LRU緩存，LinkedList在刷題的時候也是充滿了正能量。

關(guān)于類似Deque的API，xjjdog以前有專門的文章來介紹這些爆炸性的方法。

王者ConcurrentLinkedQueue，一個阻塞的雙向隊列，它的基本操作方法有：(3[基本]x2[異常與返回值]+4[阻塞加超時])x3[隊頭隊尾]=5x2x3=30，足足有30個方法?？赐晟厦娴奈恼?，這30個方法可以很快手到擒來。

不過我們今天要聊的一個重點，是使用Deque來實現(xiàn)更快的延遲隊列。

延遲隊列

如果你想要某些數(shù)據(jù)延遲一段時間再進行處理，或者要再某段時間內(nèi)按照分組進行一些計算，那延遲隊列無疑是非常合適的。

在Java的Concurrent包里，就靜悄悄的躺著DelayQueue。只要你的數(shù)據(jù)實現(xiàn)了Delayed接口，那么就可以放心大膽的把它們往里面塞。

可惜的是，DelayQueue的底層存儲，使用的是PriorityQueue。

PriorityQueue是堆實現(xiàn)的，offer和poll數(shù)據(jù)的時間復(fù)雜度是O(logN)。這就意味著，當DelayQueue中的數(shù)據(jù)比較多的時候，它的性能就會下降。

除了把數(shù)據(jù)分片，使用多個DelayQueue來完成工作，我們有沒有速度更快的方法？比如把PriorityQueue使用LinkedList來替換？

這要看場景。

如果你向DelayQueue中添加數(shù)據(jù)，是與當前添加的時間相關(guān)的，那完全可以使用LinkedList來替換PriorityQueue。

關(guān)鍵代碼

要了解DelayQueue的運行原理，我們可以需要先看一下Delayed接口。任何想要存儲到DelayQueue中的數(shù)據(jù)，都需要實現(xiàn)這個接口。

其中，getDelay就是用來判斷當前數(shù)據(jù)是否超時的方法。而compareTo，則是PriorityQueue用來排序的，如果我們是按照當前塞入數(shù)據(jù)的，則compareTo方法就不是必要的。

按照以上的思路，我們把DelayQueue的代碼拷貝一份，僅保留關(guān)鍵代碼，如下。

public long getDelay(@NotNull TimeUnit unit) {
    return MAX_CACHE_DUAL + this.enqueueTimeNs - System.nanoTime();
}
public int compareTo(@NotNull Delayed o) {
    long d = getDelay(TimeUnit.NANOSECONDS) - o.getDelay(TimeUnit.NANOSECONDS);
    return (d == 0) ? 0 : (d < 0 ? -1 : 1);
}

主要方法

輕量級的延遲隊列，如果一旦采用了LinkedList，那么它的入隊、出隊方法，就都變成了O(1)的時間復(fù)雜度。在延遲隊列中的數(shù)據(jù)增加時，時間復(fù)雜度也能維持不變，可以說是速度快的連兔子都追不上了。

一般，在java中，put和take方法，都是代表阻塞性方法。比如，take方法，我們可以將其安全的阻塞在某個線程上，而不用擔心太多的資源浪費。

final Thread thread = Thread.currentThread();
while (!this.close && !thread.isInterrupted()) {
    Data data = q.take();
}

這一切都是Condition辦到的，它和wait、notify的作用是一樣的。

當我們通過put方法添加新的數(shù)據(jù)到隊列中，會通過signal方法，來通知等待的線程獲取數(shù)據(jù)。

相同的，如果take方法發(fā)現(xiàn)隊列中的數(shù)據(jù)為空，它將進入等待狀態(tài)。如果有數(shù)據(jù)，也并不是馬上把這些數(shù)據(jù)取出來，因為數(shù)據(jù)還沒到期。比如最老的數(shù)據(jù)還剩下5秒才到期，代碼也對這種情況進行了處理，它會嘗試awaitNanos對應(yīng)的時間。

這樣，我們就可以使用這種簡單的輪詢方式來實現(xiàn)延遲隊列，而不需要單獨的線程去檢測隊列中的數(shù)據(jù)。

增加take方法的效率

但是這樣還不夠。

當數(shù)據(jù)量比較大的時候，隊列的數(shù)據(jù)可能有多條已經(jīng)到期。如果我們通過take方法來一條一條獲取的話，效率自然不如批量獲取高。

drainTo方法，可以一股腦的把到期的數(shù)據(jù)轉(zhuǎn)移到其他的集合中，但它并不是一個阻塞性的方法。

我們可以先使用take來阻塞線程，然后再批量取出所有數(shù)據(jù)。

下面代碼，會一次性獲取100條數(shù)據(jù)作為一個批量。

final Data takeItem = q.take();
final List<Data> buckets = new ArrayList<>(100);
q.drainTo(buckets, 99);
buckets.add(takeItem);

End

實際上，我們的某個業(yè)務(wù)，當采用LinkedList來替代PriorityQueue，并進行批量操作后，CPU的使用直接降低了1/3。

Deque是xjjdog最喜歡的一個接口。每當使用offerFirst、offerLast這樣精準的API進行操作，都會體驗到多巴胺的樂趣。LinkedList作為它的兒子，自然擁有了這些所有的功能。

當我們使用concurrent包里的基本API，對這些淳樸的工具進行封裝，它們就會煥發(fā)出新的活力。

作者簡介：小姐姐味道  (xjjdog)，一個不允許程序員走彎路的公眾號。聚焦基礎(chǔ)架構(gòu)和Linux。十年架構(gòu)，日百億流量，與你探討高并發(fā)世界，給你不一樣的味道。