Several important knowledge details in java!

Question 1:What did I declare!

String s = "Hello world! ";

Many people have done such a thing, but what have we declared? The answer is usually a String with the content "Hello world !". Fuzzy answers are usually the root cause of unclear concepts. If you want to answer the question accurately, half of them will probably make a wrong answer.

This statement declares a reference pointing to an object named "s". It can point to any object of the String type and currently points to "Hello world! "This String type object. This is what actually happens. We didn't declare a String object. We just declared a reference variable that can only point to the String object. Therefore, if you run the following statement:

String string = s;

We declared another reference that can only point to the String object, named string, and no second object is generated. The string still points to the original object, that is, the same object as s.

Question 2:"=" What is the difference between equals and equals?

= The operator is used to compare whether the values of variables are equal. A better understanding is:

Int a = 10;

Int B = 10;

Then a = B will be true.

But what is hard to understand is:

String a = new String ("foo ");

String B = new String ("foo ");

If a = B, false is returned.

According to the previous post, object variables are actually a reference. Their values point to the memory address of the object, not the object itself. Both a and B use the new operator, which means that two strings with content "foo" will be generated in the memory. Since they are "two" strings, they are naturally located at different memory addresses. The values of a and B are actually two different memory address values. Therefore, the result is false when the "=" operator is used. It is true that the content of objects a and B is "foo" and should be "equal", but the = operator does not involve the comparison of object content.

The comparison of object content is exactly what the equals method does.

Let's take a look at how the equals method of the Object is implemented:

Boolean equals (Object o ){

Return this = o;

}

The = Operator is used by default for Object objects. Therefore, if your own class does not overwrite the equals method, you will get the same result when using equals and =. We can also see that the equals method of the Object does not meet the goal that the equals method should achieve: compare whether the content of the two objects is equal. Because the answer should be determined by the class creator, the Object leaves this task to the class creator.

Take a look at the next extreme class:

Class Monster {

Private String content;

...

Boolean equals (Object another) {return true ;}

}

I overwrite the equals method. This implementation will always return true regardless of the content of the Monster instance.

Therefore, when you use the equals method to determine whether the object content is equal, do not take it for granted. Because you may think they are equal, and the authors of this class do not think so, and the implementation of the equals method of the class is controlled by him. If you need to use the equals method or any hash code-based set (HashSet, HashMap, HashTable ), check the java doc to see how the equals logic of this class is implemented.

Question 3:Has the String changed?

No. Because String is designed as an immutable class, all its objects are immutable objects. See the following code:

String s = "Hello ";

S = s + "world! ";

Is the object pointed to by s changed? It is easy to draw this conclusion from the first article in this series. Let's see what happened. In this Code, s originally points to a String object with the content "Hello". Then we perform the + operation on s. Does the object s points to change? The answer is no. At this time, s points to another String object instead of the original object, and the content is "Hello world! ", The original object still exists in the memory, but the reference variable s no longer points to it.

Through the above description, we can easily draw another conclusion, if you often make various modifications to the string, or make unforeseen modifications, therefore, using String to represent strings will cause a large memory overhead. Because the String object cannot be changed after it is created, a String object is required for each different String. In this case, you should consider using the StringBuffer class, which allows modification, instead of generating a new object for each different string. In addition, the conversion between the two types of objects is very easy.

At the same time, we can also know that if you want to use a String with the same content, you do not have to create a new String each time. For example, we need to initialize a String reference variable named s in the constructor and set it as the initial value. We should do this:

Public class Demo {

Private String s;

...

Public Demo {

S = "Initial Value ";

}

...

}

Rather

S = new String ("Initial Value ");

The latter calls the constructor every time to generate a new object, which has low performance and high memory overhead and has no significance. Because the String object cannot be changed, for strings with the same content, it can be expressed as long as a String object. That is to say, the constructor above is called multiple times to create multiple objects, and their String type attribute s points to the same object.

The above conclusion is based on the fact that for String constants, if the content is the same, Java considers them to represent the same String object. Using the new keyword to call the constructor always creates a new object, regardless of whether the content is the same or not.

The reason for designing a String class as an immutable class is determined by its purpose. In fact, classes in many Java standard library are not variable. When developing a system, we sometimes need to design immutable classes to pass a set of related values, which is also the embodiment of Object-oriented thinking. The immutable class has some advantages. For example, because its object is read-only, concurrent multi-thread access will not have any problems. Of course, there are also some shortcomings. For example, each State must be represented by an object, which may cause performance problems. Therefore, the Java standard library also provides a variable version, namely, StringBuffer.

Question 4:What are the final keywords modified?

Final makes the modified variable "unchanged", but because the object type variable is essentially a "Reference", it also has two meanings: The reference itself remains unchanged, and the referenced object.

The reference itself remains unchanged:

Final StringBuffer a = new StringBuffer ("immutable ");

Final StringBuffer B = new StringBuffer ("not immutable ");

A = B; // compilation Error

The referenced object remains unchanged:

Final StringBuffer a = new StringBuffer ("immutable ");

A. append ("broken! "); // Compiled

It can be seen that final is only valid for the referenced "value" (that is, the memory address of the object it points to), and it forces the reference to only point to the object initially pointed, changing the point will cause compilation errors. Final is not responsible for the changes to the objects it points. This is similar to the = Operator: = Operator is only responsible for the equal value of the referenced "value". As to whether the content of the object pointed to by this address is equal, the = operator does not matter.

Understanding final issues has important meanings. Many program vulnerabilities are based on this ---- final can only ensure that the reference always points to a fixed object, but cannot ensure that the state of that object remains unchanged. In multi-threaded operations, an object will be shared or modified by multiple threads. Unintentional modifications made by one thread to the object may cause another thread to crash. The solution to an error is to declare the object as final when it is created, so that it is "never changed ". In fact, it is futile.

Question 5:How to initialize it!

This topic discusses variable initialization, so let's first look at the types of variables in Java.

1. Class Attribute, or value range

2. Local variables in the Method

3. method parameters

For the first variable, the Java Virtual Machine will automatically initialize it. If an initial value is given, the initialization is the initial value. If not, initialize it as the default initial value of the type variable.

The default value of int type variables is 0.

The default initial value of a float variable is 0.0f.

The default value of the double type variable is 0.0.