2. 程式人生 > >執行緒安全Map比較

執行緒安全Map比較

阿新 • • 發佈：2018-11-05

如何執行緒安全的使用HashMap

2016年09月02日 13:37:32

在週二面試時，一面的面試官有問到HashMap是否是執行緒安全的，如何線上程安全的前提下使用HashMap,其實也就是HashMap，Hashtable，ConcurrentHashMap和synchronized Map的原理和區別。當時有些緊張只是簡單說了下HashMap不是執行緒安全的；Hashtable執行緒安全，但效率低，因為是Hashtable是使用synchronized的，所有執行緒競爭同一把鎖；而ConcurrentHashMap不僅執行緒安全而且效率高，因為它包含一個segment陣列，將資料分段儲存，給每一段資料配一把鎖，也就是所謂的鎖分段技術。當時忘記了synchronized Map和解釋一下HashMap為什麼執行緒不安全。面試結束後問了下面試官哪裡有些不足，面試官說上面這個問題的回答算過關，但可以在深入一些或者自己動手嘗試一下。so~~~雖然拿到了offer，但還是再整理一下，不能得過且過啊。

為什麼HashMap是執行緒不安全的

總說HashMap是執行緒不安全的，不安全的，不安全的，那麼到底為什麼它是執行緒不安全的呢？要回答這個問題就要先來簡單瞭解一下HashMap原始碼中的使用的儲存結構(這裡引用的是Java 8的原始碼，與7是不一樣的)和它的擴容機制。

HashMap的內部儲存結構

下面是HashMap使用的儲存結構:



 

1

2

3

4

5

6

7

8

transient Node<K,V>[] table;

 

static class Node<K,V> 

implements Map.Entry<K,V> {

        final int hash;

        final K key;

        V value;

        Node<K,V> next;

}

 


 

可以看到HashMap內部儲存使用了一個Node陣列(預設大小是16)，而Node類包含一個型別為Node的next的變數，也就是相當於一個連結串列，所有hash值相同(即產生了衝突)的key會儲存到同一個連結串列裡，大概就是下面圖的樣子(順便推薦個線上畫圖的網站Creately)。
HashMap內部儲存結果HashMap內部儲存結果

需要注意的是，在Java 8中如果hash值相同的key數量大於指定值(預設是8)時使用平衡樹來代替連結串列，這會將get()方法的效能從O(n)提高到O(logn)。具體的可以看我的另一篇部落格Java 8中HashMap和LinkedHashMap如何解決衝突。

HashMap的自動擴容機制

HashMap內部的Node陣列預設的大小是16，假設有100萬個元素，那麼最好的情況下每個hash桶裡都有62500個元素，這時get(),put(),remove()等方法效率都會降低。為了解決這個問題，HashMap提供了自動擴容機制，當元素個數達到陣列大小loadFactor後會擴大陣列的大小，在預設情況下，陣列大小為16，loadFactor為0.75，也就是說當HashMap中的元素超過16\0.75=12時，會把陣列大小擴充套件為2*16=32，並且重新計算每個元素在新陣列中的位置。如下圖所示(圖片來源，權侵刪)。
自動擴容

自動擴容

從圖中可以看到沒擴容前，獲取EntryE需要遍歷5個元素，擴容之後只需要2次。

為什麼執行緒不安全

個人覺得HashMap在併發時可能出現的問題主要是兩方面,首先如果多個執行緒同時使用put方法新增元素，而且假設正好存在兩個put的key發生了碰撞(hash值一樣)，那麼根據HashMap的實現，這兩個key會新增到陣列的同一個位置，這樣最終就會發生其中一個執行緒的put的資料被覆蓋。第二就是如果多個執行緒同時檢測到元素個數超過陣列大小*loadFactor，這樣就會發生多個執行緒同時對Node陣列進行擴容，都在重新計算元素位置以及複製資料，但是最終只有一個執行緒擴容後的陣列會賦給table，也就是說其他執行緒的都會丟失，並且各自執行緒put的資料也丟失。
關於HashMap執行緒不安全這一點，《Java併發程式設計的藝術》一書中是這樣說的：

HashMap在併發執行put操作時會引起死迴圈，導致CPU利用率接近100%。因為多執行緒會導致HashMap的Node連結串列形成環形資料結構，一旦形成環形資料結構，Node的next節點永遠不為空，就會在獲取Node時產生死迴圈。

哇塞，聽上去si不si好神奇，居然會產生死迴圈。。。。google了一下，才知道死迴圈並不是發生在put操作時，而是發生在擴容時。詳細的解釋可以看下面幾篇部落格：

如何執行緒安全的使用HashMap

瞭解了HashMap為什麼執行緒不安全，那現在看看如何執行緒安全的使用HashMap。這個無非就是以下三種方式：

  • Hashtable
  • ConcurrentHashMap
  • Synchronized Map

例子：



 

1

2

3

4

5

6

7

8

//Hashtable

Map<String, String> hashtable = new Hashtable<>();

 

//synchronizedMap

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

 

//ConcurrentHashMap

Map<String, String> concurrentHashMap = new ConcurrentHashMap<>();

 


 

依次來看看。

Hashtable

先稍微吐槽一下，為啥命名不是HashTable啊，看著好難受，不管了就裝作它叫HashTable吧。這貨已經不常用了，就簡單說說吧。HashTable原始碼中是使用synchronized來保證執行緒安全的，比如下面的get方法和put方法：



 

1

2

3

4

5

6

public synchronized V get(Object key) {

       // 省略實現

    }

public synchronized V put(K key, V value) {

    // 省略實現

    }

 


 

所以當一個執行緒訪問HashTable的同步方法時，其他執行緒如果也要訪問同步方法，會被阻塞住。舉個例子，當一個執行緒使用put方法時，另一個執行緒不但不可以使用put方法，連get方法都不可以，好霸道啊！！！so~~，效率很低，現在基本不會選擇它了。

ConcurrentHashMap

ConcurrentHashMap(以下簡稱CHM)是JUC包中的一個類，Spring的原始碼中有很多使用CHM的地方。之前已經翻譯過一篇關於ConcurrentHashMap的部落格，如何在java中使用ConcurrentHashMap，裡面介紹了CHM在Java中的實現，CHM的一些重要特性和什麼情況下應該使用CHM。需要注意的是，上面部落格是基於Java 7的，和8有區別,在8中CHM摒棄了Segment（鎖段）的概念，而是啟用了一種全新的方式實現,利用CAS演算法，有時間會重新總結一下。

SynchronizedMap

看了一下原始碼，SynchronizedMap的實現還是很簡單的。



 

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

// synchronizedMap方法

public static <K,V> Map<K,V> synchronizedMap(Map<K,V> m) {

       return new SynchronizedMap<>(m);

   }

// SynchronizedMap類

private static class SynchronizedMap<K,V>

       implements Map<K,V>, Serializable {

       private static final long serialVersionUID = 1978198479659022715L;

 

       private final Map<K,V> m;     // Backing Map

       final Object      mutex;        // Object on which to synchronize

 

       SynchronizedMap(Map<K,V> m) {

           this.m = Objects.requireNonNull(m);

           mutex = this;

       }

 

       SynchronizedMap(Map<K,V> m, Object mutex) {

           this.m = m;

           this.mutex = mutex;

       }

 

       public int size() {

           synchronized (mutex) {return m.size();}

       }

       public boolean isEmpty() {

           synchronized (mutex) {return m.isEmpty();}

       }

       public boolean containsKey(Object key) {

           synchronized (mutex) {return m.containsKey(key);}

       }

       public boolean containsValue(Object value) {

           synchronized (mutex) {return m.containsValue(value);}

       }

       public V get(Object key) {

           synchronized (mutex) {return m.get(key);}

       }

 

       public V put(K key, V value) {

           synchronized (mutex) {return m.put(key, value);}

       }

       public V remove(Object key) {

           synchronized (mutex) {return m.remove(key);}

       }

       // 省略其他方法

   }

 


 

從原始碼中可以看出呼叫synchronizedMap()方法後會返回一個SynchronizedMap類的物件，而在SynchronizedMap類中使用了synchronized同步關鍵字來保證對Map的操作是執行緒安全的。

效能對比

這是要靠資料說話的時代，所以不能只靠嘴說CHM快，它就快了。寫個測試用例，實際的比較一下這三種方式的效率(原始碼來源)，下面的程式碼分別通過三種方式建立Map物件，使用ExecutorService來併發執行5個執行緒，每個執行緒新增/獲取500K個元素。



 

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

public class CrunchifyConcurrentHashMapVsSynchronizedMap {

 

    public final static int THREAD_POOL_SIZE = 5;

 

    public static Map<String, Integer> crunchifyHashTableObject = null;

    public static Map<String, Integer> crunchifySynchronizedMapObject = null;

    public static Map<String, Integer> crunchifyConcurrentHashMapObject = null;

 

    public static void main(String[] args) throws InterruptedException {

 

        // Test with Hashtable Object

        crunchifyHashTableObject = new Hashtable<>();

        crunchifyPerformTest(crunchifyHashTableObject);

 

        // Test with synchronizedMap Object

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

        crunchifyPerformTest(crunchifySynchronizedMapObject);

 

        // Test with ConcurrentHashMap Object

        crunchifyConcurrentHashMapObject = new ConcurrentHashMap<>();

        crunchifyPerformTest(crunchifyConcurrentHashMapObject);

 

    }

 

    public static void crunchifyPerformTest(final Map<String, Integer> crunchifyThreads) throws InterruptedException {

 

        System.out.println("Test started for: " + crunchifyThreads.getClass());

        long averageTime = 0;

        for (int i = 0; i < 5; i++) {

 

            long startTime = System.nanoTime();

            ExecutorService crunchifyExServer = Executors.newFixedThreadPool(THREAD_POOL_SIZE);

 

            for (int j = 0; j < THREAD_POOL_SIZE; j++) {

                crunchifyExServer.execute(new Runnable() {

                    @SuppressWarnings("unused")

                    @Override

                    public void run() {

 

                        for (int i = 0; i < 500000; i++) {

                            Integer crunchifyRandomNumber = (int) Math.ceil(Math.random() * 550000);

 

                            // Retrieve value. We are not using it anywhere

                            Integer crunchifyValue = crunchifyThreads.get(String.valueOf(crunchifyRandomNumber));

 

                            // Put value

                            crunchifyThreads.put(String.valueOf(crunchifyRandomNumber), crunchifyRandomNumber);

                        }

                    }

                });

            }

 

            // Make sure executor stops

            crunchifyExServer.shutdown();

 

            // Blocks until all tasks have completed execution after a shutdown request

            crunchifyExServer.awaitTermination(Long.MAX_VALUE, TimeUnit.DAYS);

 

            long entTime = System.nanoTime();

            long totalTime = (entTime - startTime) / 1000000L;

            averageTime += totalTime;

            System.out.println("2500K entried added/retrieved in " + totalTime + " ms");

        }

        System.out.println("For " + crunchifyThreads.getClass() + " the average time is " + averageTime / 5 + " ms\n");

    }

}

 


 

測試結果：



 

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

Test started for: class java.util.Hashtable

2500K entried added/retrieved in 2018 ms

2500K entried added/retrieved in 1746 ms

2500K entried added/retrieved in 1806 ms

2500K entried added/retrieved in 1801 ms

2500K entried added/retrieved in 1804 ms

For class java.util.Hashtable the average time is 1835 ms

 

Test started for: class java.util.Collections$SynchronizedMap

2500K entried added/retrieved in 3041 ms

2500K entried added/retrieved in 1690 ms

2500K entried added/retrieved in 1740 ms

2500K entried added/retrieved in 1649 ms

2500K entried added/retrieved in 1696 ms

For class java.util.Collections$SynchronizedMap the average time is 1963 ms

 

Test started for: class java.util.concurrent.ConcurrentHashMap

2500K entried added/retrieved in 738 ms

2500K entried added/retrieved in 696 ms

2500K entried added/retrieved in 548 ms

2500K entried added/retrieved in 1447 ms

2500K entried added/retrieved in 531 ms

For class java.util.concurrent.ConcurrentHashMap the average time is 792 ms

 


 

這個就不用廢話了，CHM效能是明顯優於Hashtable和SynchronizedMap的,CHM花費的時間比前兩個的一半還少，哈哈，以後再有人問就可以甩資料了。

相關推薦

執行緒安全Map比較

如何執行緒安全的使用HashMap 2016年09月02日 13:37:32 標籤： java / hashmap / 執行緒安全 / 8116 編輯 刪除 在週二面試時，一面的面試官有問到HashMap

執行緒安全的Map的實現方式3種

1. HashMap,TreeMap 未進行同步考慮，是執行緒不安全的。 2. HashTable 和 ConcurrentHashMap 都是執行緒安全的。區別在於他們對加鎖的範圍不同，HashTable 對整張Hash表進行加鎖，而ConcurrentHashMap將Hash表分為16桶(s

高併發下map和chan實現的連結池的執行緒安全及效率

1.背景 上一次blog寫著寫著崩掉了，這次一定寫完一節儲存一節。 目前從事go語言的後臺開發，在叢集通訊時需要用到thrift的rpc。由於叢集間通訊非常頻繁且併發需求很高，所以只能採用連線池的形式。由於叢集規模是有限的，每個節點都需要儲存平行節點的連線，所以

golang執行緒安全的map

網上找的協程安全的map都是用互斥鎖或者讀寫鎖實現的，這裡用單個協程來實現下，即所有的增刪查改操作都整合到一個goroutine中，這樣肯定不會出現多執行緒併發訪問的問題。 基本思路是後臺啟動一個長期執行的goroutine，阻塞的接受自己channel中的請求req，req分為不同的請求，

golang帶有key過期的執行緒安全的map->expiredMap

github地址：https://github.com/hackssssss/ExpiredMap 偶然間看到一篇關於超期刪除key的map的文章，感覺很有意思，於是自己去實現了一下。 瞭解了一下redis中key的過期策略，發現主要有三種策略：一種是被動刪除，即key過期之後，先不將其

List set map特點及執行緒安全與否

感謝：http://blog.csdn.net/u011084603/article/details/49108585 List特點：元素有放入順序，元素可重複  Map特點：元素按鍵值對儲存，無放入順序  Set特點：元素無放入順序，元素不可重複（注意：元素雖然無放

golang多個routine操作map或者slice的多執行緒安全問題

由於map、slice為引用型別，所以即使函式傳值呼叫，引數副本依然指向對映m/切片s, 所以n個goroutine併發寫同一個對映m/切片s， 寫過多執行緒程式的童鞋都知道，對於共享變數，資源，併發讀寫會產生競爭的， 故共享資源遭到破壞， 所以要麼加鎖， 要麼用channel排隊序列化， 總之要排

Map執行緒安全幾種實現方法

如果需要使 Map 執行緒安全，大致有這麼四種方法：  1、使用 synchronized 關鍵字，程式碼如下 synchronized(anObject) {  　　value = map.get(key); } 2、使用 JDK1.5提供的鎖（j

如何實現一個執行緒安全的map？

我們都知道，map是執行緒不安全的，那麼我們如何才能實現一個執行緒安全的map呢？ 這裡介紹4種實現方式： 1、使用synchronized來進行約束： synchronized(obj){     value = map.get(key); } 2、使用JDK1.5版本

c++執行緒安全的map

參考了 《c++併發程式設計實戰》這本書上的程式碼寫了一個執行緒安全可以併發的map/* * threadsafe_map.cpp * * Created on: May 11, 2018 * Author: clh01s * 執行緒安全的查詢

面試必問－幾種執行緒安全的Map解析

HashMap執行緒安全的嗎？Java中平時用的最多的Map集合就是HashMap了，它是執行緒不安全的。看下面兩個場景：1、當用在方法內的區域性變數時，區域性變數屬於當前執行緒級別的變數，其他執行緒訪問不了，所以這時也不存線上程安全不安全的問題了。2、當用在單例物件成員變數

C/C++程式設計教訓----函式內靜態類物件初始化非執行緒安全（C++11之前）

不少程式設計師在編寫程式的時候，會使用函式內靜態(static)變數，既能滿足函式內這個變數可以持久的記錄某些資訊，又使其訪問範圍的控制侷限於函式內。但函式內靜態類物件初始化是非執行緒安全的。 問題背景 在我們產品中對log4cxx做了一些簡單的封裝 （採用VS2005編譯），其中會

十二、JVM(HotSpot)執行緒安全與鎖優化----終結篇

注：本博文主要是基於JDK1.7會適當加入1.8內容。 執行緒安全：當多個執行緒訪問一個物件時，如果不用考慮這些執行緒在執行環境下的排程和交替執行，也不需要進行額外的同步，或者在呼叫方進行任何其他的協調操作，呼叫這個物件的行為可以獲取正確的結果，那這個物件就是執行緒安全的。 1、Ja

Java多執行緒程式設計中執行緒的同步與互斥/執行緒安全/Java鎖

摘要：多執行緒三個特徵:原子性、可見性以及有序性.&gt;執行緒的同步與互斥?(同步執行緒與非同步執行緒,執行緒同步和非同步問題)&nbsp;&nbsp;1.同步:假設現有執行緒A和執行緒B,執行緒A需要往緩衝區寫資料,執行緒B需要從緩衝區讀資料,但他們之間存在一種制約

併發程式設計之多執行緒執行緒安全

什麼是執行緒安全？ 為什麼有執行緒安全問題？ 當多個執行緒同時共享，同一個全域性變數或靜態變數，做寫的操作時，可能會發生資料衝突問題，也就是執行緒安全問題。但是做讀操作是不會發生資料衝突問題。 案例: 需求現在有100張火車票，有兩個視窗同時搶火車票，請使用多執行緒模擬搶票效果。 p

Qt中實現執行緒安全的單例模式

之前專案中用到單例模式，用的是執行緒不安全的，這次專案用到了多執行緒，所以想到實現一個執行緒安全的單例模式。經過查詢資料，發現Qt本身有自己的執行緒安全單例模式實現方式。 Q_GLOBAL_STATIC巨集 使用方法：MonitorWindow.h #ifndef MONITORW

二、執行緒安全阻塞佇列 BlockingQueue 入門

一、BlockingQueue繼承關係 java.util.concurrent 包裡的 BlockingQueue是一個介面， 繼承Queue介面，Queue介面繼承 Collection BlockingQueue --> Queue –-> Collection

三、執行緒安全阻塞佇列 BlockingQueue 詳解

轉載自： https://www.cnblogs.com/WangHaiMing/p/8798709.html 本篇將詳細介紹BlockingQueue，以下是涉及的主要內容： BlockingQueue的核心方法 阻塞佇列的成員的概要介紹 詳細介紹DelayQu

設計模式之單例模式【內附物件例項化幾種方式、實現執行緒安全幾種方式】

繼續來複習常用的設計模式-單例模式，順便回憶一下執行緒安全的幾種實現方式。 一、什麼是單例模式 單例模式，簡單常用的一種設計模式，也很好的體現了程式碼控制物件在記憶體數量的一種方式，主要分2種實現方式： ①餓漢式，執行緒安全 ②懶漢式，執行緒不安全（新增鎖機制，可以實現執行緒安全）

java多執行緒2.執行緒安全之可見性

要編寫正確的併發程式，關鍵在於：在訪問共享的可變狀態時需要進行正確的管理 可見性： 同步的另一個重要目的——記憶體可見性。 我們不僅希望防止某個執行緒正在使用物件狀態而另一個執行緒同時在修改狀態，而且希望當一個執行緒修改了物件狀態後，其他執行緒能夠看到發生的狀態變化（互斥訪問/通訊效果