1. Java Memory Recycling Mechanism
Regardless of the memory allocation method of any language, it is necessary to return the real address of the allocated memory, that is, return a pointer to the first address of the memory block. Objects in Java are created by new or reflection methods. The creation of these objects is allocated in the heap (Heap), and the recycling of all objects is completed by the Java virtual machine through the garbage collection mechanism. In order to release objects correctly, GC will monitor the running status of each object, and monitor their application, reference, referenced, assignment, etc., Java will use the method of directed graph to manage memory, and monitor in real time whether the object can reach , if it is not reachable, it will be recycled, which also eliminates the problem of reference cycles. In the Java language, there are two ways to judge whether a memory space meets the garbage collection standard: one is to assign a null value to the object, and the following is not called again, and the other is to assign a new value to the object, thus re-allocating the memory space .
Second, the causes of Java memory leaks
First , what is a memory leak? I often hear people talk about memory leaks, but when it comes to asking what memory leaks are, few can explain clearly. Memory leak means that useless objects (objects that are no longer used) continue to occupy memory or the memory of useless objects cannot be released in time, resulting in a waste of memory space called memory leaks. Memory leaks are sometimes not serious and imperceptible, so developers don't know there is a memory leak, but sometimes they can be serious and prompt you Out of memory.
So, what is the root cause of Java memory leaks? A long-lived object holds a reference to a short-lived object, and memory leaks are likely to occur. Although the short-lived object is no longer needed, it cannot be recycled because the long-lived object holds its reference. This is java Scenarios where memory leaks occur. Specifically, there are the following major categories:
1. Memory leaks caused by static collection classes:
the use of HashMap, Vector, etc. is the most likely to cause memory leaks. The life cycle of these static variables is consistent with that of the application, and all the objects they refer to are also Can't be freed because they will also always be referenced by Vector etc.
Example:
Static Vector v = new Vector(10);
for (int i = 1; i<100; i++)
{
Object o = new Object();
v.add(o);
o = null;
}//
In this example, apply for an Object object cyclically, and put the applied object into a Vector. If only the reference itself is released (o=null), the Vector still refers to the object, so this object is not recyclable for GC. of. Therefore, if an object must be removed from the Vector after it is added to the Vector, the easiest way is to set the Vector object to null.
2. When the object properties in the collection are modified, calling the remove() method does not work.
Example:
public static void main(String[] args)
{
Set<Person> set = new HashSet<Person>();
Person p1 = new Person("Tang Seng","pwd1",25);
Person p2 = new Person( "Sun Wukong","pwd2",26);
Person p3 = new Person("Pig Bajie","pwd3",27);
set.add(p1);
set.add(p2);
set.add(p3);
System .out.println("Total: "+set.size()+" elements!"); //Result: Total: 3 elements!
p3.setAge(2); //Modify the age of p3, this When the hashcode value corresponding to the p3 element changes
set.remove(p3); //At this time, remove cannot be removed, causing memory leak
set.add(p3); //Re-add, actually added successfully
System.out.println("Total: "+set.size()+" elements!"); //Result: Total: 4 elements !
for (Person person : set)
{
System.out.println(person);
}
}
Note: This refers to overriding the hashCode() method of the Person class so that its value is related to the age attribute.
3. Listeners
In java programming, we all need to deal with listeners. Usually, a lot of listeners are used in an application. We will call methods such as addXXXListener() of a control to add listeners, but often release the object. It doesn't remember to delete these listeners at the time, thus increasing the chance of memory leaks.
4. Various connections,
such as database connections (dataSourse.getConnection()), network connections (socket) and io connections, will not be automatically recycled by GC unless they explicitly call their close() method to close the connection. of. The Resultset and Statement objects may not be explicitly recycled, but the Connection must be explicitly recycled, because the Connection cannot be automatically recycled at any time, and once the Connection is recycled, the Resultset and Statement objects will be NULL immediately. But if you use a connection pool, the situation is different. In addition to explicitly closing the connection, you must also explicitly close the Resultset Statement object (close one of them, and the other one will also be closed), otherwise it will cause a large number of Statement objects to fail. freed, causing a memory leak. In this case, the connection is usually made in try, and the connection is released in finally.
5. References of inner classes and external modules, etc. References of
inner classes are one of the easier to forget, and once they are not released, a series of subsequent class objects may not be released. In addition, programmers should be careful about inadvertent references to external modules. For example, programmer A is responsible for module A and calls a method in module B, such as: public
void registerMsg(Object b);
object, it is very likely that module B keeps a reference to the object. At this time, it is necessary to pay attention to whether module B provides the corresponding operation to remove the reference.
6. Singleton
mode Improper use of the singleton mode is a common problem that causes memory leaks. After the singleton object is initialized, it will exist for the entire life cycle of the JVM (in the form of static variables). If the singleton object holds A reference to an external object, then the external object will not be recycled normally by the JVM, resulting in memory leaks. Consider the following example:
class A{
public A(){
B.getInstance().setA(this);
}
....
}
//Class B adopts singleton mode
class B{
private A a;
private static B instance=new B();
public B(){}
public static B getInstance(){
return instance;
}
public void setA(A a){
this.a=a;
}
//getter...
}
Obviously B adopts the singleton mode, it holds a reference to an A object, and this A class object will not be recycled. Imagine what would happen if A was a more complex object or collection type