一、OOM类型
1.1 java堆内存超限 + 无足够连续内存空间
传统的 java 堆内存超限，即申请堆内存大小超过了 Runtime.getRuntime().maxMemory();
此时打印的LOG信息长这样：
void Heap::ThrowOutOfMemoryError(Thread* self, size_t byte_count, AllocatorType allocator_type)
抛出时的错误信息：
oss << "Failed to allocate a " << byte_count << " byte allocation with " << total_bytes_free << " free bytes and " << PrettySize(GetFreeMemoryUntilOOME()) << " until OOM";
对于由于进程中存在大量的内存碎片，没有足够空间可以分配内存的，会额外多一个LOG信息：
failed due to fragmentation (required continguous
free “<< required_bytes << " bytes for anew buffer where largest
contiguous free " << largest_continuous_free_pages << " bytes)”;
其详细代码在 art/runtime/gc/allocator/rosalloc.cc
案例
这个案例介绍的是由于
Handler使用不当（多次post，却没有及时remove）造成的OOM
由于
sCompatVectorFromResourcesEnabled（会产生多个Resources实例，资源复用失败）不恰当使用，导致的OOM血案
1.2 线程数超限 + 虚拟内存不足
线程数超限，即proc/pid/status中记录的线程数（threads 项）突破 /proc/sys/kernel/threads-max 中规定的最大线程数。
可能的发生场景有：
- app 内多线程使用不合理，如多个不共享线程池的 OKhttpclient 等等 ;
打印LOG信息：
void Thread::CreateNativeThread(JNIEnv* env, jobject java_peer, size_t stack_size, bool is_daemon)
抛出时的错误信息：
"Could not allocate JNI Env"
或者
StringPrintf("pthread_create (%s stack) failed: %s", PrettySize(stack_size).c_str(), strerror(pthread_create_result)));
创建线程可以分为两个步骤：
- 调用 mmap 分配栈内存。这里 mmap flag 中指定了 MAP_ANONYMOUS，即匿名内存映射。这是在 Linux 中分配大块内存的常用方式。其分配的是虚拟内存，对应页的物理内存并不会立即分配，而是在用到的时候触发内核的缺页中断，然后中断处理函数再分配物理内存。
- 调用 clone 方法进行线程创建。
第一种是由于进程的虚拟内存不足，抛出错误如下：
W/libc: pthread_create failed: couldn't allocate 1073152-bytes mapped space: Out of memory
W/tch.crowdsourc: Throwing OutOfMemoryError with VmSize 4191668 kB "pthread_create (1040KB stack) failed: Try again"
java.lang.OutOfMemoryError: pthread_create (1040KB stack) failed: Try again
at java.lang.Thread.nativeCreate(Native Method)
at java.lang.Thread.start(Thread.java:753)
第二种是线程数超出限制，clone方法失败
W/libc: pthread_create failed: clone failed: Out of memory
W/art: Throwing OutOfMemoryError "pthread_create (1040KB stack) failed: Out of memory"
java.lang.OutOfMemoryError: pthread_create (1040KB stack) failed: Out of memory
at java.lang.Thread.nativeCreate(Native Method)
at java.lang.Thread.start(Thread.java:1078)
案例
这个案例是关于在部分华为手机上，当线程数超过500个，产生OOM的分析验证过程。
1.3 文件描述符 (fd) 数目超限
文件描述符 (fd) 数目超限，即 proc/pid/fd 下文件数目突破 /proc/pid/limits 中的限制。可能的发生场景有：短时间内大量请求导致 socket 的 fd 数激增，大量（重复）打开文件等 ;
二、如何定位OOM
首先要知道复现OOM的操作步骤，如果是随机测试出的，也需要找到一个有效的复现步骤才行。取操作前的 .hprof，和操作后，内存增长后的 .hprof。如果内存不断增长，可取3，4次。然后分别打开MAT的 直方图（Histogram）视图，在对象列表中，对比每个对象的 Retained size的变化。
- ShallowSize：对象自身占用的内存大小，不包括它引用的对象。
- RetainedSize：对象自身的 ShallowSize 和对象所支配的（可直接或间接引用到的）对象的 ShallowSize 总和，就是该对象 GC 之后能回收的内存总和。例如上图中，D 的` RetainedSize` 就是 D、H、I 三者的 ShallowSize 之和。
考虑到 RetainSize 越大的对象对内存的影响也越大，即 RetainSize 比较大的那部分 Instance 是最有可能造成 OOM 的“元凶”。
注：大对象 ！= 内存泄漏对象。排在第一位的对象，有可能它本身正常情况就很消耗内存，真正内存泄露的对象，是那个突然排名上升的。
三、OOM 监控措施
3.1 针对线程数/fd超限
可以利用 linux 的 inotify 机制进行监控:
- watch /proc/pid/fd来监控 app 打开文件的情况,
- watch /proc/pid/task来监控线程使用情况．
3.2 针对堆内存超限
单独开一个线程进行兜底，如图：
3.3 针对全局：Probe
Probe是美团出品的OOM检测工具，它能够有效定位线上 Java 堆内存不足、FD 泄漏以及线程溢出的 OOM 问题。感兴趣的可以了解下~
四、 如何避免OOM（内存优化经验）
- 使用更加轻量的数据结构
使用 ArrayMap/ SparseArray替代HashMap等传统数据结构。 ArrayMap是Android系统专为移动操作系统编写的容器，在大多数情况下，比HashMap效率更高，占用内存更少。 SparseArray更加高效在于它们避免了对key和value的autobox自动装箱，并且避免了装箱后的解箱。
- 避免在Android里面使用Enum
- 减小Bitmap对象的内存占用
- 使用更小的图
- 避免在onDraw方法里面执行对象的创建
- 注意缓存容器中的对象泄漏
如果容器是静态或者全局的，那么对于里面存放的对象要及时remove。
- 检查内存泄漏，包括常见的Context泄漏、单例泄漏、EditText的TextWatcher泄漏等等，找到并fix他们，最简单的例子，能传application的地方就不要硬传个activity过去
- 在Activity onDestory的时候，遍历View树，清空backGround、Drawable、EditText的TextWatcher等
- Fresco的优化：RN中使用Fresco加载图片，在RN Activity销毁的时候，会将Fresco默认的memory cache清空，但是动图的缓存没有清
