Six big questions about Java do you understand it?

First, how to initialize!

This question discusses variable initialization , so let's take a look at what kinds of variables are in Java .

1. A property of a class, or a range

2. The local variable in the method

3. The parameters of the method for the first variable, the Java virtual opportunity is automatically initialized. If the initial value is given, it is initialized to the initial value. If it is not given, it is initialized to the default initial value of the type variable.

All object reference type variables default initial value is null, that is, does not point to any object. Note that the array itself is also an object, so an array reference without initialization is also null after automatic initialization. For two different class properties, the static property and the instance property are initialized differently. The instance property is initialized when the instance is created, and the static property is initialized when the class is loaded, which is the first time the class is used, and is not initialized again for the creation of subsequent instances. This issue will be discussed in detail in a later series. For the second variable, you must explicitly initialize it. If you try to use it before you initialize it, the compiler will protest. If the initialized statement is in a try block or in an if block, it must be able to get an assignment before it is used for the first time. In other words, the compiler will protest the initialization statement in a conditional judgment statement that has only if blocks, because the execution may not conform to the condition of the IF, so that the initialization statement is not executed, which violates the requirement that the local variable must be initialized before it is used. But if there is also an initialization statement in the else block, it can be compiled, because at any rate at least one of the initialization statements will be executed and not be initialized before it is used. The same is true for Try-catch, if the initialization statement is only in a try block, the compilation department passes. If you have it in catch or finally, you can compile it. In short, make sure that local variables are initialized before they are used. Therefore, a good practice is to declare their time to initialize them, if you do not know what the accident to the value of good, the above default value it! In fact, the third variable is essentially the same as the second, which is the local variable in the method. As a parameter, it is definitely initialized, and the incoming value is the initial value, so no initialization is required.

Two, what is instanceof?

Instanceof is a Java two-dollar operator, and ==,>,< is the same kind of stuff. Because it is made up of letters, it is also a reserved keyword in java. Its role is to test whether the object on its left is an instance of its right class, and returns a Boolean type of data. However, this approach is often considered to be a failure to take advantage of the object-oriented polymorphism. In fact, the above features require method overload can be fully implemented, this is an object-oriented approach should be to avoid the return to structured programming mode. As long as two names and return values are the same, methods that accept different parameter types are OK: Therefore, using instanceof is not recommended in most cases and should take advantage of polymorphism.

　　Three, "= =" and the Equals method what is the difference?

= = operator is designed to compare the values of variables to equality. The better understanding is that, according to the previous post, object variables are actually references, and their values point to the memory address where the object resides, not the object itself. Both A and B use the new operator, which means that there will be two strings in memory that are "Foo", and since they are "two", they naturally reside in different memory addresses. The value of a and B is actually a value of two different memory addresses, so using the "= =" operator, the result would be false. Admittedly, the objects of A and B are "foo" and should be "equal", but the = = operator does not involve comparison of object content. The comparison of object content is exactly what the Equals method does. Take a look at how the Equals method of Object objects is implemented:

Boolean equals (Object o) {

return this==o;}

The Object object uses the = = Operator by default. So if your own class doesn't overwrite the Equals method, then your class uses equals and uses = = to get the same result. It can also be seen that the Equals method of object does not achieve the goal that the Equals method should achieve: Compare two object contents for equality. Because the answer should be determined by the creator of the class, object leaves the task to the creator of the class. So when you're using the Equals method to determine whether the object's content is equal, don't take it for granted. Because you may think of equality, and the author of this class does not think so, and the implementation of the Equals method of the class is his master. If you need to use the Equals method, or use any collection based on the hash code (hashset,hashmap,hashtable), look at the Java doc to see how the Equals logic for this class is implemented. [NextPage]

What does the

four, final keyword modify? The

Final makes the modified variable "invariant", but because the essence of an object type variable is "reference", the term "invariant" has two meanings: the invariant of the reference itself, and the object that the reference points to does not change. The

reference itself is invariant:

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

Final StringBuffer B=ne W StringBuffer ("notImmutable "),

a=b;//compile-time error

Reference to the same object:

Final stringbuffer a=new StringBuffer (" Immutable ");

A.append (" broken! )//Compiles through the

The

is visible, and final is valid only for the reference "value", forcing the reference to point only to the object that was initially pointed to, and changing its point will result in a compile-time error. Final is not responsible for the change in the object it points to. This is very similar to the = = Operator: = = operator is only responsible for reference "value" equal, as to the object of this address is equal to the content, = = operator is regardless. Understanding the final question has a very important meaning. Many program vulnerabilities are based on this----final can only guarantee that the reference always points to the fixed object, and cannot guarantee that the object's state is unchanged. In a multithreaded operation, an object is shared or modified by multiple threads, and a thread's unconscious modification of the object may cause another thread that uses this object to crash. The wrong solution is to declare it as final when the object is new, with the intention of making it "never change." It was in vain.

Five, I declare what!

A lot of people have done this, but what are we declaring? The answer is usually: a string that reads "Hello world! ”。 Such vague answers are often the source of unclear concepts. If you want to answer correctly, half of the people will probably answer the wrong question. This statement declares a reference to an object named "s" that can point to any object of type string, currently pointing to "Hello world! "This string type of object. That's what's really going on. We didn't declare a string object, we just declared a reference variable that could only point to a string object. So, if you run another sentence after that sentence: string string = s; we're declaring another reference that can only point to a String object, named String, and no second object is generated, string or the original object, that is, and S point to the same object.

Six, has the string changed?

is not. Because a string is designed as an immutable (immutable) class, all of its objects are immutable objects. See the following code:

String s = "Hello";

s = s + "world! Does the

S point to an object that has changed? It is easy to derive this conclusion from the conclusion of the first article in this series. Let's see what's going on. In this code, s originally points to a string object, the content is "Hello", and then we have a + operation on S, so does s point to the object that has changed? The answer is no. In this case, S does not point to the original object, and points to another string object, "Hello world! "The original object still exists in memory, but S is no longer pointing to it." With the instructions above, it is easy to derive another conclusion that if you frequently make various modifications to strings, or unpredictable modifications, then using string to represent strings can cause a lot of memory overhead. Because a string object cannot be changed after it is established, a string object is required for each of the different strings. At this point, you should consider using the StrinGbuffer class, which allows you to modify, instead of generating a new object for each different string. And, these two kinds of object conversion is very easy. At the same time, we can also know that if you want to use the same string as the content, you don't have to make a new string each time. For example, to initialize a string reference variable named S in the constructor, set it to its initial value, you should do this:

Public Class Demo {

private String s;

public Demo {

s = "Initial Value";}

}

p>
Instead of

s = new String ("Initial Value");

The latter calls the constructor every time, generating new objects, low performance and memory overhead, and meaningless, because the String object is immutable, So for a string with the same content, just a string object to represent it. It is also said that multiple objects are created by calling the above constructor multiple times, and their string type attribute s is pointing to the same object. The above conclusion is also based on the fact that for string constants, if the content is the same, Java thinks they represent the same string object. With the keyword new call constructor, a new object is always created, regardless of whether the content is the same. As for why the string class is designed to be immutable, it is determined by its purpose. In fact, more than string, many classes in the Java Standard Class library are immutable. In developing a system, we sometimes also need to design immutable classes to pass a set of related values, which is also the embodiment of object-oriented thinking. Immutable classes have some advantages, such as because their objects are read-only, so multithreading concurrent access does not have any problems. Of course, there are some drawbacks, such as each of the different states need an object to represent, may cause performance problems. So the Java Standard Class Library also provides a mutable version, that is, StringBuffer.

Finally, there are some Java technologies, including EJB3.0, that you can choose to learn, and EJB is a well-deserved heavyweight compared to the three lightweight frameworks.