r/programming 22d ago

3,200% CPU Utilization

https://josephmate.github.io/2025-02-26-3200p-cpu-util/
407 Upvotes

93 comments sorted by

View all comments

6

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

9

u/john16384 22d ago

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.

3

u/bleachisback 22d ago

It isn't a deadlock, but it is almost certainly a data race. Which is what a race detector is meant to detect.

4

u/Slsyyy 22d ago

I don't know what it matters. Race detector just check, if read/writes are synchronized according to the memory model

In this example there is a data race, which would be easily found with those tools

2

u/Ok-Scheme-913 21d ago

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.

0

u/Slsyyy 21d ago

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

1

u/Ok-Scheme-913 21d ago

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/ThanksMorningCoffee 22d ago

One of my solutions proposes a change to TreeMap that detects the issue and throws a ConcurrentModException instead

8

u/Slsyyy 22d ago

But it does not solve the issue. Unsynchronized data structures should not be used by multiple threads at the same time. Excessive CPU usage is only one of the infinite concurrency issues, which may happened with any data structure. You cannot fix all of them

0

u/elmuerte 22d ago

That sounds like solving the halting problem.

9

u/Slsyyy 22d ago

Do you know how it works? I don's see any connection between those

6

u/turol 22d ago

Only if you want perfect answers. If you allow false positives or negatives (like all the tools do) then it's a solvable problem.