歡迎光臨
每天分享高質量文章
當前位置：知識星球 > 後端 > 正文

【追光者系列】HikariCP原始碼分析之ConcurrentBag

2018-05-03 分類：後端 閱讀(348) 評論(0)

摘自【工匠小豬豬的技術世界】 1.這是一個系列，有興趣的朋友可以持續關註 2.如果你有HikariCP使用上的問題，可以給我留言，我們一起溝通討論 3.希望大家可以提供我一些案例，我也希望可以支援你們做一些調優

ConcurrentBag的定義

HikariCP contains a custom lock-free collection called a ConcurrentBag. The idea was borrowed from the C# .NET ConcurrentBag class, but the internal implementation quite different. The ConcurrentBag provides…

  • A lock-free design

  • ThreadLocal caching

  • Queue-stealing

  • Direct hand-off optimizations

…resulting in a high degree of concurrency, extremely low latency, and minimized occurrences of false-sharing.

https://en.wikipedia.org/wiki/False_sharing

  • CopyOnWriteArrayList：負責存放ConcurrentBag中全部用於出借的資源

  • ThreadLocal：用於加速執行緒本地化資源訪問

  • SynchronousQueue：用於存在資源等待執行緒時的第一手資源交接

ConcurrentBag取名來源於C# .NET的同名類，但是實現卻不一樣。它是一個lock-free集合，在連線池（多執行緒資料互動）的實現上具有比LinkedBlockingQueue和LinkedTransferQueue更優越的併發讀寫效能。

ConcurrentBag原始碼解析

ConcurrentBag內部同時使用了ThreadLocal和CopyOnWriteArrayList來儲存元素，其中CopyOnWriteArrayList是執行緒共享的。ConcurrentBag採用了queue-stealing的機制獲取元素：首先嘗試從ThreadLocal中獲取屬於當前執行緒的元素來避免鎖競爭，如果沒有可用元素則掃描公共集合、再次從共享的CopyOnWriteArrayList中獲取。（ThreadLocal串列中沒有被使用的items在借用執行緒沒有屬於自己的時候，是可以被“竊取”的）

ThreadLocal和CopyOnWriteArrayList在ConcurrentBag中都是成員變數，執行緒間不共享，避免了偽共享(false sharing)的發生。 其使用專門的AbstractQueuedLongSynchronizer來管理跨執行緒訊號，這是一個”lock-less“的實現。

這裡要特別註意的是，ConcurrentBag中透過borrow方法進行資料資源借用，透過requite方法進行資源回收，註意其中borrow方法只提供物件取用，不移除物件。所以從bag中“借用”的items實際上並沒有從任何集合中刪除，因此即使取用廢棄了，垃圾收集也不會發生。因此使用時透過borrow取出的物件必須透過requite方法進行放回，否則會導致記憶體洩露，只有”remove”方法才能完全從bag中刪除一個物件。

好了，我們一起看一下ConcurrentBag原始碼概覽：

上節提過，CopyOnWriteArrayList負責存放ConcurrentBag中全部用於出借的資源，就是private final CopyOnWriteArrayList sharedList; 如下圖所示，sharedList中的資源透過add方法新增，remove方法出借

add方法向bag中新增bagEntry物件，讓別人可以借用

  1.   /**
  2.     * Add a new object to the bag for others to borrow.
  3.     *
  4.     * @param bagEntry an object to add to the bag
  5.     */
  6.    public void add(final T bagEntry) {
  7.       if (closed) {
  8.          LOGGER.info("ConcurrentBag has been closed, ignoring add()");
  9.          throw new IllegalStateException("ConcurrentBag has been closed, ignoring add()");
  10.       }
  11.       sharedList.add(bagEntry);//新新增的資源優先放入CopyOnWriteArrayList
  12.       // spin until a thread takes it or none are waiting
  13.       // 當有等待資源的執行緒時，將資源交到某個等待執行緒後才傳回（SynchronousQueue）
  14.       while (waiters.get() > 0 && !handoffQueue.offer(bagEntry)) {
  15.          yield();
  16.       }
  17.    }

remove方法用來從bag中刪除一個bageEntry，該方法只能在borrow(long, TimeUnit)和reserve(T)時被使用

  1. /**
  2.     * Remove a value from the bag.  This method should only be called
  3.     * with objects obtained by borrow(long, TimeUnit) or reserve(T)
  4.     *
  5.     * @param bagEntry the value to remove
  6.     * @return true if the entry was removed, false otherwise
  7.     * @throws IllegalStateException if an attempt is made to remove an object
  8.     *         from the bag that was not borrowed or reserved first
  9.     */
  10.    public boolean remove(final T bagEntry) {
  11.    // 如果資源正在使用且無法進行狀態切換，則傳回失敗
  12.       if (!bagEntry.compareAndSet(STATE_IN_USE, STATE_REMOVED) && !bagEntry.compareAndSet(STATE_RESERVED, STATE_REMOVED) && !closed) {
  13.          LOGGER.warn("Attempt to remove an object from the bag that was not borrowed or reserved: {}", bagEntry);
  14.          return false;
  15.       }
  16.       final boolean removed = sharedList.remove(bagEntry);// 從CopyOnWriteArrayList中移出
  17.       if (!removed && !closed) {
  18.          LOGGER.warn("Attempt to remove an object from the bag that does not exist: {}", bagEntry);
  19.       }
  20.       return removed;
  21.    }

ConcurrentBag中透過borrow方法進行資料資源借用

  1.   /**
  2.     * The method will borrow a BagEntry from the bag, blocking for the
  3.     * specified timeout if none are available.
  4.     *
  5.     * @param timeout how long to wait before giving up, in units of unit
  6.     * @param timeUnit a TimeUnit determining how to interpret the timeout parameter
  7.     * @return a borrowed instance from the bag or null if a timeout occurs
  8.     * @throws InterruptedException if interrupted while waiting
  9.     */
  10.    public T borrow(long timeout, final TimeUnit timeUnit) throws InterruptedException
  11.    {
  12.       // Try the thread-local list first
  13.       // 優先檢視有沒有可用的本地化的資源
  14.       final List<Object> list = threadList.get();
  15.       for (int i = list.size() - 1; i >= 0; i--) {
  16.          final Object entry = list.remove(i);
  17.          @SuppressWarnings("unchecked")
  18.          final T bagEntry = weakThreadLocals ? ((WeakReference<T>) entry).get() : (T) entry;
  19.          if (bagEntry != null && bagEntry.compareAndSet(STATE_NOT_IN_USE, STATE_IN_USE)) {
  20.             return bagEntry;
  21.          }
  22.       }
  23.       // Otherwise, scan the shared list ... then poll the handoff queue
  24.       final int waiting = waiters.incrementAndGet();
  25.       try {
  26.       // 當無可用本地化資源時，遍歷全部資源，檢視是否存在可用資源
  27.       // 因此被一個執行緒本地化的資源也可能被另一個執行緒“搶走”
  28.          for (T bagEntry : sharedList) {
  29.             if (bagEntry.compareAndSet(STATE_NOT_IN_USE, STATE_IN_USE)) {
  30.                // If we may have stolen another waiter's connection, request another bag add.
  31.                if (waiting > 1) {
  32.                // 因為可能“搶走”了其他執行緒的資源，因此提醒包裹進行資源新增
  33.                   listener.addBagItem(waiting - 1);
  34.                }
  35.                return bagEntry;
  36.             }
  37.          }
  38.          listener.addBagItem(waiting);
  39.          timeout = timeUnit.toNanos(timeout);
  40.          do {
  41.             final long start = currentTime();
  42.             // 當現有全部資源全部在使用中，等待一個被釋放的資源或者一個新資源
  43.             final T bagEntry = handoffQueue.poll(timeout, NANOSECONDS);
  44.             if (bagEntry == null || bagEntry.compareAndSet(STATE_NOT_IN_USE, STATE_IN_USE)) {
  45.                return bagEntry;
  46.             }
  47.             timeout -= elapsedNanos(start);
  48.          } while (timeout > 10_000);
  49.          return null;
  50.       }
  51.       finally {
  52.          waiters.decrementAndGet();
  53.       }
  54.    }
  1.   /**
  2.     * This method will return a borrowed object to the bag.  Objects
  3.     * that are borrowed from the bag but never "requited" will result
  4.     * in a memory leak.
  5.     *
  6.     * @param bagEntry the value to return to the bag
  7.     * @throws NullPointerException if value is null
  8.     * @throws IllegalStateException if the bagEntry was not borrowed from the bag
  9.     */
  10.    public void requite(final T bagEntry) {
  11.    // 將狀態轉為未在使用
  12.       bagEntry.setState(STATE_NOT_IN_USE);
  13. // 判斷是否存在等待執行緒，若存在，則直接轉手資源
  14.       for (int i = 0; waiters.get() > 0; i++) {
  15.          if (bagEntry.getState() != STATE_NOT_IN_USE || handoffQueue.offer(bagEntry)) {
  16.             return;
  17.          }
  18.          else if ((i & 0xff) == 0xff) {
  19.             parkNanos(MICROSECONDS.toNanos(10));
  20.          }
  21.          else {
  22.             yield();
  23.          }
  24.       }
  25.  // 否則，進行資源本地化
  26.       final List<Object> threadLocalList = threadList.get();
  27.       threadLocalList.add(weakThreadLocals ? new WeakReference<>(bagEntry) : bagEntry);
  28.    }

上述程式碼中的 weakThreadLocals 是用來判斷是否使用弱取用，透過下述方法初始化：

  1.   /**
  2.     * Determine whether to use WeakReferences based on whether there is a
  3.     * custom ClassLoader implementation sitting between this class and the
  4.     * System ClassLoader.
  5.     *
  6.     * @return true if we should use WeakReferences in our ThreadLocals, false otherwise
  7.     */
  8.    private boolean useWeakThreadLocals()
  9.    {
  10.       try {
  11.       // 人工指定是否使用弱取用，但是官方不推薦進行自主設定。
  12.          if (System.getProperty("com.zaxxer.hikari.useWeakReferences") != null) {   // undocumented manual override of WeakReference behavior
  13.             return Boolean.getBoolean("com.zaxxer.hikari.useWeakReferences");
  14.          }
  15. // 預設透過判斷初始化的ClassLoader是否是系統的ClassLoader來確定
  16.          return getClass().getClassLoader() != ClassLoader.getSystemClassLoader();
  17.       }
  18.       catch (SecurityException se) {
  19.          return true;
  20.       }
  21.    }

SynchronousQueue

SynchronousQueue主要用於存在資源等待執行緒時的第一手資源交接，如下圖所示：

在hikariCP中，選擇的是公平樣式 this.handoffQueue = new SynchronousQueue<>(true);

公平樣式總結下來就是：隊尾匹配隊頭出隊，先進先出，體現公平原則。

SynchronousQueue是一個無儲存空間的阻塞佇列(是實現newFixedThreadPool的核心)，非常適合做交換工作，生產者的執行緒和消費者的執行緒同步以傳遞某些資訊、事件或者任務。

因為是無儲存空間的，所以與其他阻塞佇列實現不同的是，這個阻塞peek方法直接傳回null，無任何其他操作，其他的方法與阻塞佇列的其他方法一致。這個佇列的特點是，必須先呼叫take或者poll方法，才能使用off，add方法。

作為BlockingQueue中的一員，SynchronousQueue與其他BlockingQueue有著不同特性（來自明姐http://cmsblogs.com/?p=2418）：

  • SynchronousQueue沒有容量。與其他BlockingQueue不同，SynchronousQueue是一個不儲存元素的BlockingQueue。每一個put操作必須要等待一個take操作，否則不能繼續新增元素，反之亦然。

  • 因為沒有容量，所以對應 peek, contains, clear, isEmpty … 等方法其實是無效的。例如clear是不執行任何操作的，contains始終傳回false,peek始終傳回null。

  • SynchronousQueue分為公平和非公平，預設情況下採用非公平性訪問策略，當然也可以透過建構式來設定為公平性訪問策略（為true即可）。

  • 若使用 TransferQueue, 則佇列中永遠會存在一個 dummy node。

SynchronousQueue提供了兩個建構式：

  1. public SynchronousQueue() {
  2.         this(false);
  3.     }
  4.     public SynchronousQueue(boolean fair) {
  5.         // 透過 fair 值來決定公平性和非公平性
  6.         // 公平性使用TransferQueue，非公平性採用TransferStack
  7.         transferer = fair ? new TransferQueue<E>() : new TransferStack<E>();
  8.     }

TransferQueue、TransferStack繼承Transferer，Transferer為SynchronousQueue的內部類，它提供了一個方法transfer()，該方法定義了轉移資料的規範

  1. abstract static class Transferer<E> {
  2.         abstract E transfer(E e, boolean timed, long nanos);
  3.     }

transfer()方法主要用來完成轉移資料的，如果e != null，相當於將一個資料交給消費者，如果e == null，則相當於從一個生產者接收一個消費者交出的資料。

SynchronousQueue採用佇列TransferQueue來實現公平性策略，採用堆疊TransferStack來實現非公平性策略，他們兩種都是透過連結串列實現的，其節點分別為QNode，SNode。TransferQueue和TransferStack在SynchronousQueue中扮演著非常重要的作用，SynchronousQueue的put、take操作都是委託這兩個類來實現的。

公平樣式

公平樣式底層使用的TransferQueue內部佇列，一個head和tail指標，用於指向當前正在等待匹配的執行緒節點。 （來自https://blog.csdn.net/yanyan19880509/article/details/52562039） 初始化時，TransferQueue的狀態如下：

接著我們進行一些操作：

1、執行緒put1執行 put(1)操作，由於當前沒有配對的消費執行緒，所以put1執行緒入佇列，自旋一小會後睡眠等待，這時佇列狀態如下：

2、接著，執行緒put2執行了put(2)操作，跟前面一樣，put2執行緒入佇列，自旋一小會後睡眠等待，這時佇列狀態如下：

3、這時候，來了一個執行緒take1，執行了 take操作，由於tail指向put2執行緒，put2執行緒跟take1執行緒配對了(一put一take)，這時take1執行緒不需要入隊，但是請註意了，這時候，要喚醒的執行緒並不是put2，而是put1。為何？ 大家應該知道我們現在講的是公平策略，所謂公平就是誰先入隊了，誰就優先被喚醒，我們的例子明顯是put1應該優先被喚醒。至於讀者可能會有一個疑問，明明是take1執行緒跟put2執行緒匹配上了，結果是put1執行緒被喚醒消費，怎麼確保take1執行緒一定可以和次首節點(head.next)也是匹配的呢？其實大家可以拿個紙畫一畫，就會發現真的就是這樣的。  公平策略總結下來就是：隊尾匹配隊頭出隊。  執行後put1執行緒被喚醒，take1執行緒的 take()方法傳回了1(put1執行緒的資料)，這樣就實現了執行緒間的一對一通訊，這時候內部狀態如下：

4、最後，再來一個執行緒take2，執行take操作，這時候只有put2執行緒在等候，而且兩個執行緒匹配上了，執行緒put2被喚醒，  take2執行緒take操作傳回了2(執行緒put2的資料)，這時候佇列又回到了起點，如下所示：

以上便是公平樣式下，SynchronousQueue的實現模型。總結下來就是：隊尾匹配隊頭出隊，先進先出，體現公平原則。

非公平樣式

還是使用跟公平樣式下一樣的操作流程，對比兩種策略下有何不同。非公平樣式底層的實現使用的是TransferStack，  一個棧，實現中用head指標指向棧頂，接著我們看看它的實現模型:

1、執行緒put1執行 put(1)操作，由於當前沒有配對的消費執行緒，所以put1執行緒入棧，自旋一小會後睡眠等待，這時棧狀態如下：

2、接著，執行緒put2再次執行了put(2)操作，跟前面一樣，put2執行緒入棧，自旋一小會後睡眠等待，這時棧狀態如下：

3、這時候，來了一個執行緒take1，執行了take操作，這時候發現棧頂為put2執行緒，匹配成功，但是實現會先把take1執行緒入棧，然後take1執行緒迴圈執行匹配put2執行緒邏輯，一旦發現沒有併發衝突，就會把棧頂指標直接指向 put1執行緒

4、最後，再來一個執行緒take2，執行take操作，這跟步驟3的邏輯基本是一致的，take2執行緒入棧，然後在迴圈中匹配put1執行緒，最終全部匹配完畢，棧變為空，恢復初始狀態，如下圖所示：

從上面流程看出，雖然put1執行緒先入棧了，但是卻是後匹配，這就是非公平的由來。

CopyOnWriteArrayList

CopyOnWriteArrayList負責存放ConcurrentBag中全部用於出借的資源。(引自http://www.importnew.com/25034.html)

CopyOnWriteArrayList，顧名思義，Write的時候總是要Copy，也就是說對於任何可變的操作（add、set、remove）都是伴隨複製這個動作的，是ArrayList 的一個執行緒安全的變體。

A thread-safe variant of ArrayList in which all mutative operations (add, set, and so on) are implemented by making a fresh copy of the underlying array.This is ordinarily too costly, but may be more efficient than alternatives when traversal operations vastly outnumber mutations, and is useful when you cannot or don’t want to synchronize traversals, yet need to preclude interference among concurrent threads. The “snapshot” style iterator method uses a reference to the state of the array at the point that the iterator was created. This array never changes during the lifetime of the iterator, so interference is impossible and the iterator is guaranteed not to throw ConcurrentModificationException. The iterator will not reflect additions, removals, or changes to the list since the iterator was created. Element-changing operations on iterators themselves (remove, set, and add) are not supported. These methods throw UnsupportedOperationException. All elements are permitted, including null.

CopyOnWriteArrayList的add操作的原始碼如下：

  1. public boolean add(E e) {
  2.     //1、先加鎖
  3.     final ReentrantLock lock = this.lock;
  4.     lock.lock();
  5.     try {
  6.         Object[] elements = getArray();
  7.         int len = elements.length;
  8.         //2、複製陣列
  9.         Object[] newElements = Arrays.copyOf(elements, len + 1);
  10.         //3、將元素加入到新陣列中
  11.         newElements[len] = e;
  12.         //4、將array取用指向到新陣列
  13.         setArray(newElements);
  14.         return true;
  15.     } finally {
  16.        //5、解鎖
  17.         lock.unlock();
  18.     }
  19. }

一次add大致經歷了幾個步驟：

  1. 加鎖

  2. 拿到原陣列，得到新陣列的大小（原陣列大小+1），實體化出一個新的陣列來

  3. 把原陣列的元素複製到新陣列中去

  4. 新陣列最後一個位置設定為待新增的元素（因為新陣列的大小是按照原陣列大小+1來的）

  5. 把Object array取用指向新陣列

  6. 解鎖

插入、刪除、修改操作也都是一樣，每一次的操作都是以對Object[] array進行一次複製為基礎的

由於所有的寫操作都是在新陣列進行的，這個時候如果有執行緒併發的寫，則透過鎖來控制，如果有執行緒併發的讀，則分幾種情況： 

  • 如果寫操作未完成，那麼直接讀取原陣列的資料； 

  • 如果寫操作完成，但是取用還未指向新陣列，那麼也是讀取原陣列資料； 

  • 如果寫操作完成，並且取用已經指向了新的陣列，那麼直接從新陣列中讀取資料。

可見，CopyOnWriteArrayList的讀操作是可以不用加鎖的。

常用的List有ArrayList、LinkedList、Vector，其中前兩個是執行緒非安全的，最後一個是執行緒安全的。Vector雖然是執行緒安全的，但是隻是一種相對的執行緒安全而不是絕對的執行緒安全，它只能夠保證增、刪、改、查的單個操作一定是原子的，不會被打斷，但是如果組合起來用，並不能保證執行緒安全性。比如就像上面的執行緒1在遍歷一個Vector中的元素、執行緒2在刪除一個Vector中的元素一樣，勢必產生併發修改異常，也就是fail-fast。

所以這就是選擇CopyOnWriteArrayList這個併發元件的原因，CopyOnWriteArrayList如何做到執行緒安全的呢？

CopyOnWriteArrayList使用了一種叫寫時複製的方法，當有新元素新增到CopyOnWriteArrayList時，先從原有的陣列中複製一份出來，然後在新的陣列做寫操作，寫完之後，再將原來的陣列取用指向到新陣列。

當有新元素加入的時候，如下圖，建立新陣列，並往新陣列中加入一個新元素,這個時候，array這個取用仍然是指向原陣列的。

當元素在新陣列新增成功後，將array這個取用指向新陣列。

CopyOnWriteArrayList的整個add操作都是在鎖的保護下進行的。  這樣做是為了避免在多執行緒併發add的時候，複製出多個副本出來,把資料搞亂了，導致最終的陣列資料不是我們期望的。

CopyOnWriteArrayList反映的是三個十分重要的分散式理念：

1)讀寫分離 我們讀取CopyOnWriteArrayList的時候讀取的是CopyOnWriteArrayList中的Object[] array，但是修改的時候，操作的是一個新的Object[] array，讀和寫操作的不是同一個物件，這就是讀寫分離。這種技術資料庫用的非常多，在高併發下為了緩解資料庫的壓力，即使做了快取也要對資料庫做讀寫分離，讀的時候使用讀庫，寫的時候使用寫庫，然後讀庫、寫庫之間進行一定的同步，這樣就避免同一個庫上讀、寫的IO操作太多

2)最終一致 對CopyOnWriteArrayList來說，執行緒1讀取集合裡面的資料，未必是最新的資料。因為執行緒2、執行緒3、執行緒4四個執行緒都修改了CopyOnWriteArrayList裡面的資料，但是執行緒1拿到的還是最老的那個Object[] array，新新增進去的資料並沒有，所以執行緒1讀取的內容未必準確。不過這些資料雖然對於執行緒1是不一致的，但是對於之後的執行緒一定是一致的，它們拿到的Object[] array一定是三個執行緒都操作完畢之後的Object array[]，這就是最終一致。最終一致對於分散式系統也非常重要，它透過容忍一定時間的資料不一致，提升整個分散式系統的可用性與分割槽容錯性。當然，最終一致並不是任何場景都適用的，像火車站售票這種系統使用者對於資料的實時性要求非常非常高，就必須做成強一致性的。

3）使用另外開闢空間的思路，來解決併發衝突

缺點：

  1. 因為CopyOnWrite的寫時複製機制，所以在進行寫操作的時候，記憶體裡會同時駐扎兩個物件的記憶體，舊的物件和新寫入的物件（註意:在複製的時候只是複製容器裡的取用，只是在寫的時候會建立新物件新增到新容器裡，而舊容器的物件還在使用，所以有兩份物件記憶體）。如果這些物件佔用的記憶體比較大，比如說200M左右，那麼再寫入100M資料進去，記憶體就會佔用300M，那麼這個時候很有可能造成頻繁的Yong GC和Full GC。之前某系統中使用了一個服務由於每晚使用CopyOnWrite機制更新大物件，造成了每晚15秒的Full GC，應用響應時間也隨之變長。針對記憶體佔用問題，可以透過壓縮容器中的元素的方法來減少大物件的記憶體消耗，比如，如果元素全是10進位制的數字，可以考慮把它壓縮成36進位制或64進位制。或者不使用CopyOnWrite容器，而使用其他的併發容器，如ConcurrentHashMap。

  2. 不能用於實時讀的場景，像複製陣列、新增元素都需要時間，所以呼叫一個set操作後，讀取到資料可能還是舊的,雖CopyOnWriteArrayList 能做到最終一致性,但是還是沒法滿足實時性要求；

  3. 資料一致性問題。CopyOnWrite容器只能保證資料的最終一致性，不能保證資料的實時一致性。所以如果你希望寫入的的資料，馬上能讀到，請不要使用CopyOnWrite容器。關於C++的STL中，曾經也有過Copy-On-Write的玩法，參見陳皓的《C++ STL String類中的Copy-On-Write》，後來，因為有很多執行緒安全上的事，就被去掉了。https://blog.csdn.net/haoel/article/details/24058

隨著CopyOnWriteArrayList中元素的增加，CopyOnWriteArrayList的修改代價將越來越昂貴，因此，CopyOnWriteArrayList 合適讀多寫少的場景，不過這類慎用 

因為誰也沒法保證CopyOnWriteArrayList 到底要放置多少資料，萬一資料稍微有點多，每次add/set都要重新複製陣列，這個代價實在太高昂了。在高效能的網際網路應用中，這種操作分分鐘引起故障。CopyOnWriteArrayList適用於讀操作遠多於修改操作的併發場景中。而HikariCP就是這種場景。

還有比如白名單，黑名單，商品類目的訪問和更新場景，假如我們有一個搜尋網站，使用者在這個網站的搜尋框中，輸入關鍵字搜尋內容，但是某些關鍵字不允許被搜尋。這些不能被搜尋的關鍵字會被放在一個黑名單當中，黑名單每天晚上更新一次。當使用者搜尋時，會檢查當前關鍵字在不在黑名單當中，如果在，則提示不能搜尋。

但是使用CopyOnWriteMap需要註意兩件事情：

  1. 減少擴容開銷。根據實際需要，初始化CopyOnWriteMap的大小，避免寫時CopyOnWriteMap擴容的開銷。

  2. 使用批次新增。因為每次新增，容器每次都會進行複製，所以減少新增次數，可以減少容器的複製次數。

參考資料

  • http://www.cnblogs.com/taisenki/p/7699667.html

  • http://cmsblogs.com/?p=2418

  • https://blog.csdn.net/yanyan19880509/article/details/52562039

  • http://www.importnew.com/25034.html

  • https://blog.csdn.net/linsongbin1/article/details/54581787

END

贊(0)
標籤：

相關推薦

熱門標籤

iOS (11238)微軟 (4955)Linux (4274)安全 (4180)Python (4161)效能 (3165)運維 (2774)最佳化 (2419).NET (2262)Google (2136)機器學習 (1795)併發 (1613)分散式 (1559)叢集 (1240)SQL (1174)Mysql (1060)區塊鏈 (1017)Docker (977)微服務 (922)面試 (919)Apache (743)NLP (725)Redis (719)Android (668)Git (640)架構師 (632)Nginx (630)Facebook (599)JVM (595)爬蟲 (476)

熱門文章

分享創造快樂