Is there a problem with memory leaks in the Java language __java

In the Java language, there are two criteria for determining whether a single memory space meets the garbage back:

First: Give the object a null value NULL, no longer be used;

Second: The object is given a new value and the memory space is reassigned.

Generally speaking, there are two main types of memory leaks:

One was in the heap to apply for the space not to be released;

The second is that the object is no longer in use, but it is still retained in memory.

The introduction of the garbage collection mechanism can effectively solve the first situation, whereas in the second case, the garbage collection mechanism cannot guarantee that objects that are no longer being used will be released. As a result, memory leaks in the Java language mainly refer to the second case.

In the Java language, there are many reasons for memory leaks, mainly in the following areas:

(1) Static collection classes, such as hashmap and vectors. If these containers are static, and because their declaration cycle is consistent with the program, the objects in the container will not be released until the program ends, causing a memory leak.

(2) Various connections, such as database connection, network connection and IO connection.

(3) listener. In the Java language, listeners are often used. Often, multiple listeners are used in one application, but there is often no corresponding removal listener while releasing the object, which can also lead to memory leaks.

(4) The scope of the variable is unreasonable. In general, if a variable defines a scope greater than its use, it is likely to cause a memory leak, on the other hand, if the object is not set to NULL in a timely manner, it is likely to cause a memory leak released, as follows:

Class server{

Private String msg;

public void Receivemsg () {

Readfromnet ()///Receive data from network stored in MSG

Savedb ()//Save MSG in the database

｝

From the above code, messages received through the Readfromnet () method are stored in variable msg, and then the Savedb () method is invoked to save the contents of MSG to the database, where MSG is useless, but because the declaration cycle of MSG is the same as the declaration cycle of the object, MSG cannot be reclaimed at this time, thus causing a memory leak. For this problem, there are two solutions: the first method, because MSG is scoped to the Receivemsg () method, so that MSG can be defined as a local variable of this method, and when the method ends, the MSG declaration cycle ends. The garbage collector can then recycle the contents of MSG, and the second method is set to null after using MSG, so the garbage collector automatically reclaims the memory space occupied by MSG content.

(5) Single-case mode can cause memory leaks