Java memory leaks

Although Java has GC garbage auto-recycling, it doesn't mean that Java programs will not have memory leaks. If an object is nowhere to be used, but there is still a reference pointing to him, then the garbage collector cannot recycle him, which is a memory leak. Such leaks can be transient (that is, the program runs for a period of time after the reference is eliminated and then departs the GC) or it may be at the program level (that is, it is not recycled until the program exits). The memory leaks in Java are different from the memory leaks in C/s + +, which can be system-level, and can only be restarted if the program exits and cannot be recycled.

The Android system assigns a fixed-size heap to each program, and when it uses more than the heap memory, it triggers oom, so when you develop an Android program, the allocation of the control heap is released and the objects are allocated in the following cases.

1. The lifetime of a static object is at the program level, and the lifetime of the object is as long as the static object when it references a static object or a static object that references objects on the heap.

2. As a thread of an inner class (including Asynctask), because the thread's run cycle and the period of the object are inconsistent, the running thread defaults to owning the reference to the object it is in, so the thread that is running destroys the object that it resides in does not actually recycle, but waits until the thread exits before it executes.

3. There is no anti-registration after registering an object.

4. Resource objects should be closed in time, such as (Cursor,file), such objects often not only have Java heap memory and native heap memory, so need to close ();

These tend to cause the memory leak to drop and cause oom, the following is the chance to reduce the chances of Oom releasing

1. Bitmap distribution According to the needs of the size allocation, and timely destruction, because bitmap tend to occupy a large amount of memory, and part of the native, plus GC timing affected by the system, if not released in time to destroy the bitmap, it will cause excessive memory use caused oom

2. Using softrefrence, this type of object is effectively released when memory is tight

3. Reduce the memory allocation and release of pressure to the system, such as GetView in adapter, by Viewholder view reuse

Java memory leaks