Loading...
The memory model, executors, locks, atomics, virtual threads, and diagnosing races and deadlocks.
3 questions in Java & Spring.
Virtual threads make blocking cheap by unmounting from their carrier OS thread whenever they block, so thread-per-request scales to hundreds of thousands of concurrent tasks. Finalised in JDK 21, they do nothing for CPU-bound work, and pooling them defeats their purpose.
Thread safety composes per operation, not across operations. A get followed by a put is two atomic steps with a legal interleaving between them. You close the window by making the whole compound action one operation, such as compute or merge, or by holding a single lock across both steps.
It guarantees visibility and ordering: a volatile write happens-before every later read of that field, so everything the writer did beforehand becomes visible to the reader. It guarantees nothing about atomicity, so an increment is still a race and a volatile reference says nothing about the object it points to.