concurrenthashmap | 易学教程

Is it possible for ConcurrentHashMap to “deadlock”?

阅读更多关于 Is it possible for ConcurrentHashMap to “deadlock”?

问题 We have come across a strange issue with ConcurrentHashMap , where two threads appears to be calling put() , and then waiting forever inside the method Unsafe.park() . From the outside, it looks like a deadlock inside ConcurrentHashMap . We have only seen this happen once so far. Can anyone think of anything that could cause these symptoms? EDIT : The thread dump for the relevant threads is here: "[redacted] Thread 2" prio=10 tid=0x000000005bbbc800 nid=0x921 waiting on condition

ConcurrentHashMap源码分析(JDK1.7和JDK1.8)

阅读更多关于 ConcurrentHashMap源码分析(JDK1.7和JDK1.8)

ConcurrentHashMap是Java中使用非常普遍的一个Map，ConcurrentHashMap较HashMap而言极大提高了并发操作速度，我们知道HashMap是线程不安全的，在多线程环境下容易出现死锁，线程安全的HashTable（包括SynchronizedMap）由于对每次操作都加锁导致效率非常低，我们都知道Map一般都是数组+链表结构（JDK1.8可能为数组+红黑树），ConcurrentHashMap避免了对全局加锁改成了局部加锁操作，这样就极大地提高了并发环境下的操作速度，ConcurrentHashMap在JDK1.7和1.8中的实现非常不同，接下来我们会分别对1.7和1.8中的实现原理做分析。 ConcurrentHashMap（JDK1.7）在JDK1.7中ConcurrentHashMap采用了数组+Segment+分段锁的方式实现，Segment是ConcurrentHashMap（后续此ConcurrentHashMap都泛指JDK1.7中实现）一个非常重要的部分，Segment继承了ReentrantLock因此拥有了锁的功能，Segment中维护了HashEntry数组table，HashEntry本质是一个K-V存储结构，内部存储了目标对象的Key和Value

Should you check if the map containsKey before using ConcurrentMap's putIfAbsent

阅读更多关于 Should you check if the map containsKey before using ConcurrentMap's putIfAbsent

问题 I have been using Java's ConcurrentMap for a map that can be used from multiple threads. The putIfAbsent is a great method and is much easier to read/write than using standard map operations. I have some code that looks like this: ConcurrentMap<String, Set<X>> map = new ConcurrentHashMap<String, Set<X>>(); // ... map.putIfAbsent(name, new HashSet<X>()); map.get(name).add(Y); Readability wise this is great but it does require creating a new HashSet every time even if it is already in the map.

Recursive ConcurrentHashMap.computeIfAbsent() call never terminates. Bug or “feature”?

阅读更多关于 Recursive ConcurrentHashMap.computeIfAbsent() call never terminates. Bug or “feature”?

Some time ago, I've blogged about a Java 8 functional way of calculating fibonacci numbers recursively , with a ConcurrentHashMap cache and the new, useful computeIfAbsent() method: import java.util.Map; import java.util.concurrent.ConcurrentHashMap; public class Test { static Map<Integer, Integer> cache = new ConcurrentHashMap<>(); public static void main(String[] args) { System.out.println( "f(" + 8 + ") = " + fibonacci(8)); } static int fibonacci(int i) { if (i == 0) return i; if (i == 1) return 1; return cache.computeIfAbsent(i, (key) -> { System.out.println( "Slow calculation of " + key);

What is the difference between Collectors.toConcurrentMap and converting a Map to ConcurrentHashMap via Collectors.toMap supplier option?

阅读更多关于 What is the difference between Collectors.toConcurrentMap and converting a Map to ConcurrentHashMap via Collectors.toMap supplier option?

问题 I want to convert a Map into a ConcurrentHashMap via Java 8 Stream and Collector interface, and there are two options I can use. The first: Map<Integer, String> mb = persons.stream() .collect(Collectors.toMap( p -> p.age, p -> p.name, (name1, name2) -> name1+";"+name2, ConcurrentHashMap::new)); And the second: Map<Integer, String> mb1 = persons.stream() .collect(Collectors.toConcurrentMap( p -> p.age, p -> p.name)); Which one is the better option? When should I use each option? 回答1: There is

Atomically incrementing counters stored in ConcurrentHashMap

阅读更多关于 Atomically incrementing counters stored in ConcurrentHashMap

问题 I would like to collect some metrics from various places in a web app. To keep it simple, all these will be counters and therefore the only modifier operation is to increment them by 1. The increments will be concurrent and often. The reads (dumping the stats) is a rare operation. I was thinking to use a ConcurrentHashMap . The issue is how to increment the counters correctly. Since the map doesn't have an "increment" operation, I need to read the current value first, increment it than put

Is gcc std::unordered_map implementation slow? If so - why?

阅读更多关于 Is gcc std::unordered_map implementation slow? If so - why?

问题 We are developing a highly performance critical software in C++. There we need a concurrent hash map and implemented one. So we wrote a benchmark to figure out, how much slower our concurrent hash map is compared with std::unordered_map . But, std::unordered_map seems to be incredibly slow... So this is our micro-benchmark (for the concurrent map we spawned a new thread to make sure that locking does not get optimized away and note that I never inser 0 because I also benchmark with google:

HashMap、HashTable、ConcurrentHashMap

阅读更多关于 HashMap、HashTable、ConcurrentHashMap

HashTable :底层数组+链表，无论key还是value都不能为null，线程安全，实现线程安全的方式是在修改数据时锁住整个HashTable，效率低，ConcurrentHashMap做了相关优化，初始化size为11，扩容后oldSize*2+1,计算index方法是index=(hash & 0x7FFFFFFF) %tab.length HashMap:底层数组+链表实现，可以存储null键和null值，线程不安全。初始zise为16，扩容newsize=oldsize*2,size一定是2的n次幂。扩容针对整个Map，每次扩容时，原来数组的元素一次重新计算存放位置，并重新插入，插入元素才判断要不要扩容，有可能扩容无效（插入后扩容，如果没有再次插入，就会产生无效扩容），当Map中元素总数超过Entry数组的75%，触发扩容操作，为了减少链表长度，元素分配更均匀，index计算方法：index=hash &(tab.length-1) HashMap的初始值还要考虑加载因子：哈希冲突：若干key的哈希值数组大小取模后，如果落在同一个数组下标上，将组成一条Entry链，对key的查找需要遍历每个Entry链上的元素执行equals()比较。加载因子：为了降低哈希冲突的概率，默认当HashMap中的键值对达到数组大小的75%时，就会触发扩容，因此如果预估容量是100

ConcurrentHashMap的使用

阅读更多关于 ConcurrentHashMap的使用

一.ConcurrentHashMap的简要总结： 1、public V get(Object key)不涉及到锁，也就是说获得对象时没有使用锁； 2、put、remove方法要使用锁，但并不一定有锁争用，原因在于ConcurrentHashMap将缓存的变量分到多个Segment，每个Segment上有一个锁，只要多个线程访问的不是一个Segment就没有锁争用，就没有堵塞，各线程用各自的锁，ConcurrentHashMap缺省情况下生成16个Segment，也就是允许16个线程并发的更新而尽量没有锁争用； 3、Iterator对象的使用，不一定是和其它更新线程同步，获得的对象可能是更新前的对象， ConcurrentHashMap允许一边更新、一边遍历，也就是说在Iterator对象遍历的时候，ConcurrentHashMap也可以进行remove,put操作，且遍历的数据会随着remove,put操作产出变化，所以希望遍历到当前全部数据的话，要么以ConcurrentHashMap变量为锁进行同步(synchronized该变量)，要么使用CopiedIterator包装iterator，使其拷贝当前集合的全部数据，但是这样生成的iterator不可以进行remove操作。二.Hashtable和ConcurrentHashMap的不同点： 1

并发容器ConcurrentHashMap

阅读更多关于并发容器ConcurrentHashMap

ConcurrentHashMap Hashmap多线程会导致HashMap的Entry链表形成环形数据结构，一旦形成环形数据结构，Entry的next节点永远不为空，就会产生死循环获取Entry。 HashTable使用synchronized来保证线程安全，但在线程竞争激烈的情况下HashTable的效率非常低下。因为当一个线程访问HashTable的同步方法，其他线程也访问HashTable的同步方法时，会进入阻塞或轮询状态。如线程1使用put进行元素添加，线程2不但不能使用put方法添加元素，也不能使用get方法来获取元素，所以竞争越激烈效率越低。 putIfAbsent() ：没有这个值则放入map，有这个值则返回key本来对应的值。 Hash 散列，哈希：把任意长度的输入通过一种算法（散列），变换成为固定长度的输出，这个输出值就是散列值。属于压缩映射，容易产生哈希冲突。Hash算法有直接取余法等。产生哈希冲突时解决办法：开放寻址；2、再散列；3、链地址法（相同hash值的元素用链表串起来）。 ConcurrentHashMap在发生hash冲突时采用了链地址法。 md4,md5,sha-hash算法也属于hash算法，又称摘要算法。位运算 int 类型的位高位低位 ConcurrentHashMap

订阅 concurrenthashmap