Q: What is the difference between HashMap and Hashtable?
1. HashMap is not thread safe, HashTable is thread safe.
2. Because of thread safety, the efficiency of HashTable is not as efficient as HashMap.
3. HashMap only allows the key of one record to be null at most, and allows multiple records to have the value null, but HashTable does not allow it.
4. The default initialization array size of HashMap is 16, and HashTable is 11. The former expands twice when it is expanded, and the latter expands twice by +1.
5. HashMap needs to recalculate the hash value, while HashTable directly uses the hashCode of the object.
Q: What is another thread-safe class similar to HashMap in Java? It is also thread safe. What is the difference between it and Hashtable in terms of thread synchronization?
ConcurrentHashMap class (a thread-safe and efficient HashMap implementation provided in the Java concurrency package java.util.concurrent).
Hashtable is the principle of using the synchronized keyword to lock (lock the object).
For ConcurrentHashMap, a segmented lock method is used in JDK1.7. In JDK1.8, CAS (lock-free algorithm)+synchronized+red-black tree is directly adopted, and the method of segmented lock is also adopted and the granularity of the lock is greatly reduced.
Q: What is the difference between HashMap&ConcurrentHashMap?
Except for locking, the principle is not much different.
In addition, the key-value pair of HashMap allows null, but ConcurrentHashMap does not allow it. In terms of data structure, it is a node class related to red-black trees.
Q: Why is ConcurrentHashMap more efficient than HashTable?
1. Hashtable uses a lock (locking the entire linked list structure) to deal with concurrency issues. Multiple threads compete for a lock, which is easy to block.
2. ConcurrentHashMap uses segmented locks in JDK1.7, which is equivalent to dividing a HashMap into multiple segments, and assigning a lock to each segment. This supports multi-threaded access and lock granularity: Based on Segment, it contains multiple HashEntry.
3. Use CAS+synchronized+Node+red-black tree in JDK1.8. Lock granularity: Node (first node), the lock granularity is reduced.
Q: Specific analysis for ConcurrentHashMap lock mechanism (JDK1.7 VS JDK1.8)?
In JDK1.7, a segmented lock mechanism is used to implement concurrent update operations. The bottom layer uses an array + linked list storage structure, including two core static internal classes Segment and HashEntry.
1. Segment inherits ReentranLock (reentrant lock) to act as a lock. Each Segment object guards several buckets of each hash map.
2. HashEntry is used to encapsulate the key-value pairs of the mapping table.
3. Each bucket is a linked list connected by several HashEntry objects.
JDK1.8 uses Node+CAS+Synchronized to ensure concurrency safety. Cancel the class Segment and directly use the table array to store key-value pairs. When the length of the linked list composed of HashEntry objects exceeds TREEIFY_THRESHOLD, the linked list is converted to a red-black tree to improve performance. The bottom layer is changed to array + linked list + red-black tree.
Q: ConcurrentHashMap in JDK1.8, why use the built-in lock synchronized instead of the reentrant lock ReentranLock?
After Jdk1.5, heavyweight locks are no longer born fat. It is a fat man who slowly swells and finally becomes a fat man. The expansion process is the bias lock, lightweight lock (spin lock), and heavyweight lock.
The details here will continue to be detailed in other articles. We only need to know that in the case of minimal concurrency, our Synchronized will do a process similar to delay and fattening.
ConcurrentHashMap1.8 reduces the granularity of the lock again, so is the possibility of concurrent contention high? Also, even if there is contention, as long as the thread can get the lock within 30 to 50 spins, then Synchronized is It will not be upgraded to a heavyweight lock, and the waiting thread will not be suspended, and we will reduce the process overhead of suspending and waking up the context switch.
Therefore, when the lock has been refined to such a degree, using Synchronized has once again become the best choice.
Q: What is the concurrency of ConcurrentHashMap?
In JDK1.7, the maximum number of threads that can update ConcurrentHashMap at the same time when the program is running without lock contention is 16 by default, and can be set in the constructor. When the user sets the concurrency, ConcurrentHashMap will use the smallest power of 2 exponent greater than or equal to this value as the actual concurrency (if the user sets the concurrency to 17, the actual concurrency is 32).
The concurrency in 1.8 does not have much practical significance. The main use is to set the initial capacity to be smaller than the concurrency and increase the initial capacity to the degree of concurrency.
Q: Introduction to the process of ConcurrentHashMap?
See the blogger's blog spike ConcurrentHashMap for a detailed introduction.