Pick up the--finally/final/finalize and see the sky

Java programming, often use to exception handling, and finally seems to be try/catch after the perfect logic processing, in fact there are many subtle traps; final is common in variable retouching, so you've seen it in the inner class. Finalize as the GC reclaims the object before the door, when to execute, the effect is how, sometimes look and forget. Here is a summary of some of my online friends and their posts to summarize the three. (Focus on the next finally)

First look at final

• The final modifier variable cannot be re-assigned, it modifies the instance variable, the specified value is defined as a "macro variable", the value is not initialized in a non-static code block and a constructor, and when it modifies a class variable, the specified value is considered a "macro variable" when defined, and is not initialized in a static code block.
• The final modified method cannot be overridden
• The final decorated class cannot be inherited
• Inner classes generally use the final decorated local variables.

looking at Finalize

• System call Finalize method has uncertainty
• The Finalize method is a protected method that the subclass can override to implement resource cleanup, which is called by the GC before the object is reclaimed. In general, when an object becomes unreachable, the GC will determine whether to overwrite the method, recycle it if it is not overwritten, and if the overlay puts the object into the f-queue queue and executes the Finalize method of the object by a low-priority thread, And then judge again whether it can be reached.
• Try not to call finalize and, if called, avoid object regeneration, which is used to close the stream.

finally fine

• The Finall statement executes after the return statement is executed, and the return is executed before returning;
• Return statement execution results in a finally block overwrite return statement execution results in try and catch
• Finally block operation Try/catch returns the base variable, the result is not affected by the finally operation
• The finally block operates Try/catch when the reference object is returned. Results are affected by the finally operation

Here are a few examples to verify the 4 important points of finally
The Example 1 code is as follows:

Package Java_zhaohuaxishi;public class Example1 {public int test () {int i = 0;try{i = 10; System.out.println ("Try"); return i+=10;} catch (Exception e) {i = 20;return 200;} Finally{system.out.println ("finally"); System.out.println (i);}} /** * @param args */public static void main (string[] args) {//TODO auto-generated method StubSystem.out.println (New Examp Le1 (). Test ());}}

Operation Result:

tryfinally2020

This also means that the finally print out is a try in return has been computed, to verify the point of view.
The Example 2 code is as follows:

Package Java_zhaohuaxishi;public class Example1 {public int test () {int i = 0;try{i = 10;return 100;} catch (Exception e) {i = 20;return 200;} Finally{return i;}} /** * @param args */public static void main (string[] args) {//TODO auto-generated method StubSystem.out.println (New Examp Le1 (). Test ());}}

the above did not appear abnormal, printed as follows:

10

Given the exception, the code is as follows:

Package Java_zhaohuaxishi;public class Example2 {public int test () {int i = 0;try{i = 10/0;return 100;} catch (Exception e) {i = 20;return 200;} Finally{return i;}} /** * @param args */public static void main (string[] args) {//TODO auto-generated method StubSystem.out.println (New Examp Le2 (). Test ());}}

The printing results are as follows:

20

The result is that the finally return always overwrites the result of return in Try/catch, whether or not it occurs, and verifies point two.
The Example 3 code is as follows:

Package Java_zhaohuaxishi;public class Example5 {public int test () {int i = 0;try{i = 10;return i;} catch (Exception e) {i = 20;return i;} Finally{i=30;//return i;}} /** * @param args */public static void main (string[] args) {//TODO auto-generated method StubSystem.out.println (New Examp Le5 (). Test ());}}

The printing results are as follows:

10

As you can see, actually finally modifying the I variable is not working, verifying the point of view three.
The Example 4 code is as follows:

Package Java_zhaohuaxishi;class test{int num;public Test (int num) {this.num = num;} public int Getnum () {return num;} public void setnum (int num) {this.num = num;}} public class Example3 {public Test test () {Test T  = new Test (0); Try{t.setnum (ten); return t;} catch (Exception e) {t.setnum (); return t;} Finally{t.setnum (30);}} /** * @param args */public static void main (string[] args) {//TODO auto-generated method StubSystem.out.println (New Examp Le3 (). Test (). Getnum ());}}

The printing results are as follows:

30

from the above results, the finally operation of the object is indeed the same object on the try, then we compare the above view three, the time to manipulate the variable can not be changed, think a bit strange, we look at the following code:

Package Java_zhaohuaxishi;class test{int num;public Test (int num) {this.num = num;} public int Getnum () {return num;} public void setnum (int num) {this.num = num;}} public class Example3 {public int test () {Test T  = new test (0); Try{t.setnum (10); System.out.println (T.getnum ()); return T.getnum ();} catch (Exception e) {t.setnum (); return T.getnum ();} Finally{system.out.println (T.getnum ()); T.setnum (30);}} /** * @param args */public static void main (string[] args) {//TODO auto-generated method StubSystem.out.println (New Examp Le3 (). Test ());}}

this time we are not returning an object, but returning an int variable. From the point of view we can tell that the returned T.getnum () is actually calculated and then saved. So if we are going to change T's num in Finally, the num of T is actually changed, but the return should still be 10! The printing results are as follows:

103010

Sure enough! This is exactly the same as what we had in advance. If someone thinks that the T object in the finally may be inconsistent with try, the following example will make you feel amazing:

Package Java_zhaohuaxishi;class test4{int num;public Test4 (int num) {this.num = num;} public int Getnum () {return num;} public void setnum (int num) {this.num = num;}} public class Example4 {public Test4 test (Test4 t) {System.out.println ("T:" +t.hashcode ()); Try{t.setnum (); return T ;} catch (Exception e) {t.setnum (); return t;} Finally{//t.setnum (30); SYSTEM.OUT.PRINTLN ("Finally modified before:" +t.hashcode ()); t = new Test4 (0); SYSTEM.OUT.PRINTLN ("Finally Modified:" +t.hashcode ());//return t;}} /** * @param args */public static void main (string[] args) {//TODO auto-generated method stubTest4 t  = new Test4 (0); S YSTEM.OUT.PRINTLN ("Return returned object" +new Example4 (). Test (T). Hashcode ()); System.out.println ("Last T:" +t.hashcode ());}}

Let's take a look at the print results:

Passed in t:2004703190finally before: 2004703190finally modified: 1175576547return Returns the last t:2004703190 of the object 2004703190

the result looks magical. We verify that the object is working when we are four! However, when we try to modify the T-reference so that he points to other objects, it is invalid ...
If you have more interest, you can learn more about JVM working mechanism!

Copyright NOTICE: This article is the original blogger articles, reproduced please indicate the source.

Pick up the--finally/final/finalize and see the sky