I am reading the book Java Concurrency in Practice, and here is what it says about deadlock.
JVM does not recover from deadlock, and only way to get rid of dead lock is to restart the server. It also mentions that JVM uses graph search where Thread acts as graph node and edge between two threads A and B is defined as Thread A is waiting for lock on resource already held by thread B. This graph is directed and if there is any cycle in this graph, then there is deadlock
Now my question is that if JVM knows that there is deadlock, then why does not it kill one thread and let other proceed? is there any specific reason behind this or my question itself is based on wrong conclusion?
Please let me know your views about this. Thanks in advance!!!
Now my question is that if JVM knows that there is deadlock, then why does not it kill one thread and let other proceed? is there any specific reason behind this or my question itself is based on wrong conclusion?
How could the JVM make the decision about which thread to kill? What if the JVM, in releasing the lock by force, allowed invalid data to enter some sort of critical database?
The JVM cannot make these sort of decisions arbitrarily. It reports on the deadlock but cannot automagically recover from it.
You could see this problem in any situation where two critical objects are being modified with locks but two threads are locking them in a different order. Database transactions are able to recover from such deadlocks because they are designed to roll back tables and indices but Java synchronized locks don't have implicit memory rollback capabilities. By killing one thread and releasing its locks, the JVM would be allowing partial memory updates to be propagated.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With