Resizing Concurrent Hash Map

Question

What is the amount of memory penalty for a Concurrent Hash Map resize. Specifically what I am looking for are

Q1. Does the size of the concurrent hash map double? What I have read indicates the resize is done per bucket, but does not indicate what is the increase in the number of buckets

Q2. If the size of the concurrent hash map increases, how are the nodes moved to the correct buckets as the hash codes might be different now. Specifically elements are added based on hash codes, so how are nodes moved around with re-hashing.

Answer 1

1. This is an implementation detail, and is intentionally not documented. By not documenting it the JDK developers are free to make performance improvements and tradeoffs without breaking any contracts. You should avoid writing any code that makes assumptions about undocumented behavior such as how a collection will be resized. The current implementation is documented in the class's comments if you're interested in reading them, but understand that they can and do change over time.

2. This similarly is an implementation detail, but your statement that "the hash codes might be different now" is incorrect; both HashMap and ConcurrentHashMap are documented to behave incorrectly in the face of keys with changing hashcodes. Therefore we can assume the hashcodes do not change - it is only the position where the object is stored that changes.

   Suppose for example our bucketing algorithm was simply hashcode % size - if a bin has 4 slots and an object's hashcode is 78 then it would be place in bin 2 (78 % 4 = 2). If the bin is resized to 8 slots the object would be moved to bin 6 (78 % 8 = 6). The JDK classes use more elegant bucketing algorithms, but the concept is the same.