A summary of the causes of memory leaks in Java and how to avoid memory leaks (Hyper-Detail edition) _java

Android Memory Leak Summary

The purpose of memory management is to let us in the development of how to effectively avoid the problem of memory leaks in our application. Memory leaks Everyone is not unfamiliar, it is simply vulgar to say that the released object is not released, has been held by some or some instances are no longer used to cause the GC can not be recycled. Recently, I read a lot of relevant documents, I intend to do a summary of precipitation down with everyone to share and learn, but also to give themselves a warning, how to avoid these situations after coding, improve the application of experience and quality.

I'll start with the basics of Java memory leaks, and give a concrete example of how Android causes memory leaks, and how to use tools to analyze application memory leaks, and finally to summarize them.

Java Memory allocation Policy

Java Program runtime memory allocation strategy has three kinds, is static allocation, stack type allocation, and heap type allocation, corresponding, three kinds of storage strategy uses the memory space mainly is static storage area (also called method area), stack area and heap area respectively.

Static storage (method area): Mainly holds static data, global static data, and constants. The inside of this block is already allocated when the program is compiled and exists throughout the running of the program.

Stack area: When a method is executed, local variables in the method body (including the underlying data type, the reference to the object) are created on the stack, and the memory held by those local variables is automatically freed at the end of the method execution. Because the stack memory allocation operation is placed within the processor's instruction set, it is highly efficient, but allocates a limited amount of memory.

Heap area: Also called dynamic memory allocation, usually refers to the memory that comes out directly when the program is running, which is an instance of the object. This section will be reclaimed by the Java garbage collector when it is not in use.

Stack versus heap difference:

Some basic types of variables and reference variables for objects defined in the method body are allocated in the stack memory of the method. When a variable is defined in a block of methods, Java allocates the memory space for the variable in the stack, and when the variable is scoped, the variable becomes invalid, and the memory space allocated to it is released, and the memory space can be reused.

Heap memory is used to hold all objects created by new (including all the member variables in the object) and arrays. The memory allocated in the heap is automatically managed by the Java garbage collector. After generating an array or object in the heap, you can also define a special variable in the stack that equals the array or the first address of the object in the heap memory, and this particular variable is the reference variable we mentioned above. We can use this reference variable to access the object or array in the heap.

As an example:

public class Sample {
int s1 = 0;
Sample MSample1 = new sample ();
public void Method () {
int s2 = 1;
Sample MSample2 = new sample ();
}
}
Sample MSample3 = new sample ();

The local variable s2 and reference variable mSample2 of the Sample class exist in the stack, but MSample2 objects are on the heap.
The object entity that MSample3 points to is stored on the heap, including all the member variables S1 and mSample1 of the object, and it itself exists in the stack.

Conclusion:

The base data types and references for local variables are stored on the stack, and the referenced object entities are stored in the heap. Because they belong to a variable in the method, the lifecycle ends with the method.

Member variables are all stored in the heap (including the base data types, references, and referenced object entities)--because they belong to the class, and the class object is ultimately used by new.

After learning about the memory allocation in Java, let's look at how Java manages memory.

How Java manages memory

Java's memory management is the issue of object allocation and deallocation. In Java, programmers need to request memory space for each object with the keyword new (except for the base type), and all objects allocate space in the heap (Heap). In addition, the release of objects is determined and executed by GC. In Java, the allocation of memory is done by the program, and the release of memory is done by GC, and the two-line approach does simplify the programmer's work. But at the same time, it also aggravates the work of the JVM. This is one of the reasons why Java programs run slower. Because, in order to properly release the object, the GC must monitor the running state of each object, including the object's application, reference, reference, assignment, and so on, which the GC needs to monitor.

Monitoring object state is to release objects more accurately and in a timely manner, and the fundamental principle of releasing objects is that the object is no longer referenced.

To better understand the working principle of GC, we can consider the object as the vertex of a directed graph, consider the reference relation as a directed edge of the graph, and point to the referenced object from the reference. In addition, each thread object can be the starting vertex of a graph, for example, most programs start with the main process, and the graph is a root tree that starts with the vertex of the main process. In this graph, the objects to which the root vertex can reach are valid objects, and the GC will not recycle them. If an object (connected subgraph) is unreachable with this root vertex (note that the graph is a forward graph), then we think that the object is no longer referenced and can be recycled by GC.
Below, we give an example of how to represent memory management with a graph. For every moment of the program, we have a graph that represents the memory allocation of the JVM. The following is the illustration of the left program running to line 6th.

Java uses a graph-like approach to memory management that eliminates the problem of reference loops, such as having three objects that reference each other, so that GC can recycle them as long as they are not up to the root process. The advantage of this approach is that it is highly accurate to manage memory, but less efficient. Another commonly used memory management technology is to use counters, such as the COM model using counter method to manage the component, which is less accurate than the graph, the precision is difficult to deal with the problem of circular reference, but execution is very efficient.

What is a memory leak in Java

In Java, a memory leak is the existence of some allocated objects that have the following two characteristics, first of all, these objects are accessible, that is, in the direction graph, the existence of the path can be connected to, and secondly, these objects are useless, that the program will not use these objects later. If the objects meet these two conditions, they can be judged as memory leaks in Java, which are not reclaimed by GC, but they occupy memory.

In C + +, memory leaks are larger in scope. Some objects are allocated memory space, but then unreachable, because there is no GC in C + +, these memory will never be back. In Java, these unreachable objects are collected by the GC, so programmers do not need to consider this part of the memory leak.

Through the analysis, we learned that for C + +, programmers need to manage their own edges and vertices, and for Java programmers only need to manage edges (no need to manage the release of vertices). In this way, Java improves the efficiency of programming.

Therefore, through the above analysis, we know that there are also memory leaks in Java, but the scope is smaller than C + +. Because Java is linguistically guaranteed, any object is accessible and all unreachable objects are managed by GC.

For programmers, the GC is basically transparent and invisible. Although we have only a few functions to access the GC, such as the function System.GC () that runs the GC, this function does not guarantee that the JVM's garbage collector will execute, as defined by the Java language Specification. Because different JVM implementations may use different algorithms to manage GC. Typically, the GC thread has a lower priority level. There are also a number of strategies for the JVM to invoke GC, some of which have reached a certain level of memory usage, and the GC begins to work, is timed to execute, has a smooth execution GC, or breaks the execution GC. But generally, we don't need to care about that. Unless GC execution affects application performance on certain occasions, such as for web-based real-time systems such as online games, where users do not want the GC to suddenly interrupt application execution for garbage collection, we need to adjust the GC's parameters so that the GC can release the memory in a gentle way, For example, by decomposing garbage collection into a series of small steps, the hotspot JVM provided by Sun supports this feature.

Also give a typical example of a Java memory leak,

Vector v = new vector (a);
for (int i = 1; i < i++) {
object o = new Object ();
V.add (o);
o = null; 
}

In this example, we loop through the object object and put the application in a vector, and if we just release the reference itself, then the vector still references the object, so the object is not recyclable for the GC. Therefore, if the object is added to the vector, it must also be removed from the vector, and the simplest way is to set the vector object to null.

Memory leaks in verbose Java

1.Java Memory Recovery mechanism

Regardless of the type of memory allocation, you need to return the actual address of the allocated memory, which is to return a pointer to the first address of the memory block. Objects in Java are created using new or reflective methods, which are created in the heap (Heap), and all objects are recycled by the Java virtual machine through the garbage collection mechanism. GC in order to properly release objects, will monitor the health of each object, their applications, references, referrals, assignments, and other conditions of monitoring, Java will use a method of mapping to manage memory, real-time monitoring of the object can be achieved, if not reachable, it will be recycled, This can also eliminate the problem of reference loops. In the Java language, there are two criteria for determining whether a single memory space is eligible for garbage collection: one is to give the object a null value NULL, the following has not been invoked, the other is to give the object a new value, so that the memory space is reallocated.

2.Java memory leak causes

A memory leak is a waste object (objects that are no longer in use) that constantly occupy memory or the memory of unwanted objects is not released in a timely manner, resulting in the wasting of memory space called a memory leak. Memory leaks are sometimes not severe and difficult to detect, so developers do not know that there is a memory leak, but sometimes very serious, will prompt you out of the memory.

What is the root cause of Java memory leaks? A long lifecycle object holds a reference to a short lifecycle object and is likely to have a memory leak, even though the short lifecycle object is no longer needed, but because the long lifecycle holds its references and cannot be reclaimed, this is the scenario where memory leaks occur in Java. There are several major categories:

1. Static collection classes cause memory leaks:

The use of hashmap, vectors, and so on is the most vulnerable to memory leaks, and the lifecycle of these static variables is consistent with the application, and all object objects referenced by them cannot be released because they will also be referenced by vectors.

For example

Static vector v = new vector (a);
for (int i = 1; i<100; i++)
{
object o = new Object ();
V.add (o);
o = null;
}

In this example, the loop applies the object object and puts the applied objects into a vector, and if only the reference itself (O=null) is released, the vector still references the object, so the object is not recyclable for the GC. Therefore, if the object is added to the vector, it must also be removed from the vector, and the simplest way is to set the vector object to null.

2. When the object attribute in the collection is modified, the Remove () method is not effective.

For example:

public static void Main (string[] args)
{
set<person> Set = new hashset<person> ();
person P1 = new Person ("Tang Seng", "pwd1",);
person P2 = new Person ("Monkey King", "Pwd2",);
Person P3 = new person ("pig", "pwd3",);
Set.add (p1);
Set.add (p2);
Set.add (p3);
System.out.println ("A total of:" +set.size () + "Element!"); Results: Total: 3 elements!
P3.setage (2); Modify the age of the P3, at which point the P3 element corresponding to the hashcode value changes
set.remove (p3);//At this time remove, resulting in memory leaks
set.add (p3);//re-add, incredibly add success
System.out.println ("A total of:" +set.size () + "Element!"); Results: Total: 4 Elements!
for (person Person:set)
{
System.out.println (person);
}
}

3. Listener

In Java programming, we all need to deal with the listener, usually in an application will use a lot of listeners, we will call a control such as Addxxxlistener () and other methods to increase the listener, but often in the release of the object did not remember to delete these listeners, This increases the chance of memory leaks.

4. Various connections

For example, a database connection (Datasourse.getconnection ()), a network connection (socket), and an IO connection are not automatically reclaimed by GC unless it explicitly calls its close () method to turn its connection off. For Resultset and statement objects, no explicit collection can be made, but connection must be explicitly recycled because connection cannot be automatically recycled at any time, and connection once recycled, Resultset and statement objects are immediately null. However, if you use connection pooling, the situation is different, in addition to explicitly shutting down the connection, you must explicitly close the ResultSet Statement object (either close one and the other will close), otherwise a large number of Statement objects will not be released, causing a memory leak. In this case, the connection is generally going to be in the try, releasing the connection in finally.

5. References to internal classes and external modules

References to internal classes are more easily forgotten and, once not released, can result in a series of subsequent class objects not being released. In addition, programmers have to be careful of the external module inadvertently referenced, such as programmer A is responsible for a module, called the B module of a method such as:

public void registermsg (Object b);

This call must be very careful, passing in an object, it is likely that module B to maintain a reference to the object, this time you need to pay attention to module B to provide appropriate action to remove the reference.

6. Single Case mode

Improper use of single case mode is a common problem that causes memory leaks. A single instance object will exist throughout the JVM's lifecycle (in the form of a static variable) after initialization, and if the single Instance object holds an external reference, the object will not be properly reclaimed by the JVM, causing a memory leak, considering the following example:

Class a{public
A () {
b.getinstance (). SetA (this);
}
....
}
Class B uses a single case model
class b{
private A;
private static B Instance=new B ();
Public B () {} public
static B getinstance () {return
instance;
}
public void SetA (a) {
this.a=a
}
Getter ...
}

Obviously b uses the singleton mode, it holds a reference to a object, and the object of Class A cannot be reclaimed. Imagine what happens if a is a more complex object or collection type.

A common memory leak rollup in Android

Collection class leaks

A collection class can cause memory to be consumed if it has only a method of adding elements without a corresponding deletion mechanism. If the collection class is a global variable (such as a static property in a class, a global map, or a static reference, or final always points to it), then there is no corresponding deletion mechanism, and it is likely that the memory consumed by the collection will only increase. For example, the above typical example is one of the cases, of course, we certainly do not write in the project so 2B code, but a little attention is still very easy to see this situation, such as we all like to do some caching through HashMap things, this situation will be more to keep some heart.

A single example of a memory leak

Because the static nature of a single example makes its lifecycle as long as the application lifecycle, it can easily cause a memory leak if used inappropriately. For example, the following is a typical example,

public class AppManager {
private static AppManager instance;
private context;
Private AppManager {
This.context = context;
}
public static AppManager getinstance {
if (instance = null) {
instance = new AppManager (context) ;
}
return instance
}
}

This is a common single case pattern, and the length of the context's life cycle is critical when creating this single instance because of the need to pass in a context:

1. If the application context is passed in at this time, because the lifecycle of the application is the lifecycle of the entire application, there will be no problem.

2. If the context of the activity is passed in at this time, when the corresponding activity of the context exits, the life cycle of the context is equal to the lifecycle of the entire application because the reference to the context is held by the instance object, so the current activity exits when it Memory is not recycled, which causes a leak.

The correct way should be changed to the following way:

public class AppManager {
private static AppManager instance;
private context;
Private AppManager (Context context) {
this.context = Context.getapplicationcontext ();//Use the context of application
}
public static AppManager getinstance {
if (instance = null) {
instance = new AppManager (context) ;
}
return instance
}
}

Or so write, even the context does not have to pass in:

Add a static method to your application, GetContext () returns to the application context,

...

context = Getapplicationcontext ();
...
/**
* Gets the global context
* @return Returns the global context object *
/public static Context GetContext () {return context
;
}
public class AppManager {
private static AppManager instance;
private context;
Private AppManager () {
this.context = Myapplication.getcontext ();//Use the context of application
} public
Static AppManager getinstance () {
if (instance = null) {
instance = new AppManager ();
}
return instance
}
}

Anonymous internal class/Non-static inner class and asynchronous thread

Non-static internal classes Create a memory leak caused by static instances

There may be times when we may be able to create the same data resources in the active activity, in order to avoid duplication:

public class Mainactivity extends appcompatactivity {
private static testresource mresource = null;
@Override
protected void onCreate (Bundle savedinstancestate) {
super.oncreate (savedinstancestate);
Setcontentview (r.layout.activity_main);
if (Mmanager = = null) {
Mmanager = new Testresource ();
}
//...
}
Class Testresource {
//...
}}

This creates a single instance of a non-static inner class within the activity, which is used every time the activity is started, so that although the duplication of resources is avoided, this type of writing creates a memory leak, because the non-static inner class holds the reference to the external class by default. The non-static inner class creates a static instance with a lifetime of as long as the application, which causes the static instance to hold a reference to the activity all the time, causing the activity's memory resources to not be recycled properly. The correct procedure is:

Set the inner class as a static inner class or extract the inner class into a single example, and if you need to use the context, follow the recommended context for using application. Of course, the context of application is not omnipotent, so it can not be arbitrarily used, for some places must use the context of activity, for Application,service, The context of the activity three scenarios is as follows:

Where: NO1 means that application and Service can start an activity, but you need to create a new task queue. For Dialog, only the activity can create

Anonymous inner class

Android development often inherits implementation Activity/fragment/view, and if you use an anonymous class and are held by an asynchronous thread, be careful if there is nothing to do that will cause the leak

public class Mainactivity extends activity {
...
Runnable ref1 = new myrunable ();
Runnable Ref2 = new Runnable () {
@Override public
void Run () {
}
};
...
}

The difference between REF1 and Ref2 is that REF2 uses an anonymous inner class. Let's take a look at the run-time memory of these two references:

As you can see, ref1 is nothing special.

But there is one more reference to the implementation object of this anonymous class: Ref2

this$ 0 This reference points to mainactivity.this, which means that the current mainactivity instance is held by the REF2, and if the reference is passed to an asynchronous thread, the thread and the acitivity life cycle are inconsistent, causing the activity to leak.

Memory leaks caused by Handler

Handler use of the memory leak caused by the problem should be said to be the most common, many times we in order to avoid ANR and not the main thread for time-consuming operations, in the processing network tasks or encapsulation of some request callback and other APIs are Handler to deal with, but Handler is not omnipotent, for Handler use code to write an irregular is likely to cause a memory leak. In addition, we know that Handler, messages, and MessageQueue are all interconnected, and that the message and the Handler object that sent it will be threaded MESSAGEQUEU if the message sent by Handler has not been processed. E has been held.

Because Handler belongs to the TLS (Thread local Storage) variable, the lifecycle and activity are inconsistent. So this implementation is generally difficult to ensure consistent with the life cycle of the View or activity, so it can easily lead to the inability to release correctly.

As an example:

public class Sampleactivity extends activity {
private final Handler Mleakyhandler = new Handler () {
@Override 
   
    public void Handlemessage (Message msg) {
//...
}
}
@Override
protected void onCreate (Bundle savedinstancestate) {
super.oncreate (savedinstancestate);
Post A and delay its execution for minutes.
Mleakyhandler.postdelayed (New Runnable () {
@Override public
void Run () {/*/* ... */}
}, 1000 *); 
    //go back to the previous activity.
Finish ();
}

   

In the sampleactivity, a message was declared that delayed execution by 10 minutes Message,mleakyhandler pushed it into the Message Queuing MessageQueue. When the activity is dropped, the message for the deferred task continues to exist in the main thread, which holds the Handler reference of the work, so that the finish () will not be recycled to create a memory leak. (Because Handler is a non-static inner class, it holds a reference to the external class, which means sampleactivity).

Fix method: Avoid the use of non-static inner classes in activity, such as the above we declare Handler as static, and its survival is not related to the life cycle of the activity. At the same time, through the weak reference to introduce activity, to avoid directly to the activity as a context, see the following code:

public class Sampleactivity extends activity {/** * instances of static inner classes does not hold a implicit * referenc
E to their outer class. * Private static Class MyHandler extends Handler {private final weakreference<sampleactivity> mactivity; Handler (sampleactivity activity) {mactivity = new weakreference<sampleactivity> (activity); \ @Override Public
void Handlemessage (Message msg) {sampleactivity activity = Mactivity.get (), if (activity!= null) {//...}}}
Private final MyHandler Mhandler = new MyHandler (this);
/** * Instances of anonymous classes do not hold a implicit * reference to their outer the class when they "static".
* * private static final Runnable srunnable = new Runnable () {@Override public void run () {/* ... * *}}; @Override protected void OnCreate (Bundle savedinstancestate) {super.oncreate (savedinstancestate);//Post a message and D
Elay its execution for minutes.
Mhandler.postdelayed (srunnable, 1000 * 60 * 10); Go back toThe previous activity.
Finish (); }
}

Review, that is, the recommended use of static internal classes + WeakReference this way. Pay attention to NULL before each use.

WeakReference is mentioned earlier, so here are a few reference types for Java objects.

Java reference to the classification of strong reference, SoftReference, WeakReference, phatomreference four species.

In the development of Android applications, soft references and weak reference techniques can be used as much as possible to prevent memory overflow and to handle objects with large memory footprint and long declaration periods.

Soft/Weak references can be used in conjunction with a reference queue (Referencequeue), and the Java Virtual machine adds the soft reference to the reference queue associated with it if the object referenced by the soft reference is reclaimed by the garbage collector. This queue lets you know the list of objects that have been recycled for soft/weak references, thereby clearing the failed soft/weak references for the buffers.

Suppose our application uses a large number of default images, such as the default avatar in the application, the default game icon, and so on, which are used in many places. If you read a picture every time, it's slower because it requires hardware to read the file, which can lead to lower performance. So we consider caching the picture and reading it directly from memory when needed. However, because the picture occupies a large memory space, caching many pictures requires a lot of memory, it may be more prone to outofmemory exceptions. At this point, we can consider using soft/weak reference technology to prevent this problem from happening. The following is the prototype of the high speed buffer:

First, define a hashmap and save the soft reference object.

Private Map <string, softreference<bitmap>> imagecache = new HashMap <string, Softreference<bitmap >> ();

Then define a method to save the bitmap soft reference to HashMap.

With soft references, the memory space of these cached picture resources can be freed up before the outofmemory exception occurs, thus avoiding the upper limit of memory and avoiding crash.

If you just want to avoid outofmemory exceptions, you can use soft references. If you care more about the performance of your application, and you want to reclaim some objects that are memory-intensive as soon as possible, you can use weak references.

Alternatively, you can decide whether to select a soft or weak reference based on how often the object is used. If the object is likely to be used frequently, use a soft reference as much as possible. If the object is less likely to be used, you can use a weak reference.

OK, go back to the topic. As mentioned above, create a static Handler inner class and then use a weak reference to the objects held by Handler so that the objects held by Handler can be recycled, but while this avoids activity leaks, looper Message queues for threads are still messages that may be pending, so we should remove messages from Message Queuing MessageQueue when the activity is Destroy or Stop.

There are several ways to remove the message:

Public final void Removecallbacks (Runnable R);
Public final void Removecallbacks (Runnable R, Object token);
Public final void Removecallbacksandmessages (Object token);
Public final void Removemessages (int what);
Public final void Removemessages (int what, object);

Try to avoid using static member variables

If the member variable is declared static, then we all know that its lifecycle will be the same as the entire app process lifecycle.

This can lead to a series of problems, and if your app process is designed to be in a long memory, it will not be released even if the app is cut into the background. According to the current mobile phone app memory management mechanism, the larger memory of the background process will be a priority recovery, Yi ' Wei if this app did process mutual protection, it will cause the app in the background frequently restart. When the phone is installed with the app you're developing, one night the phone is drained of power and traffic, and your app has to be unloaded or silently by the user.

Here's how to fix it:

Do not initialize static members at the beginning of a class. You can consider lazy initialization.
Architectural design to consider whether it is really necessary to do so, as far as possible to avoid. If the architecture requires this design, then the lifecycle of this object is your responsibility to manage it.

Avoid override Finalize ()

1. The date of execution of the Finalize method is uncertain and cannot be relied upon to release scarce resources. The reason for the uncertainty of time is:
The time that the virtual machine calls GC is indeterminate
The time that the Finalize daemon thread is scheduled to be indeterminate

2. The Finalize method will only be executed once, even if the object is resurrected, and if the Finalize method has been executed, the GC will not execute again because:

The object containing the Finalize method is generated by a virtual machine at new time by the VM to refer to the object, and when the Finalize method executes, the finalize Ref for that object corresponds to the reference Erence will be released, even if the object is resurrected at this time (that is, the object is referenced by a strong reference), and the second time the GC does not match the finalize reference, the Finalize method will not be executed again.

3. An object containing a finalize method requires at least two rounds of GC to be released.

Memory leak due to resource not shutdown

The use of resources such as braodcastreceiver,contentobserver,file, cursor cursor,stream,bitmap and so on should be closed or logged off when the activity is destroyed, otherwise these resources will not be recycled, caused a memory leak.

Memory pressure caused by some bad code

Some code does not cause memory leaks, but they either do not release the unused memory efficiently, or do not use existing objects efficiently, but frequently request new memory.

Like what:

Bitmap does not call the Recycle () method, we should call recycle () to free the memory before it is set to NULL for the Bitmap object when not in use. Because the memory space of the Bitmap object is loaded, part of it is Java, part C (because the bottom of the Bitmap allocation is called through JNI). And this recyle () is for the C part of the memory release.
When constructing Adapter, no cached Convertview is used, and a new Converview is created each time. The use of Viewholder is recommended here.

Summarize

References to components such as activity should be controlled within the life cycle of the activity, and if Getapplicationcontext or getapplication are not considered, the activity is not compromised by an object reference to the external minister's life cycle.

Try not to use non-static external member variables (including the context) in static variables or static internal classes, even if you want to use them, consider the need to empty external member variables at the right time, or you can use weak references in inner classes to reference variables of external classes.

You can avoid memory leaks for internal class objects that have a life cycle longer than the activity, and for internal classes that use the member variables of an external class:

Change inner class to static inner class

A weak reference is used in a static inner class to refer to a member variable of an external class
Handler's holding reference object is best to use weak references, and when the resource is released it can also empty the Handler message. For example, when the activity onStop or OnDestroy, cancel the message and Runnable of the Handler object.

In the Java implementation process, also consider its object release, the best way to do this is to explicitly assign NULL to this object when you are not using it, such as calling recycle () after using bitmap, and then assigning null, and emptying the array with direct or indirect references to resources such as pictures (using Array.clear (); Array = null) and so on, it is best to follow the principle of who created who to release.

Properly shut down resources, use of resources such as braodcastreceiver,contentobserver,file, cursor cursor,stream,bitmap, etc., should be closed or cancelled in time for activity destruction.

Maintain sensitivity to the lifecycle of the object, paying special attention to the lifecycle of a single case, static object, global collection, and so on.

The above is a small set of Java to introduce the causes of memory leaks and how to avoid memory leaks (Super detailed version), I hope to help you, if you have any questions please give me a message, small series will promptly reply to everyone. Here also thank you very much for the cloud Habitat Community website support!