The difference between a=a+b and a+=b in Java

A long time ago to learn some of the differences between A=a+b and A+=b, come in again in retrospect, found that the understanding is not thorough, so the search for documents to find a re-study.

Comparing the differences between the two operators can be compared in the following two aspects: execution efficiency and type conversion.

first of all, Execution Efficiency problem

Simply execute these two statements, regardless of compiler optimization, a=a+b execution efficiency is less than a+=b, because it takes more than one step intermediate variable operation, and will occupy a variable space. The Java compiler has optimized it by default, and the two statements are executed as a+=b, so there is actually nothing else.

Next Talk about Type Conversions the difference.

I believe everyone has come across this situation:

public class Test {public static void main (string[] args) {int a = 2;float B = 6;a+=b;//right//a=a+b;//errora= (int) (A+B) ; Right}}

when using a=a+b, it throws "Exception in thread" main "java.lang.Error:Unresolved compilation problem: Type mismatch: Cannot convert from the float to int "exception, which is understandable, if you do not use (int) coercion type conversion, float is not directly complex value to the INT variable.

We will comment out the a=a+b, Javac compile, and then use the anti-compilation software (such as Xjad) to open the Test.class file, you will find that the source code is parsed into this way:

public class Test{public Test () {}public static void Main (String args[]) {int a = 2;float b = 6f;a = (int) ((float) A + b); a = (int) ((float) A + b);}}

that is, a+=b is forced type cast, and a= (int) ((float) a+b) is equivalent!

Here we understand why A=a+b throws an exception.

Cause: In Java, the conversion of a small byte type to a large byte type occurs when an arithmetic operation is performed on the base type. When the int type and the float type are added, A is converted to the float type, and then the sum of the B. This turns the result type into a float type and throws an exception if you attempt to assign a float type to a.

In addition, for variable types that have a smaller short,byte than int, the result of the operation is automatically converted to an int type, such as

byte a = 1, b=2;b=a+b;

byte a = 1;short b =2;b=a+b;

Will throw "Exception in thread" main "java.lang.Error:Unresolved compilation problem: Type Mismatch:cannot Convert fr Om int to byte "similar to the exception, you can see that the a+b result becomes the int type.

If it is a final modified variable, no type conversion exception occurs when the operation is performed.

public class Test {final int d = 3;public static void Main (string[] args) {final short  a = 1;final short  b =2;short C=a+b;}}

After compiling with the anti-compilation software, the code is parsed into this way:

public class test{final int d = 3;public Test () {}public static void Main (String args[]) {Short A = 1;short b = 2;short C = 3;}}

As you can see, for the basic types of the final modified variables, the operation between them is directly hardcoded into a direct assignment statement, even the intermediate result is not, the type conversion of the exception is gone.

In addition, we can note that for the final variable A in the method, B, the encoding is omitted directly. The final member variable d of the test class still retains the final attribute.

So it's no different for the JVM to use the normal variables in the final retouching Method! The normal variables used in the final decoration method are primarily intended for Java front-end compilers (such as JAVAC)! This means that the normal variable that is final modified in the method is Javac checked at the front-end and guarantees that the variable will not be changed within the scope of the new value, but the final of the normal variable in the modified method after being compiled into a byte code does not exist! What's more specific is that the bytecode file (. class file) that you generate with or without the normal variables in the final decoration method is no different.

PS: For a final decorated class member, it should occupy heap memory because its life cycle is before the object is destroyed. (This is not certain--)

The difference between a=a+b and a+=b in Java