关于并发hashmap的内部工作 [英] Regarding internal working of concurrent hashmap

查看:107
本文介绍了关于并发hashmap的内部工作的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在通过 ConcurrentHashMap 此相关教程,并有一些问题。

I was going through the ConcurrentHashMap and this related tutorial, and had some questions.


  1. 在这篇文章中,提到 ConcurrentHashMap 允许多个读者同时读取而没有任何阻止。这是通过基于并发级别将Map分割成不同的部分并在更新期间仅锁定一部分Map来实现的。默认并发级别为16,因此Map将其分为16个部分,每个部分由不同的锁定。这意味着,16个线程可以同时操作Map,直到它们在Map的不同部分上运行。尽管保持线程安全性,这使得 ConcurrentHashMap 具有高性能。虽然它有一个警告:由于更新操作,如 put() remove() putAll() clear()未同步,并发检索可能无法反映地图上最近的更改

  1. In the article, it was mention that ConcurrentHashMap allows multiple readers to read concurrently without any blocking. This is achieved by partitioning the Map into different parts based on concurrency level and locking only a portion of the Map during updates. Default concurrency level is 16, and accordingly the Map is divided into 16 part and each part is governed with a different lock. This means, 16 threads can operate on Map simultaneously, until they are operating on different parts of the Map. This makes ConcurrentHashMap high performant despite keeping thread-safety intact. Though, it comes with a caveat: Since update operations like put(), remove(), putAll() or clear() are not synchronized, concurrent retrieval may not reflect the most recent change on the Map

文章中还提到了另一点:另一个要记住的重点是在CHM上迭代,Iterator由 keySet 是弱一致的,它们只反映某一点的 ConcurrentHashMap 的状态,可能不会反映任何最近的更改

Another point also mentioned in the article: Another important point to remember is iteration over CHM, Iterator returned by keySet are weakly consistent and they only reflect state of ConcurrentHashMap at a certain point and may not reflect any recent change.

我没有明白粗体突出显示的点,你能提供更多的信息还是在简单的程序中显示? >

I have not understood the points highlighted in bold, could you provide more info or show me in a simple program?

推荐答案



由于更新操作,如put(),remove ,putAll()或clear()不同步,并发检索可能无法反映地图上最近的变化

Since update operations like put(), remove(), putAll() or clear() is not synchronized, concurrent retrieval may not reflect most recent change on Map

据了解,这意味着在一个线程中修改地图可能不一定在另一个线程中同时进行的检索中看到。考虑以下示例:

As I understand it, this means that a modification of the map in one thread may not necessarily be seen by a retrieval happening at the same time in another thread. Consider the following example:

                  Thread 1 starts              Thread 1's call to get("a")
                 a call to get("a")             completes, returning null
                         |                                 |
Thread 1        ---------+---------------------------------+-------
                             time ----->
Thread 2        -----+---------------------------+-----------------
                     |                           |
             Thread 2 starts a            Thread 2's call to
            call to put("a", 1)          put("a", 1) completes

即使线程2 放置地图中的值线程1的获取完成执行,线程1没有看到地图修改,并返回 null

Even though Thread 2 put a value in the map Thread 1's get completed execution, Thread 1 did not "see" the map modification, and returned null.

另一个要记住的重点是在CHM上迭代,由ConcurrentHashMap的keySet返回的Iterator每周一致,只反映ConcurrentHashMap和某些点的状态,可能不会反映任何最近的变化。

Another important point to remember is iteration over CHM, Iterator returned by keySet of ConcurrentHashMap are weekly consistent and they only reflect state of ConcurrentHashMap and certain point and may not reflect any recent change.

这是一个类似的情况。如果线程1从 ConcurrentHashMap keySet Iterator >,然后线程2在地图中放置一个新条目,线程1的迭代器不能保证看到该条目。 (它可能或不可能。)

This is a similar situation. If Thread 1 obtains an Iterator from a ConcurrentHashMap's keySet, and later Thread 2 puts a new entry in the map, Thread 1's Iterator is not guaranteed to see that entry. (It may or it may not.)

这篇关于关于并发hashmap的内部工作的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆