Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

JVM Synchronized Finally Blocks

Looking at the Java Virtual Machine Specification and compiled code tells us how "synchronized" blocks are implemented in java. The following code:

public void testSync()
{
    Object obj = getSomeObject();
    synchronized (obj) { doSomething(); }
}

...is roughly equivalent to this pseudocode:

public void testSync()
{
    Object obj = getSomeObject();
    Object __temp = obj;
    monitorenter __temp;
    try { doSomething(); }
    finally { monitorexit __temp; }
}

...with one exception.

For some reason, the exception table displays two finally handlers. For example:

  Exception table:
     from    to  target type
        12    20    23   any
        23    25    23   any

The first handler is where I expect it to be, but the second handler is actually for the finally block of the first handler, and if it catches an exception it executes the same handler. You could visualize this poorly in the following way:

try { doSomething(); }
finally { beginTry: try { monitorexit __temp; } finally { goto beginTry; } }

Does anybody know why this is? If it were just the finally block, the second entry in the table would not be there. Besides, I can't see any possible reason for wanting to execute the finally block again if it's already thrown an exception.

Thanks, Brandon

like image 864
leviathanbadger Avatar asked Feb 27 '13 20:02

leviathanbadger


People also ask

Does finally {} block always run?

A finally block always executes, regardless of whether an exception is thrown. The following code example uses a try / catch block to catch an ArgumentOutOfRangeException.

What is a synchronized block in Java?

A Synchronized block is a piece of code that can be used to perform synchronization on any specific resource of the method. A Synchronized block is used to lock an object for any shared resource and the scope of a synchronized block is smaller than the synchronized method.

How does JVM perform thread synchronization?

To coordinate shared data access among multiple threads, the Java virtual machine associates a lock with each object and class. A lock is like a privilege that only one thread can "possess" at any one time. If a thread wants to lock a particular object or class, it asks the JVM.

Which is more preferred synchronized method or synchronized block?

Synchronized block is more preferred way because it doesn't lock the Object, synchronized methods lock the Object and if there are multiple synchronization blocks in the class, even though they are not related, it will stop them from execution and put them in wait state to get the lock on Object.


1 Answers

If it's a choice between trying over and over to release the monitor unsuccessfully, and proceeding without releasing it, both alternatives will cause a deadlock; just if you proceed without releasing then the deadlock doesn't happen until the next time something tries to acquire the monitor, and that problem may be far away from the initial failure. Also trying to release the monitor may work out eventually, while letting the monitor go unreleased is a certain disaster. So you're better off retrying.

like image 107
Nathan Hughes Avatar answered Sep 29 '22 11:09

Nathan Hughes