The sand pot that hasn't been broken--dig into the order of the finally code block and return statement execution!

Ask about the execution order of the finally code block, even if the novice just learning programming can not hesitate to say the answer: whether it is abnormal or not, the code of the finally statement block will be executed! Although bloggers have not yet fully understand the mystery, but hope that the following code can arouse the reader's thinking, some people think it is not very important to understand, but I believe that every upward person to face knowledge must have a near pilgrimage heart, because we are standing on the shoulders of giants or predecessors forward, because we are very small! It really does make sense to understand, because it involves the logic in your later block of finally code. If you don't say much, look at the code:

 Public classfinallytest{ Public Static voidMain (string[] args) {System.out.println ("MAIN:X =" +test ()); }    Private Static intTest () {intx = 1; Try{System.out.println ("TRY:X =" +x); returnx; }Catch(Exception e) {Throw NewRuntimeException (e); }finally{            ++x; System.out.println ("FINALLY:X =" +x); }    }}

The results of the operation are as follows:

Parsing from the run result, the code in the TRY statement executes this is no doubt, at this time x=1, and then according to what we have known, before the return statement to execute the code in the finally statement block, the X self-increment 1 value to 2 and output, from the result is not error, but, Notice that the value of the X that return to the main function in the TRY statement block should be 2 ah, how can it be 1? The code in the finally statement was executed, and now the blogger suspects that the JVM is executing a return statement with a thread that executes the finally code block and returns the result itself. The following verification was carried out under this conjecture:

What happens when you block 500 milliseconds before executing a return statement, wait until the finally statement block finishes executing, and then return the return statement to the value of x???

ImportJava.util.*;Importjava.text.*; Public classfinallytest{Static intx = 1;  Public Static voidMain (string[] args) {System.out.println ("Main:x =" +test () + ":" +printtime ()); }    Private Static intTest () {Try{System.out.println ("Try:x =" +x + ":" +printtime ()); Thread.Sleep (500); returnx; }Catch(Exception e) {Throw NewRuntimeException (e); }finally{            ++x; System.out.println ("Finally:x =" +x + ":" +printtime ()); }    }    //Print Current time format: minutes: seconds: milliseconds     Public StaticString Printtime () {Date Date=NewDate (System.currenttimemillis ()); SimpleDateFormat SDF=NewSimpleDateFormat ("Mm:ss:SS"); returnSdf.format (date); }}

The results of the implementation are as follows:

Do you think it would be strange for readers to read this step? Will it be interesting? Obviously the value of X has become 2, but the main function is still 1, which is why? So the blogger searched around for some of the relevant parties, so the following conjecture: It is well known that the return statement has two functions, one is to return the result, and the other is to terminate execution, then it will be executed to the return statement, the value of x is returned to the caller, Then execute the code in the finally statement block, and then terminate the function?

The sand pot that hasn't been broken--dig into the order of the finally code block and return statement execution!