A classic deadlock requires at least two threads circularly waiting on each other, so it can't happen in the traditional sense with a single thread — but a single thread can still lock itself up permanently through a related failure mode sometimes called self-deadlock.
Key Points: • Self-deadlock occurs when a thread tries to reacquire a lock it already holds, but the lock implementation is non-reentrant and blocks it from doing so. • Java's intrinsic synchronized locks are reentrant, so a thread re-entering a synchronized block it already owns never self-deadlocks this way. • Custom or third-party lock implementations that aren't reentrant are where this issue actually shows up in practice. • The symptom looks similar to a deadlock — the thread simply waits forever — but the root cause and fix (reentrant-aware locking or restructuring the code to avoid recursive acquisition) are different from a multi-thread deadlock. • True deadlocks (circular waits between threads) require at least two threads and two or more locks acquired in inconsistent order.
Example: If a thread holding a custom non-reentrant lock recursively calls a method that tries to acquire the same lock again, it ends up waiting forever for itself to release a lock it's still holding — a self-inflicted deadlock rather than the usual two-thread circular wait.
Interview Tip: A concise interview answer is:
"A true deadlock needs at least two threads waiting on each other, so it can't happen with just one. But a single thread can effectively deadlock itself, called self-deadlock, if it tries to reacquire a non-reentrant lock it already holds — Java's own synchronized keyword avoids this because intrinsic locks are reentrant."