Summarize the difference between HashTable, HashMap, ConcurrentHashMap

1. Use a hash table in a multi-threaded environment

HashMap itself is not thread-safe.

Using a hash table in a multi-threaded environment can use:

Hashtable (deprecated)
ConcurrentHashMap (recommended)

1)HashMap

First of all, HashMap itself is not thread-safe
Secondly, the key value of HashMap can be empty

The following is the hash method of HashMap. It can be seen that if the key value is empty, the return value of the hash method is 0
insert image description here

The expansion of HashMap is to wait for a certain put to find that the load factor is not up to standard and then start to expand, create a new table, and re-hash the elements (details will be discussed later)

2）Hashtable

If the key in the put method in the Hashtable source code is empty, the hashCode method will throw a null pointer exception

insert image description here

for example:

insert image description here

**The thread safety of HashTable is simply to add the synchronized keyword to the key method. **

insert image description here

It is equivalent to directly locking the Hashtable object itself.

If multiple threads access the same Hashtable, it will directly cause lock conflicts.
The size attribute is also controlled by synchronized, which is also relatively slow.
Once the expansion is triggered, the entire expansion process will be completed by this thread. This process will involve a large number of element copies, and the efficiency will be very low.

insert image description here

A Hashtable has only one lock. When two threads access any data in the Hashtable, there will be lock competition. As shown in the figure above, two threads need to operate these two elements. Since it is a large lock, there will be competition, but carefully Analysis, these two operations are on different hash buckets, and do not involve modifying the same variable, so thread safety will not occur, so the above lock competition is unnecessary.

If two modifications fall on the same hash bucket, there is a thread safety risk

3）ConcurrentHashMap

In contrast, ConcurrentHashMap has made a major improvement, refining the granularity of locks

The read operation is not locked (but volatile is used to ensure that the result is read from the memory), and only the write operation is locked. The method of locking is still synchronized, but instead of locking the entire object, it is a "lock bucket" (using The head node of each linked list is used as the lock object), which greatly reduces the probability of lock conflicts.
Make full use of CAS features. For example, the size attribute is updated through CAS. Avoid heavyweight locks.
Optimized the way of expansion: split into parts
- To find a thread that needs to be expanded, you only need to create a new array and move only a few elements to it.
- During expansion, the old and new arrays exist at the same time.
- Each subsequent thread that operates ConcurrentHashMap will participate in the moving process. Each operation is responsible for moving a small number of elements.
- After moving the last element, delete the old array.
- During this period, inserts only add to the new array.
- During this period, the search needs to search both the new array and the old array

insert image description here

At this time, the number of buckets on a hash table may be very large, resulting in the probability of lock conflicts, greatly reducing the

Expansion = applying for larger memory + moving elements (the process of moving elements must be re-hashed)

The above is based on Java 8; in Java 1.7, ConcurrentHashMap does not have a lock for each bucket, but a "segmented lock" where one lock manages several buckets

insert image description here

The key of ConcurrenHashMap cannot be empty either. See the put method in the source code below. If key==null, a null pointer exception will be thrown.

insert image description here