android where 变量,Android OOM问题的What Where How

知己知彼，百战不殆。

要想解决和避免OOM，必须先知道OOM是什么，在哪里会发生，最后才是怎样去解决OOM；

What？什么是OOM

OOM --> java.lang.OutOfMemoryError

内存溢出，应用内存占用过高，虚拟机无法再分配更多的内存，这时系统就会抛出OOM，JVM规范中划定了大部分区域的内存的管理，可参考JVM规范官方文档：https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#d5e24307

Where & How？ 哪里会出现OOM，怎么解决

首先要了解运行时内存区域的划分，可参考我的博客：

https://blog.csdn.net/u013360790/article/details/89510941

JVM除了程序计数器没有对内存做限制，其他内存区域都可以抛出OOM；

主要分为三大块，线程共享的堆和方法区，以及线程私有的栈，包括虚拟机栈和本地方法栈；

堆

堆中主要存放对象的实例，所以如果当堆无法存下要对象分配的空间，并且无法再进行扩展，这时就会抛出OOM；

这个就比较好理解了，JDK1.8字符串也存储在堆中，几乎所有对象实例都在堆中，GC时间过长的也会引起OOM；

方法区\MetaSpace

方法区内存不足时也将会抛出OutOfMemoryError异常，而方法区主要存的类信息，以及常量，所以当我们系统本身内存不足时，进行加载大量的类或者常量时，也有可能出现OOM，在JDK1.7以前，连字符串常量都存储在方法区；

栈

虚拟机可以动态扩展，当扩展时无法申请到足够的内存，就会抛出OutOfMemoryError异常，比如在我们递归调用时，递归分为两步，一步递，一步归，所以在内存如果出现大量临时引用等，也有可能导致OOM；常见在Debug模式时，程序运行明显不如关闭Debug模式流畅，因为debug时需要额外存储大量调试信息；

根据JDK和Android 8.0源码，看下都什么地方Throw OutOfMemoryError

如果查找几个就会看出问题，系统都在什么情况下会抛出OOM，知道如何引起，自然知道如何避免和解决了；

集合类

大部分长度超出Integer.MAX_VALUE - 8 时，系统会抛出Required array size too large，Requested array size exceeds VM limit；

IO操作

缓存过大，在Bitmap操作时，比如decodeStream()，可能抛出ImageUtils#decodeStream(InputStream, Rect, Options) threw an OOME，说明过大的文件加载到了内存中；

线程泄漏

创建线程超出JVM限制时会抛出unable to create new native thread，所以要注意线程的关闭，比如在使用ExecutorService记得shutDown；防止线程挂起或者阻塞或者等待获取锁时间过长，比如出现死锁；

数据操作

Cursor未进行及时close，在AbstractWindowedCursor中可以看到，Cursor存储了我们从数据库中查询回来的东西，所以在使用完要及时关闭，等待GC来回收是不靠谱的，因为有可能由于引用还在，所以无法回收；

变量生命周期尽量短

比如局部变量，因为引用存在栈中，所以方法弹栈后经过GC时就可以被回收，自然比成员变量生命周期短，及时的回收内存，自然可以有效避免内存溢出；

引用泄漏

这个非常好理解，例如泄漏Context，比如Activity这种Context往往是承载整个应用视图会引用大量变量，Context被生命周期更长的对象引用时，就无法回收Context了，就会出现内存泄漏，泄漏多了，自然溢出；

举一反三，除了我们Android的Context，所有代码中的线程间交互，内部类对外部类的引用等都有可能在生命周期不一致情况下，造成内存泄漏，所以这种需要在编写代码时刻意防范；

递归调用

使用递归时注意出口，并且和For循环一样，尽量避免在内部循环创建对象，也要注意调用栈深度，否则也会报StackOverflowError；

还有很多细节平时多注意就好；

Android 可以使用LeakCanary来监控Context的泄漏，并能生成内存快照；

然后可以使用Android Studio或者Mat来对heep dump进行分析；