concurrenthashmap

I am testing ConcurrentHashMap on Oracle's Java 8 implementation: ConcurrentMap<String, String> concurrentMap = new ConcurrentHashMap<>(); String result = concurrentMap.computeIfAbsent("A", k -> "B"); System.out.println(result); // "B" result = concurrentMap.putIfAbsent("AA", "BB"); System.out.println(result); // null The Javadoc of computeIfAbsent does say that Implementation Requirements: The default implementation is equivalent to the following steps for this map, then returning the current value or null if now absent: if (map.get(key) == null) { V newValue = mappingFunction.apply(key); if

I have written a timer which will measure the performance of a particular code in any multithreaded application. In the below timer, it will also populate the map with how many calls took x milliseconds. I will use this map as part of my histogram to do further analysis, like what percentage of calls took this much milliseconds and etc. public static class StopWatch { public static ConcurrentHashMap<Long, Long> histogram = new ConcurrentHashMap<Long, Long>(); /** * Creates an instance of the timer and starts it running. */ public static StopWatch getInstance() { return new StopWatch(); }

ConcurrentHashMap is often used in concurrent environments for aggregation of some events under a key - like counting hits for some string values. In case we don't know the keys in advance we need to have a good way to initialize key on need, it should to be fast and safe in terms of concurrency. What is the best pattern (in terms of efficiency) for this problem? I will use a model map with <String, AtomicInteger> declared like: ConcurrentHashMap<String, AtomicInteger> map = new ConcurrentHashMap<>(); But it could be a map with any key-value pair, where we need to initialize a key-value pair

is final Map<Integer,Map<String,Integer>> status = new ConcurrentHashMap<Integer, Map<String,Integer>>(); Map<Integer,Map<String,Integer>> statusInner = new ConcurrentHashMap<Integer, Map<String,Integer>>(); status.put(key,statusInner); the same as volatile Map<Integer,Map<String,Integer>> status = new ConcurrentHashMap<Integer, Map<String,Integer>>(); Map<Integer,Map<String,Integer>> statusInner = new ConcurrentHashMap<Integer, Map<String,Integer>>(); status.put(key,statusInner); in case the inner Map is accessed by different Threads? or is even something like this required: volatile Map

一、HashMap分析 　　在JDK1.8之前，hashMap由数组+链表组成，1.8之后，对hashMap进行了一些修改，最大的不同就是利用了红黑树，所以其由数组+链表+红黑树组成。查找时，根据hash值我们能够快速定位到数组的具体下标，但是之后的话，需要顺着链表一个个比较下去才能找到我们需要的，时间复杂度取决于链表的长度为O(n)，为了降低这部分的开销，在Java8中，当链表中的元素达到了8个时，会将链表转换为红黑树，在这些位置进行查找时可以降低时间复杂度为O(logn)。 1.put过程：（JDK1.8） 　　　第一次put值时，会触发resize()，类似Java7的第一次put也是要初始化数组长度的。 　　　第一次resize和后续的扩容有些不一样，因为这次是数组从null初始化到默认的16或自定义的初始容量，找到具体的数据下标，如果此位置没有值，那么直接初始化一下Node并放置在这个位置就可以了。如果数组改为只有数据：首先，判断该位置的第一个数据和我们要插入的数据，key是不是“相等”，如果是，取出这个节点，如果该节点是代表红黑树的节点，调用红黑树的插值方法，插入到链表的最后面（Java7是插入到链表的最前面），当treeify_threshold为8时，如果新插入的值是链表中的第8个，会触发下面的treeifyBin，也就是将链表转换为红黑树；如果在该链表中找到了

Back to concurrency. By now it is clear that for the double checked locking to work the variable needs to be declared as volatile . But then what if double checked locking is used as below. class Test<A, B> { private final Map<A, B> map = new HashMap<>(); public B fetch(A key, Function<A, B> loader) { B value = map.get(key); if (value == null) { synchronized (this) { value = map.get(key); if (value == null) { value = loader.apply(key); map.put(key, value); } } } return value; } } Why does it really have to be a ConcurrentHashMap and not a regular HashMap ? All map modification is done within

首先需要知道几个名词： 公平锁/非公平锁 可重入锁 独享锁/共享锁 互斥锁/读写锁 乐观锁/悲观锁 分段锁 偏向锁/轻量级锁/重量级锁 自旋锁 公平锁/非公平锁： 公平锁是指多个线程按照申请锁的顺序来获取锁。 非公平锁是指多个线程获取锁的顺序并不是按照申请锁的顺序，有可能后申请的线程比先申请的线程优先获取锁。有可能，会造成优先级反转或者饥饿现象。 可重入锁： 可重入锁又名递归锁，是指在同一个线程在外层方法获取锁的时候，在进入内层方法会自动获取锁。 独享锁/共享锁： 独享锁是指该锁一次只能被一个线程所持有。 共享锁是指该锁可被多个线程所持有。 互斥锁/读写锁 上面讲的独享锁/共享锁就是一种广义的说法，互斥锁/读写锁就是具体的实现。 乐观锁/悲观锁 乐观锁与悲观锁不是指具体的什么类型的锁，而是指看待并发同步的角度。 悲观锁认为对于同一个数据的并发操作，一定是会发生修改的，哪怕没有修改，也会认为修改。因此对于同一个数据的并发操作，悲观锁采取加锁的形式。悲观的认为，不加锁的并发操作一定会出问题。 乐观锁则认为对于同一个数据的并发操作，是不会发生修改的。在更新数据的时候，会采用尝试更新，不断重新的方式更新数据。乐观的认为，不加锁的并发操作是没有事情的。 从上面的描述我们可以看出，悲观锁适合写操作非常多的场景，乐观锁适合读操作非常多的场景，不加锁会带来大量的性能提升。 悲观锁在Java中的使用