Shulou(Shulou.com)06/02 Report--

This article mainly introduces "what are the six major problems that Java beginners must understand". In daily operation, I believe many people have doubts about what the six major problems that Java beginners must understand. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubts of "what are the six questions that Java beginners must understand?" Next, please follow the editor to study!

Question 1: what did I declare!

String s = "Hello world!"

A lot of people have done this, but what exactly did we declare? The answer is usually: a String with the content "Hello world!". Such a vague answer is usually the source of confusion. If you want an accurate answer, half of the people will probably give the wrong answer.

This statement declares a reference to an object named "s", which can point to any object of type String, currently pointing to "Hello world!" This object of type String. That's what really happened. We don't declare a String object, we just declare a reference variable that can only point to the String object. So, if you run another sentence after that sentence:

String string = s

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

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

The = = operator is used specifically to compare whether the values of variables are equal. What is easier to understand is:

Int axi10

Int baggage 10

Then it will be true.

But what's hard to understand is:

String a=new String ("foo")

String b=new String ("foo")

Then the false will be returned by aroomroomb.

As mentioned in the previous post, an object variable is actually a reference whose value points to the memory address where the object is located, not to the object itself. Both an and b use the new operator, which means that two strings with the content "foo" will be generated in memory, and since they are "two", they are naturally located at different memory addresses. The values of an and b are actually values of two different memory addresses, so using the "= =" operator, the result is false. Admittedly, the contents of the objects an and b refer to are "foo" and should be "equal", but the = = operator does not involve the comparison of object contents.

Comparing the contents of an object is exactly what the equals method does.

Take a look at how the equals method of the Object object is implemented:

Boolean equals (Object o) {

Return this==o

}

The Object object uses the = = operator by default. So if your self-created class does not override the equals method, then your class will get the same result using equals and using =. You can also see that Object's equals method does not achieve what the equals method should achieve: compare whether the contents of the two objects are equal. Because the answer should be decided by the creator of the class, Object leaves this task to the creator of the class.

Take a look at an extreme class:

Class Monster {

Private String content

...

Boolean equals (Object another) {return true;}

}

I override the equals method. This implementation causes comparisons between Monster instances to always return true regardless of their contents.

So when you use the equals method to determine whether the content of an object is equal, please don't take it for granted. Because you may think equal, but the author of this class does 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 collection (HashSet,HashMap,HashTable), take a look at java doc to confirm how the equals logic of this class is implemented.

Question 3: has String changed or not?

No. Because String is designed to be an immutable class, all of its objects are immutable. Look at the following code:

String s = "Hello"

S = s + "world!"

Has the object pointed to by s changed? This conclusion can be easily derived from the conclusion of 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", and then we do a + operation on s, so does the object that s points to change? The answer is no. At this point, s no longer points to the original object, but points to another String object with the content "Hello world!". The original object still exists in memory, but the reference variable s no longer points to it.

From the above, it is easy to draw another conclusion that using String to represent a string will incur a lot of memory overhead if you often make various changes to the string, that is to say, unforeseen changes. Because the String object cannot be changed after it is created, a String object is needed to represent each different string. At this point, you should consider using the StringBuffer class, which allows modification instead of generating a new object for each different string. Moreover, the conversion between these two kinds of objects is very easy.

At the same time, we also know that if you want to use a string with the same content, you don't have to new one String at a time. For example, to initialize a String reference variable called s in the constructor and set it to the initial value, you should do this:

Public class Demo {

Private String s

...

Public Demo {

S = "Initial Value"

}

...

}

Instead of

S = new String ("Initial Value")

The latter calls the constructor every time to generate a new object, which is slow in performance, high in memory overhead, and meaningless, because the String object is immutable, so for a string with the same content, it only needs a String object to represent it. That is, the above constructor is called multiple times to create multiple objects, and their String type properties s all point to the same object.

The above conclusion is also based on the fact that for string constants, Java believes that they represent the same String object if the contents are the same. Calling the constructor with the keyword new always creates a new object, regardless of whether the content is the same or not.

Why the String class is designed to be immutable is determined by its purpose. In fact, not only String, the classes in many Java standard class libraries are immutable. 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. Immutable classes have some advantages, for example, because its objects are read-only, there is no problem with multithreaded concurrent access. Of course, there are some disadvantages, such as each different state is represented by an object, which may cause performance problems. So the Java standard class library also provides a variable version, StringBuffer.

At this point, the study of "what are the six major issues that Java beginners must understand" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.