I think the article has some good points, but he should spend more time discussing what circumstances you can block when waiting for a result, and how to balanc

I think the article has some good points, but he should spend more time discussing what circumstances you can block when waiting for a result, and how to balance too much blocking against too many asynchronous states. I think his focus on “global mutable state” is a bit of a red herring. It makes no difference whether the mutable state is global (protected by a lock) or owned by a single thread. You can refactor all your synchronized {...} blocks and replace them with executor.execute(futuretask); futuretask.get();, where executor is a single-threaded event loop and futuretask.get() blocks for the operation to complete. This refactoring would make a single thread the owner of the state, but there would be exactly the same number of deadlocks. Conceptually, you can think of your critical sections as a separate thread on which you invoke methods and then block until completion. After refactoring to use Executor and BlockingQueue, one still has to make sure there are no cycles in which threads are allowed to block waiting for which other threads.