软引用，弱引用-CSDN博客

GC格式：

Roughly speaking, the format is

[Reason] [Amount Freed], [Heap Statistics], [External Memory Statistics], [Pause Time]

GC_FOR_MALLOC means that the GC was triggered because there wasn't enough memory left on the heap to perform an allocation. Might be triggered when new objects are being created.

GC_EXPLICIT means that the garbage collector has been explicitly asked to collect, instead of being triggered by high water marks in the heap. Happens all over the place, but most likely when a thread is being killed or when a binder communication is taken down.

There are a few others as well:

GC_CONCURRENT Triggered when the heap has reached a certain amount of objects to collect.

GC_EXTERNAL_ALLOC means that the the VM is trying to reduce the amount of memory used for collectable objects, to make room for more non-collectable.

typedefenum{
    /* Not enough space for an "ordinary" Object to be allocated. */
    GC_FOR_MALLOC,
    /* Automatic GC triggered by exceeding a heap occupancy threshold. */
    GC_CONCURRENT,
    /* Explicit GC via Runtime.gc(), VMRuntime.gc(), or SIGUSR1. */
    GC_EXPLICIT,
    /* GC to try to reduce heap footprint to allow more non-GC'ed memory. */
    GC_EXTERNAL_ALLOC,
    /* GC to dump heap contents to a file, only used under WITH_HPROF */
    GC_HPROF_DUMP_HEAP
}GcReason;

GC_EXTERNAL_ALLOC freed 297K, 49% free 3411K/6663K, external 24870K/26260K, paused 83ms

前面Free的内存是VM中java使用的内存，external是指VM中通过JNI中Native的类中的malloc分配出的内存，例如Bitmap和一些Cursor都是这么分配的。
在Davilk中，给一个程序分配的内存根据机型厂商的不同，而不同，现在的大部分的是32M了，而在VM内部会把这些内存分成java使用的内存和 Native使用的内存，它们之间是不能共享的，就是说当你的Native内存用完了，现在Java又有空闲的内存，这时Native会重新像VM申请，而不是直接使用java的。
例如上边的例子
free 3411K/6663K和external 24870K/26260K 如果这时需要创建一个2M的Bitmap，Native现有内存26260-24870=1390K<2048k,因此他就会向Vm申请内存，虽然java空闲的内存是 6663-3411=3252>2048,但这部分内存Native是不能使用。
但是你现在去申请2M的Native内存，VM会告诉你无法分配的，因为现在已使用的内存已经接近峰值了32M(26260+6663=32923 )，所以现在就会成force close 报OOM。
所以现在我们要检查我们的native内存的使用情况来避免OOM。

大家都知道Android的上层应用是基于 Dalvik Virtual Machine的。Dalvik VM的特点是基于寄存器，相比SUN的JVM（基于堆栈，没有寄存器）来说，理论上完成同样的功能需要的指令条数少，但是指令集复杂。到了Android2.2，Dalvik终于实现了JIT（Just In Time）功能，前进了一大步。

近期我们遇到OutOfMemory的错误，通常是堆内存溢出。网上有些帖子说可以通过函数设置应用的HEAP SIZE来解决这个问题，其实是不对的。

VMRuntime.getRuntime().setMinimumHeapSize(NewSize);

堆（HEAP）是VM中占用内存最多的部分，通常是动态分配的。堆的大小不是一成不变的，通常有一个分配机制来控制它的大小。比如初始的HEAP是4M大，当4M的空间被占用超过75%的时候，重新分配堆为8M大；当8M被占用超过75%，分配堆为16M大。倒过来，当16M的堆利用不足30%的时候，缩减它的大小为8M大。重新设置堆的大小，尤其是压缩，一般会涉及到内存的拷贝，所以变更堆的大小对效率有不良影响。

上面只是个例子，不过可以看到三个参数：max heap size, min heap size, heap utilization（堆利用率）。

Max Heap Size，是堆内存的上限值，Android的缺省值是16M（某些机型是24M），对于普通应用这是不能改的。函数setMinimumHeapSize其实只是改变了堆的下限值，它可以防止过于频繁的堆内存分配，当设置最小堆内存大小超过上限值时仍然采用堆的上限值（16M），对于内存不足没什么作用。

setTargetHeapUtilization(float newTarget) 可以设定内存利用率的百分比，当实际的利用率偏离这个百分比的时候，虚拟机会在GC的时候调整堆内存大小，让实际占用率向个百分比靠拢。

//程序onCreate时调用

private final static floatTARGET_HEAP_UTILIZATION = 0.75f;

VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION);

总结：

手机应用开发资源是很有限的，堆内存的上限值只有16M。不过只要代码写的好，这个值对于目前的手机应用需求已经足够了。

如果出现内存溢出问题，把精力放在代码优化上吧。

首先分清楚Stack，Heap的中文翻译：Stack—栈，Heap—堆。

在中文里，Stack可以翻译为“堆栈”，所以我直接查找了计算机术语里面堆和栈开头的词语：

堆存储： heapstorage 堆存储分配： heapstorage allocation 堆存储管理： heap storage management

栈编址： stack addressing 栈变换：stack transformation 栈存储器：stack memory 栈单元： stack cell

接着，总结在Java里面Heap和Stack分别存储数据的不同。

	Heap(堆)	Stack(栈)
JVM中的功能	内存数据区	内存指令区
存储数据	对象实例(1)	基本数据类型, 指令代码,常量,对象的引用地址(2)

1. 保存对象实例，实际上是保存对象实例的属性值，属性的类型和对象本身的类型标记等，并不保存对象的方法（方法是指令，保存在stack中）。

对象实例在heap中分配好以后，需要在stack中保存一个4字节的heap内存地址，用来定位该对象实例在heap中的位置，便于找到该对象实例。

2. 基本数据类型包括byte、int、char、long、float、double、boolean和short。
函数方法属于指令.

=======================

引用网上广泛流传的“Java堆和栈的区别”里面对堆和栈的介绍；

"Java 的堆是一个运行时数据区,类的(对象从中分配空间。这些对象通过new、newarray、anewarray和multianewarray等指令建立，它们不需要程序代码来显式的释放。堆是由垃圾回收来负责的，堆的优势是可以动态地分配内存大小，生存期也不必事先告诉编译器，因为它是在运行时动态分配内存的，Java的垃圾收集器会自动收走这些不再使用的数据。但缺点是，由于要在运行时动态分配内存，存取速度较慢。"

“栈的优势是，存取速度比堆要快，仅次于寄存器，栈数据可以共享。但缺点是，存在栈中的数据大小与生存期必须是确定的，缺乏灵活性。栈中主要存放一些基本类型的变量（,int, short, long, byte, float, double, boolean, char）和对象句柄。 ”

可见，垃圾回收GC是针对堆Heap的，而栈因为本身是FILO - first in, last out. 先进后出，能够自动释放。这样就能明白到new创建的，都是放到堆Heap！

Android为什么会在Decode Bitmap的时候出现OOM错误，简单的讲就是Android在解码图片的时候使用了本地代码来完成解码的操作，但是使用的内存是堆里面的内存，而堆内存的大小是收VM实例可用内存大小的限制的，所以当应用程序可用内存已经无法再满足解码的需要时，Android将抛出OOM错误。

为了确保我们外部分配内存成功，我们应该保证当前已分配的内存加上当前需要分配的内存值，大小不能超过当前堆的最大内存值，而且内存管理上将外部内存完全当成了当前堆的一部分。也许我们可以这样理解，Bitmap对象通过栈上的引用来指向堆上的Bitmap对象，而Bitmap对象又对应了一个使用了外部存储的native图像，实际上使用的是byte[]来存储的内存空间，如下图：

当调用native方法的时候，就进入了一个全新的并且不再受虚拟机限制的世界

*弱引用无效，很有可能是因为弱引用的对象还有其它的强引用指向这个对象。

*Native的空间一旦分配，就不可再动态分给其它堆空间了，但native的空间中的分配的内存还是会被释放的。（也就是说分配给native heap的内存只能变大不能变小）

*软引用当内存不足的时候，会清理内存。内存不足的意思是：当前已分配的堆空间不足，而不是总的堆空间不足。