The memory model, executors, locks, atomics, virtual threads, and diagnosing races and deadlocks.
4 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.
A thread-safe connection pool pairs a Semaphore of N permits, which bounds how many connections exist and gives acquire its timeout, with a queue of idle connections. Acquire returns a lease that releases exactly once from a finally block, and a broken connection is discarded without losing its permit.
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.