JDK7 multi-threaded concurrent environment HashMap infinite loop infinite loop, CPU full 100%, Java
The underlying data implementation of HashMap is an array + linked list, and the linked list is loaded with new data after a hash collision, like a bucket.
In the implementation of HashMap in JDK7, there is an infinite loop problem in the concurrent environment . One of the results is that the program runs to a certain time in a multi-threaded concurrent environment, and the CPU is 100% full. After the process is killed and started, the program returns to normal, but when it is started again, it runs to a certain time in a multi-threaded concurrent environment. ( The infinite loop starts after the get operation ), and the CPU will be pulled to 100% (in an infinite loop).
The expansion of HashMap in a concurrent multi-threaded environment causes an infinite loop. Usually, when initializing HashMap, there will be a loadFactore load factor such as 0.75. When the size of the original stored element reaches 0.75 of the inherent length, the expansion will start. During the expansion process, the nodes of the oldTable single-linked list will be inserted into the newTable single-linked list, and the newTable will be single-linked. The linked list inverts the singly linked list in oldTable.
Therefore, in the multi-threaded concurrent expansion scenario, it is likely that the expanded HashMap will generate a single-linked list with a ring, which will lead to an endless loop of subsequent data fetching, and the CPU will be 100% full.
The order of the new linked list is completely opposite to that of the old linked list. As long as the new link is built in the original order, there will be no cycle. JDK8 uses head and tail to ensure that the order of the linked list is the same as before, and there will be no circular reference.
Conclusion: In JDK8, Java corrected this problem, but HashMap always has thread safety problems. For example, concurrent put will cause data overwriting, so avoid using HashMap in a multi-threaded concurrent environment. If it is a concurrent multi-threaded environment, please:
1. ConcurrentHashMap replaces HashMap.
2. Use synchronized or lock to lock HashMap. (low efficiency)
LinkedHashMap implements LRU cache cache mechanism, Kotlin_zhangphil's blog-CSDN blog * * Based on Java LinkedList, implements Android big data caching strategy * Author: Zhang Phil * Original source: http://blog.csdn.net/zhangphil * * Implementation principle: The principle model believes that: the head element in LinkedList is the oldest cached data, which is cached in L_android big data. In one sentence: the biggest difference between the two is that HashMap does not guarantee the order of the data put in; for example, if elements are added sequentially and sequentially in HashMap: 1, 2, 3, 4, 5, when traversing HashMap The output is in order. https://blog.csdn.net/zhangphil/article/details/132604797 Similarities and differences between Java's HashMap and LinkedHashMap_zhangphil's blog-CSDN blogIn one sentence: the biggest difference between the two is that HashMap does not guarantee put in The order of the data; LinkedHashMap guarantees the order of the data put in. In other words, the order of data added to HashMap and the order of data during traversal are not necessarily the same; while LinkedHashMap guarantees what is the order of data when adding and what is the order of data when traversing. For example, if elements are added sequentially and sequentially in the HashMap: 1, 2, 3, 4, 5, the order output when traversing the HashMap
https://blog.csdn.net/zhangphil/article/details/44115629