concurrenthashmap | 易学教程

ConcurrentHashMap.newKeySet() vs Collections.newSetFromMap()

阅读更多关于 ConcurrentHashMap.newKeySet() vs Collections.newSetFromMap()

问题 Java 8 introduced new way to obtain a concurrent Set implementation // Pre-Java-8 way to create a concurrent set Set<String> oldStyle = Collections.newSetFromMap(new ConcurrentHashMap<>()); // New method in Java 8 Set<String> newStyle = ConcurrentHashMap.newKeySet(); Is there any reason to prefer new method? Any advantages/disadvantages? 回答1: ConcurrentHashMap.newKeySet() should be somewhat more efficient as removes a single level of indirection. Collections.newSetFromMap(map) is mostly based

Segmentation in ConcurrentHashMap

阅读更多关于 Segmentation in ConcurrentHashMap

问题 I am a newbie to the world of Java and I was exploring the ConcurrentHashMap API in which I discovered this: static final int DEFAULT_INITIAL_CAPACITY = 16; static final float DEFAULT_LOAD_FACTOR = 0.75F; static final int DEFAULT_CONCURRENCY_LEVEL = 16; static final int MAXIMUM_CAPACITY = 1073741824; static final int MAX_SEGMENTS = 65536; static final int RETRIES_BEFORE_LOCK = 2; final Segment<K, V>[] segments; final Segment<K, V> segmentFor(int paramInt) { return this.segments[(paramInt >>>

并发容器之ConcurrentHashMap

阅读更多关于并发容器之ConcurrentHashMap

　　JDK5中添加了新的concurrent包，相对同步容器而言，并发容器通过一些机制改进了并发性能。因为同步容器将所有对容器状态的访问都串行化了，这样保证了线程的安全性，所以这种方法的代价就是严重降低了并发性，当多个线程竞争容器时，吞吐量严重降低。因此Java5.0开始针对多线程并发访问设计，提供了并发性能较好的并发容器，引入了java.util.concurrent包。与Vector和Hashtable、 Collections.synchronizedXxx()同步容器等相比，util.concurrent中引入的并发容器主要解决了两个问题： 1）根据具体场景进行设计，尽量避免synchronized，提供并发性。 2）定义了一些并发安全的复合操作，并且保证并发环境下的迭代操作不会出错。　　util.concurrent中容器在迭代时，可以不封装在synchronized中，可以保证不抛异常，但是未必每次看到的都是"最新的、当前的"数据。　　下面是对并发容器的简单介绍：　　ConcurrentHashMap代替同步的Map（Collections.synchronized（new HashMap()）），众所周知，HashMap是根据散列值分段存储的，同步Map在同步的时候锁住了所有的段

Lock handler for arbitrary keys

阅读更多关于 Lock handler for arbitrary keys

问题 I have code which implements a "lock handler" for arbitrary keys. Given a key , it ensures that only one thread at a time can process that(or equals) key (which here means calling the externalSystem.process(key) call). So far, I have code like this: public class MyHandler { private final SomeWorkExecutor someWorkExecutor; private final ConcurrentHashMap<Key, Lock> lockMap = new ConcurrentHashMap<>(); public void handle(Key key) { // This can lead to OOM as it creates locks without removing

ConcurrentHashMap jdk 8 Uses TreeNodes instead of List .. Why? [closed]

阅读更多关于 ConcurrentHashMap jdk 8 Uses TreeNodes instead of List .. Why? [closed]

问题 Closed . This question needs to be more focused. It is not currently accepting answers. Want to improve this question? Update the question so it focuses on one problem only by editing this post. Closed 5 years ago . Hi i know the workings of ConcurrentHashMap before JDK 8. I also understood the code: it was pretty modular and not very hard to understand. The code of ConcurrentHashMap in JDK 8 has changed a lot from its previous implementations. Because this question was classified as too

Using ConcurrentHashMap, when is synchronizing necessary?

阅读更多关于 Using ConcurrentHashMap, when is synchronizing necessary?

问题 I have a ConcurrentHashMap where I do the following: sequences = new ConcurrentHashMap<Class<?>, AtomicLong>(); if(!sequences.containsKey(table)) { synchronized (sequences) { if(!sequences.containsKey(table)) initializeHashMapKeyValue(table); } } My question is - is it unnecessary to make the extra if(!sequences.containsKey(table)) Check inside the synschronized block so other threads wont initialize the same hashmap value? Maybe the check is necessary and I am doing it wrong? It seems a bit

hashmap和hashtable

阅读更多关于 hashmap和hashtable

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

Synchronizing on local variable

阅读更多关于 Synchronizing on local variable

问题 I noticed a weird construct in ConcurrentHashMap's compute and computeIfAbsent methods: Node<K,V> r = new ReservationNode<K,V>(); synchronized (r) { //... } What is the point of synchronizing on a local object considering that the JIT will most likely treat it as a no-op? 回答1: Right after the code has acquired the object’s monitor, the reference to the object is stored into the tab which is the globally visible array of nodes which make up the contents of the ConcurrentHashMap : Node<K,V> r =

ConcurrentHashMap in Java?

阅读更多关于 ConcurrentHashMap in Java?

问题 What is the use of ConcurrentHashMap in Java? What are its benefits? How does it work? Sample code would be useful too. 回答1: The point is to provide an implementation of HashMap that is threadsafe. Multiple threads can read from and write to it without the chance of receiving out-of-date or corrupted data. ConcurrentHashMap provides its own synchronization, so you do not have to synchronize accesses to it explicitly. Another feature of ConcurrentHashMap is that it provides the putIfAbsent

Is iterating ConcurrentHashMap values thread safe?

阅读更多关于 Is iterating ConcurrentHashMap values thread safe?

问题 In javadoc for ConcurrentHashMap is the following: Retrieval operations (including get) generally do not block, so may overlap with update operations (including put and remove). Retrievals reflect the results of the most recently completed update operations holding upon their onset. For aggregate operations such as putAll and clear, concurrent retrievals may reflect insertion or removal of only some entries. Similarly, Iterators and Enumerations return elements reflecting the state of the