内存泄露：
长生命周期对象引用了短生命周期对象，导致短生命周期对象得不到释放，GC时无法回收短对象，从而会导致内存泄露
内存泄露最终可能会导致OOM出现。
OOM：应用程序无法申请足够的内存空间，并且，gc之后也释放不出足够的内存空间就会导致OOM。
出现OOM原因：
1.设置的堆（或者元空间）大小太小。
2.一次性创建了太多对象，例如通过sql查询表中的全部数据。
3.应用程序使用完的对象没有被及时释放，导致内存无法回收，长期积累导致内存不足，最终会导致内存耗尽，这种情况叫做内存泄露。
Jvm主要划分为如下几部分：
（1）方法区：1>保存类的信息，类名称，类的访问权限，父类，接口等信息。2>保存方法信息，方法名称和方法访问权限，以及方法字节码。3>静态变量 4>运行时常量池，对应类字节码中的常量池。每个类对应一个运行时常量池，存储字面量和符号引用和5>字符串常量池，保存字符串对象，防止重复创建字符串对象，减少内存占用 ，类直接是共享的 6>jit编译的机器码缓存
（2）堆：保存java对象
（3）程序计数器，保存当前线程将要执行的下一条字节码指令
（4）虚拟机栈，用来存储函数局部变量，参数，返回地址等数据，线程私有
（5）本地方法栈，存储native函数局部变量，参数返回地址等数据
Gc作用区域主要是堆，还有方法区中的一些类对象
怎么判断对象是否可回收：可达性分析，将局部变量和静态变量引用的对象作为gc root，从gc root开始使用广度或者深度遍历算法查找引用对象，如果此对象在引用链上就说明此对象可达属于存活对象，如果不在就属于非存活对象，非存活对象就是gc回收的对象
安卓中怎么检查是否有内存泄露：
1.通过引入leakcanery
实现原理：使用application.RegisterActivity Lifecycle方法监听activity的 destroy生命周期回调，此时随机生成字符串作为key，同当前activity，引用队列，一起构造出弱引用对象，同时将key保存至set中。构造弱引用对象的时候设置引用队列作用是，当弱引用中的对象被回收后，会将此弱引用放至引用队列中。
使用idlehadler在主线程空闲的时候延迟5s发送消息，在子线程中执行判断activity是否存在内存泄露，具体逻辑：首先通过引用队列中已经回收对象的ref，根据他们的key匹配set中的key并将key移除，此时可以发现set中保存的就是已经destroy但是没有回收的key。然后判断当前对象是否被回收即set中是否包含此key，如果不包含即已经回收就直接返回，如果包含即没有回收就手动执行gc，执行以后再通过引用队列将set中回收的key移除，此时再进行判断当前对象是否被回收，如果回收就返回，如果没有说明存在内存泄露，dump此时的heap，生成heap.file，然后进行分析此file，将可能发生的内存泄露信息展示给用户。
2.使用 studio自带的profiler工具进行分析
使用步骤：https://blog.csdn.net/Calvin_zhou/article/details/119681272
安卓中常见的内存泄露场景：
1.静态引用导致内存泄露：
静态变量持有activity或者fragment引用
解决：在不需要持有引用时及时设置为null
2.匿名内部类和非静态内部类
匿名内部类和非静态内部类会持有外部类引用，如果没有适当释放这些类会导致外部类无法被回收
解决：将匿名内部类和非静态内部类改为静态内部类，或者将外部类引用传递给内部类时使用弱引用进行传递，避免对外部类强引用
3.资源未正确释放
4.单例模式导致的内存泄露
单例对象的生命周期是整个应用程序生命周期，如果在单例对象中持有了activity或者fragment引用，就会导致activity或者fragment无法被回收，从而导致内存泄露
