Suppose we have a ConcurrentHashMap of size 16 .i.e concurrency level 16. If number of threads working on this map is greater than 16 i.e. somewhere 20 to 25 then what will happen to the extra threads whether they will be in waiting state?
If yes then how long they will be in waiting state and internally how they will communicate with other threads?
There's nothing magic about the concurrency level. Even if you have fewer than 16 threads in your example, they still can collide when attempting to access the map.
If the concurrency level is 16, then when any two threads try to put two different keys into the map, there will be one chance in 16 that the two keys are assigned to the same segment. If that's the case, then their access to the segment will have to be serialized. (i.e., one of the threads will have to be blocked until the other thread has finished.)
Of course, if two threads try to access the same key at the same time then it's guaranteed that they will access the same segment and one will be blocked, no matter what the concurrency level.
what will happen to the extra threads whether they will be in waiting state?
Nothing. That's what a synchronized statement does. It does nothing (a.k.a., it "blocks") until the lock becomes available. Then, it acquires the lock, performs the body of the statement, and releases the lock.
how long they will be in waiting state?
A thread that is blocked on a mutex lock will remain blocked until the lock is released by some other thread. In well designed code, that should only be a very short time---just long enough for the other thread to update a few fields.
internally how they will communicate with other threads?
Not sure what you mean by "internally". A thread that is blocked can't communicate with other threads. It can't do anything until it is unblocked.
Maybe you are asking how the operating system knows what to unblock, and when.
When a thread attemts to lock a mutex that already is in use by some other thread, the operating system will suspend the thread, save its state, and put some token that represents the thread into a queue that is associated with the mutex. When the owner of the thread releases the mutex, the OS picks a thread from the queue, transfers ownership of the mutex to the selected thread, restores the thread's saved state, and lets it run.
The algorithms that different operating systems use to select which thread to unblock, and the means of saving and restoring thread contexts (a.k.a., "context switch") are deeper subjects than I have room or time to discuss here.