為什么即使在單執行緒情況下也不使用同步的ArrayList？-有解無憂

我已經運行了以下代碼來測量將元素添加到 ArrayList 與它的同步版本之間的時間和性能差異，令人驚訝的是沒有發現任何顯著差異！我所說的意義重大，我的意思是這種差異并沒有給你任何資訊，你可以從中選擇一個而不是另一個！

我的問題是，如果在性能方面它們幾乎相同，那么為什么它們甚至首先提供非同步版本？為什么不對多執行緒和單執行緒情況使用同步版本呢？

僅供參考，可以看出我沒有預熱 JVM，而且我知道垃圾收集很可能會在迭代之間運行以釋放舊陣列，但我認為這并不重要，因為我們在這兩種情況下都有它即使您只運行一次迭代，您也會得到相同的結果！

    int size = 100_000_000;
    long totalTime = 0;
    for(int j=0; j<20; j  ) {
        List<Integer> l1 = new ArrayList<>(size);
        //List<Integer> l1 = Collections.synchronizedList(new ArrayList<>(size));

        long t1 = System.nanoTime();

        IntStream.range(0, size).sequential().forEach(i -> l1.add(i));

        long t2 = System.nanoTime();
        totalTime  = t2-t1;
    }
    System.out.println("time (ms):"   TimeUnit.NANOSECONDS.toMillis(totalTime/20));

uj5u.com熱心網友回復：

如果你得到奇怪的基準測驗結果，你需要做的第一件事就是驗證你的基準測驗。由于很多原因，您的基準測驗存在缺陷。

沒有適當的熱身。這不僅是典型的 JIT 預熱，而且在 JVM 啟動的最初幾秒內，偏向鎖定被禁用。
迭代次數不足
理論上，由于消除了死代碼，可以優化代碼

所以我使用 JMH 重寫了你的基準測驗：一個微型基準測驗框架。

package com;

import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.BenchmarkMode;
import org.openjdk.jmh.annotations.Fork;
import org.openjdk.jmh.annotations.Measurement;
import org.openjdk.jmh.annotations.Mode;
import org.openjdk.jmh.annotations.OperationsPerInvocation;
import org.openjdk.jmh.annotations.OutputTimeUnit;
import org.openjdk.jmh.annotations.Scope;
import org.openjdk.jmh.annotations.State;
import org.openjdk.jmh.annotations.Warmup;

import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
import java.util.concurrent.TimeUnit;
import java.util.stream.IntStream;

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@State(Scope.Benchmark)
@OperationsPerInvocation(SyncArrayListBenchmark.OPERATIONS_PER_INVOCATION)
public class SyncArrayListBenchmark {

    public static final int OPERATIONS_PER_INVOCATION = 100_000_000;


    @Benchmark
    public int arrayList() {
        List<Integer> l1 = new ArrayList<>(OPERATIONS_PER_INVOCATION);

        IntStream.range(0, OPERATIONS_PER_INVOCATION).sequential().forEach(i -> l1.add(i));

        return l1.size();
    }

    @Benchmark
    public int synchronized_arrayList() {
        List<Integer> l1 = Collections.synchronizedList(new ArrayList<>(OPERATIONS_PER_INVOCATION));

        IntStream.range(0, OPERATIONS_PER_INVOCATION).sequential().forEach(i -> l1.add(i));

        return l1.size();
    }
}

使用 JDK 11 運行的結果：

Benchmark                                      Mode  Cnt  Score   Error  Units
SyncArrayListBenchmark.arrayList               avgt   25  4.986 ± 0.100  ns/op
SyncArrayListBenchmark.synchronized_arrayList  avgt   25  6.447 ± 0.104  ns/op

使用 JDK 17 運行的結果：

Benchmark                                      Mode  Cnt   Score   Error  Units
SyncArrayListBenchmark.arrayList               avgt   25   6.819 ± 0.300  ns/op
SyncArrayListBenchmark.synchronized_arrayList  avgt   25  10.374 ± 0.427  ns/op

結論：

如您所見，同步 ArrayList 的影響是顯著的。

使用 JDK 11，即使使用了偏向鎖定，平均延遲也會增加 29%。

在 JDK 17 中，同步 ArrayList 的影響甚至更差，因為基準的平均延遲要高出 52%。在 JDK 15 中，偏向鎖定已默認禁用，即將被完全洗掉。所以它很可能是一個促成因素。

'有趣'的是JDK 11的同步版本比17的非同步版本更快。我不確定原因是什么；可能與 GC 更改有關。

我把它作為練習留給讀者。JMH 有一些很棒的分析器。我要做的第一件事是擺脫分配，從而排除垃圾收集器。

uj5u.com熱心網友回復：

synchronization，當它實際使用時，確實需要花費。然而，hotspot 在意識到互斥體實際上并沒有做任何有用的事情并消除它方面是相當不錯的。這就是你所看到的。

那么，為什么不ArrayList直接同步開箱/為什么不建議“使用 Vector，而不是 ArrayList”？許多不同的原因：

最重要的帶回家的原因（其余的只是歷史特性）：因為同步串列幾乎沒有用。見下文。
現代JVM 非常擅長消除不做任何事情的同步。這就是為什么您很難使用簡單的時序代碼來查看任何差異的原因。但情況并非總是如此。ArrayList 是在 java 1.2 中引入的。Vector（具有不同 API 的同步陣列串列）比這更早：1.0。ArrayList 的引入有兩個不同的原因：部分是為了清理該 API，部分是因為“同步它！” 很慢。現在它不再慢了，但是 Java 1.2 已經23 歲了。如果您可以在任何地方找到它并報告給我，請在 java 1.2 上重新運行您的代碼：)
關于 Vector 的所有內容都已棄用、過時且不習慣。部分原因僅僅是“因為”。23 年前，“使用 ArrayList，而不是 Vector”的建議是正確的，原因有很多。包括“因為它更快”（即使今天不再如此）。現在使用 ArrayList 而不是 Vector 的原因主要是：“因為 ArrayList 是每個人都熟悉的，Vector 不是，當在羅馬表現得像羅馬人時，不要無緣無故地搖擺不定”。這以各種實用的方式出現：例如，“Vector”這個名稱現在在 Java 生態系統中被用于完全不同的東西（訪問不完全是 64 位的硬體暫存器，是 Project Panama 的一部分）。

為什么同步串列大多沒用？

非同步（“執行緒安全”）實作完全中斷；規范說：任何事情都有可能發生。同步（“執行緒安全”）實作不會完全中斷；相反，您會得到 1 個選項排列，但無法保證哪些選項的可能性更大或更小。不過，這并不比完全混亂更有用！例如，如果我撰寫以下代碼：

List a = new Vector<String>();
Thread x = new Thread(() -> a.add("Hello"));
Thread y = new Thread(() -> a.add("World"));
x.start();
y.start();
System.out.println(a);

那么這個應用列印是合法的[Hello, World]，但是這個應用列印也是合法的[World, Hello]。沒有辦法知道，VM 可以自由地總是回傳一個，或者總是回傳另一個，或者擲硬幣，或者讓它取決于月相。矢量是同步的，這對我來說仍然沒用。沒有人愿意撰寫需要處理排列組合爆炸的演算法！

然而，對于不是“執行緒安全”的 ArrayList，情況會變得更糟。這里有更多的排列方式。JVM 可以在不破壞規范的情況下執行以下任何操作：

[你好世界]
[世界，你好]
[你好]
[世界]
[空，你好]
[世界，世界]
[]
[WhatTheHeckReally]
暫停，通過揚聲器系統播放 macarena，然后崩潰。

任何事情都會發生 - 規范說行為是未指定的。在實踐中，前4個都是完全可能的。

避免這種混亂是好的，但同步 Vector 提供的排列只是......不太糟糕。但仍然很糟糕，所以誰在乎呢？您希望此代碼 100% 可靠：您希望代碼每次都做同樣的事情（除非我想要隨機性，但是使用java.util.Randomwhich 的規范明確說明它是如何隨機的。執行緒可以是非隨機的，所以如果你必須有隨機性，你也不能使用它）。

為了使事情可靠，操作需要由物件本身完成（您呼叫 ONE 方法，這是您的執行緒與它進行的唯一互動），或者您需要外部鎖。

例如，如果我想將 '1' 放入一個尚未存在的鍵的哈希圖中，并增加數字（如果是），則此代碼不起作用：

Map<String, Integer> myMap = Collections.synchronizedMap(new HashMap<>());

...

String k = ...;
if (myMap.containsKey(k)) myMap.put(k, myMap.get(k)   1);
else myMap.put(k, 1);

看起來不錯？不，壞了：

執行緒 1 呼叫 myMap.containsKey 并看到答案是false.
執行緒 1 恰好在 if 之后，put.
執行緒 2 運行，并為同一個鍵遞增。它也發現myMap,containsKey回傳錯誤。因此它運行myMap.put(k, 1)。
執行緒 1 繼續運行，并運行.. myMap.put(k, 1)
地圖現在包含k = 1，即使incrementFor(k)運行了兩次。您的應用程式已損壞。

看？同步？在這里完全沒用。你想要的是一個鎖：

synchronized (something) {
  String k = ...;
  if (myMap.containsKey(k)) myMap.put(k, myMap.get(k)   1);
  else myMap.put(k, 1);
}

and this is completely fine - no matter how had you try running incrementFor(k) simultaneously, it'll dutifully count every invocation, or, better yet, we ask the map to do it for us, to have a map that just has an increment function or similar. HashMap does not. I guess Collections.synchronizedList could return an object that has extra methods, but as the name suggest, that implementation then neccessarily uses locking, and there are more efficient ways to do it.

This task is better done with ConcurrentHashMap, and using the right method:

ConcurrentHashMap<String, Integer> myMap = new ConcurrentHashMap<>();

...

myMap.merge(k, 1, (a, b) -> a   b);

That does it in one call. (merge is the same as .put(k, 1) if k isn't in the map already, but if it is, it is the same as .put(k, RESULT) where RESULT is the result of running a b where a is 'what was in the map' and 'b' is the value you are trying to add (So, 1, in this case).

A non-synchronized list can still mess up a single call, but if your 'job' involves more than one call, a synchronized one in the sense of e.g. Collections.synchronizedMap or j.u.Vector cannot safely do this.

最后，這就是為什么建議不要使用同步的東西的原因——即使它可能不是真正的性能問題，但這樣做幾乎沒有意義。如果您確實有并發需求，那么在內部同步事物不太可能對您有所幫助，并且在這種情況下，包中的某些更具體的型別java.util.concurrent可能會更快地完成它（因為當并發發生時，synchronized絕對不是免費的）。

轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/412303.html

標籤：

上一篇：為Java中的多執行緒應用程式提供每日更新快取的最佳實踐

下一篇：如何在不使用Sleep()的情況下讓執行緒自行等待？