Two threads occasionally deadlock while transferring state between two in-memory accounts. How would you diagnose and prevent it?

Prevent deadlocks with consistent lock ordering

Finds circular lock acquisition and replaces timing-dependent nested locking with a stable order or a simpler ownership boundary.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would capture thread dumps or runtime traces while the process is stuck and identify which thread owns each lock and which lock it is waiting for. In the transfer example, thread A may lock account 1 then wait for account 2 while thread B locks account 2 then waits for account 1. I would make every transfer acquire account locks in one stable order, such as by account ID, regardless of transfer direction. I would also keep the critical section short and avoid I/O or blocking waits while holding either lock.

Full answer below

Practice focus

Wait-for cycles, stable lock ordering, critical-section scope, diagnostics, timeouts, nested-lock removal, and distinction from database deadlocks.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Deadlocks are structural cycles, not merely slow locks. A reliable answer identifies the ownership graph and removes the cycle instead of adding arbitrary delays until reproduction becomes harder.
I would capture thread dumps or runtime traces while the process is stuck and identify which thread owns each lock and which lock it is waiting for. In the transfer example, thread A may lock account 1 then wait for account 2 while thread B locks account 2 then waits for account 1. I would make every transfer acquire account locks in one stable order, such as by account ID, regardless of transfer direction. I would also keep the critical section short and avoid I/O or blocking waits while holding either lock.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
The ordering rule must be centralized, because one call path that reverses it can restore the cycle. I would normalize the two resources first, acquire the lower key and then the higher key, validate the invariant, update both, and release in reverse scope through structured blocks. If the workflow can be redesigned so one owner processes transfers sequentially, that may be clearer than nested locks. A timeout can expose and recover from excessive waiting, but it does not prove the state is safe or remove the deadlock condition.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Adding sleeps so the two operations are less likely to overlap.
Using a timeout as proof that a partially completed transfer is safe.
Applying the ordering rule in one method while other paths acquire locks directly.
Holding account locks while calling an external service or database.

Two threads occasionally deadlock while transferring state between two in-memory accounts. How would you diagnose and prevent it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Was this drill useful?

Found this answer useful?

Human editorial direction

Two threads occasionally deadlock while transferring state between two in-memory accounts. How would you diagnose and prevent it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Start a conversation

Was this drill useful?

Found this answer useful?

Human editorial direction