concurrenthashmap

HashMap和HashTable有何不同？ 线程安全： HashTable 中的方法是同步的，而HashMap中的方法在默认情况下是非同步的。在多线程并发的环境下，可以直接使用HashTable，但是要使用HashMap的话就要自己增加同步处理了。 继承关系： HashTable是基于陈旧的Dictionary类继承来的。 HashMap继承的抽象类AbstractMap实现了Map接口。 允不允许null值： HashTable中，key和value都不允许出现null值，否则会抛出NullPointerException异常。 HashMap中，null可以作为键，这样的键只有一个；可以有一个或多个键所对应的值为null。 默认初始容量和扩容机制： HashTable中的hash数组初始大小是11，增加的方式是 old*2+1。HashMap中hash数组的默认大小是16，而且一定是2的指数。原因参考全网把Map中的hash()分析的最透彻的文章，别无二家。-HollisChuang's Blog 哈希值的使用不同 ： HashTable直接使用对象的hashCode。 HashMap重新计算hash值。 遍历方式的内部实现上不同 ： Hashtable、HashMap都使用了 Iterator。而由于历史原因，Hashtable还使用了Enumeration的方式 。

concurrentMap() function Have WARNING: DATA RACE , And fatal error : concurrent map read and map write concurrentStruct() have WARNING: DATA RACE, But running ok why the struct can DATA RACE? package main import ( "sync" ) func main() { // concurrentMap() concurrentStruct() // concurrentStructWithMuLock() } type Metadata struct { mu sync.RWMutex // 🔐 key bool } // concurrentStruct 并发操作结构体 // concurrent read and write the struct // go run -race main.go 有 WARNING: DATA RACE，但是可以运行 // go run -race main.go It have WARNING: DATA RACE, But running ok func concurrentStruct() { m := new(Metadata) for

Can any concurrent expert explain in ConcurrentHashMap, which concurrent features improved comparing with which in previous JDKs Well, the ConcurrentHashMap has been entirely rewritten. Before Java 8, each ConcurrentHashMap had a “concurrency level” which was fixed at construction time. For compatibility reasons, there is still a constructor accepting such a level though not using it in the original way. The map was split into as many segments, as its concurrency level, each of them having its own lock, so in theory, there could be up to concurrency level concurrent updates, if they all

为了线程安全，ConcurrentHashMap 引入了一个 “分段锁” 的概念。具体可以理解把一个大的 map 拆分成 N 个小的 Map 。最后再根据 key.hashcode( )来决定放到哪一个 hashmap 中去。 hashmap 本质是数组+链表，根据 key.hashcode( ) 计算出数组对应下标。如果多个 key 对应同一个下标，用一个链表串起来，新数据在前面。 ConcurrentHashMap ：在 hashmap 基础上，ConcurrentHashMap 将数据分解成多个 segment (默认 16 个），每次操作对 segment 加锁，避免多线程锁的几率，提高并发效率。 来源： https://my.oschina.net/u/3973793/blog/3096629

i have a project, and i am build this project with jdk 6,7,8 and my target is 1.6 when i build jdk 8 i get this error: Undefined reference: java.util.concurrent.ConcurrentHashMap.KeySetView java.util.concurrent.ConcurrentHashMap.keySet() since i have this code in that line: final Iterator<CLASS_NAME> itr = hashMap.keySet().iterator(); how can avoid error, i made some search in internet, and since java 8 changed its return type keyset, i got error. is this any solution. i am using maven, and animal-sniffer-plugin gives this error, with signature error. Another Answer suggests a modification to

Is ConcurrentHashMap.get() guaranteed to see a previous ConcurrentHashMap.put() by different thread? My expectation is that is is, and reading the JavaDocs seems to indicate so, but I am 99% convinced that reality is different. On my production server the below seems to be happening. (I've caught it with logging.) Pseudo code example: static final ConcurrentHashMap map = new ConcurrentHashMap(); //sharedLock is key specific. One map, many keys. There is a 1:1 // relationship between key and Foo instance. void doSomething(Semaphore sharedLock) { boolean haveLock = sharedLock.tryAcquire(3000,

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 [0x0000000040e93000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to

java并发初探ConcurrentHashMap Doug Lea在java并发上创造了不可磨灭的功劳，ConcurrentHashMap体现这位大师的非凡能力。 1.8中ConcurrentHashMap的线程安全 1.volatile Node<k,v> []table保证数组的可见性 2.get操作没有加锁 3.put操作调用final V putVal(K key, V value, boolean onlyIfAbsent) ，在方法内部为Syncronized方法加锁，Syncronized据说在1.8得到优化 4.扩容的方法不是Syncronized，而在数据迁移的时候通过Syncronized迁移数据 5.多线程putVal(K key, V value, boolean onlyIfAbsent)，通过helpTransfer帮助数组扩容（binCount），然后继续添加元素 （binCount！=0跳出） else if ((fh = f.hash) == MOVED) tab = helpTransfer(tab, f); 6.多线程下扩容，因为扩容是多线程共同进行，而且锁住了首节点，能够快速扩容 else if ((f = tabAt(tab, i)) == null)//锁住节点 advance = casTabAt(tab, i, null, fwd)

原创转载请注明出处： https://www.cnblogs.com/agilestyle/p/11395881.html 分段锁 分段锁其实是一种锁的设计，并不是具体的一种锁，对于ConcurrentHashMap而言，其并发的实现就是通过分段锁的形式来实现高效的并发操作。 并发容器类的加锁机制是基于粒度更小的分段锁，分段锁也是提升多并发程序性能的重要手段之一。 在并发程序中，串行操作是会降低可伸缩性，并且上下文切换也会减低性能。在锁上发生竞争时将通水导致这两种问题，使用独占锁时保护受限资源的时候，基本上是采用串行方式 —— 每次只能有一个线程能访问它。所以对于可伸缩性来说最大的威胁就是独占锁。 一般有三种方式降低锁的竞争程度： 1、减少锁的持有时间 2、降低锁的请求频率 3、使用带有协调机制的独占锁，这些机制允许更高的并发性。 在某些情况下可以将锁分解技术进一步扩展为一组独立对象上的锁进行分解，这成为分段锁。 其实说的简单一点就是： 容器里有多把锁，每一把锁用于锁容器其中一部分数据，那么当多线程访问容器里不同数据段的数据时，线程间就不会存在锁竞争，从而可以有效的提高并发访问效率，这就是ConcurrentHashMap所使用的锁分段技术，首先将数据分成一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据的时候，其他段的数据也能被其他线程访问。 比如

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? Holger 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 = new ReservationNode<K,V>(); synchronized (r) { if (casTabAt(tab, i, null, r)) { Right at this