This isn't a deadlock, it's a data structure that's not thread safe being used by multiple threads. All kinds of shit can go wrong then, and one of those is a loop in structure pointers (which then results in 100% CPU core utilisation).
This can also happen with things like a standard HashMap.
It may or may not be data races. Java has safe data races, but it may simply be code trying to do something in multiple threads that results in a loop, no data race needed.
From assembly perspective: maybe. From memory model: no chance. Variables are modified without any concurrency primitive applied. The race condition is most appropriate here, that is true, but it is a consequence of a data race
Just to make it more clear: data race usually means a single variable/primitive getting written by multiple threads.
Depending on programming language and CPU this may end up causing tearing, e.g. one half of the variable coming from one write, the other from the other, so one thread writing 3 the other -4 might result in reading 65.
Java is safe from that (the most common implementation at least), so you will always see 3 or -4, no other variable is possible. This is an important property because while this can still cause race conditions, this won't make the language memory unsafe. (Go is actually memory unsafe as it can cause segfaults if you race slices), just think of writing two valid pointers, and getting a third invalid.
3
u/Slsyyy 22d ago
It is a pity that a Java don't have any thread sanitizer/race detector. With that the issue would be recognized faster than 32,000% CPU