Hashmap in multithreaded environment when doing resizing

Question

I am following a tutorial and it basically explains about the cause of race condition which happens when resizing Hashmap in a multithreaded environment:

Answer 1

I don't know if the example is valid. What is clear is that it is implementation-specific. I think it also misses the bigger picture.

HashMap's contract clear states (emphasis theirs):

If multiple threads access a hash map concurrently, and at least one of the threads modifies the map structurally, it must be synchronized externally. (A structural modification is any operation that adds or deletes one or more mappings; merely changing the value associated with a key that an instance already contains is not a structural modification.)

If you break the contract, all bets are off. The map is free to blow up in arbitrary, unspecified, ways.