作为一名Android程序开发者，在日常的代码开发工作中可能不会过多关注自己业务对内存的使用是否合理，通常情况下Android系统的内存管理机制帮我们处理好了内存的分配和回收。然而在一些异常场景下不合理的内存占用不仅会使用户应用程序运行卡顿、ANR、黑屏，在极端情况下还会发生 OOM（Out of Memory）崩溃，极大影响用户体验造成用户流失。通常我们在对待线上的的Out of Memory的闪退都会被当做小概率事件没有被有效重视和系统分析，本文将结合支付宝线上OOM真实案例详细的介绍下常见OOM问题的根因分析和优化实践。
在支付宝应用架构的不断演进中用户支付场景已经是最基础的使用场景，随着小程序生态的引入森林庄园等复杂h5/小程序的使用比例不断增长，同时理财、本地生活等重度业务也运行在支付宝这艘航母上，并且在每年的大促活动像双11、618、新春五福活动上线后让本就不富裕的内存空间又雪上加霜，在2020年之前支付宝的内存问题一直未被重点关注，从一组数据可以看到在过去的19-20财年中，客户端OOM闪退率暴涨了近一倍，占整体客户端闪退的45%以上，内存水位则涨幅在300M左右，按照这个趋势20年底的OOM闪退率会涨幅50%。那到底是什么原因导致的支付宝OOM问题如此严重呢？这里先抛出几个问题：
- 线上低端机的OOM问题是否真的比高端机更严重呢？
- 线上的OOM真的全是由于Java内存泄漏导致的堆内存紧张导致的吗？
- 线上OOM有没有可能在App堆内存宽裕，设备物理内存也宽裕的情况下发生？
通过以下数据我们可以看到在支付宝32位包的OOM闪退中9-11系统的占比远远超过6.x以下机器，并且在对闪退时内存统计中发现5.x以上机器闪退时端上整体内存值还有大量剩余，而虚拟内存空间几乎达到了2^32=4GB。
众所周知32位应用程序的虚拟内存寻址上限只有 2^32=4GB，无论高端机还是低端机只要虚拟内存寻址达到这个上限就会触发系统OOM闪退，通常在logcat日志中会看到"OutOfMemoryError: pthread_create (1040KB stack) failed: Try again", "libc abi: terminating with uncaught exception of type St9bad_alloc: std::bad_alloc"，"Could not mmap handle 0x67ae34d0 fd=652 (Out of memory)"等。因此按照不同的成因我们总结了OOM问题分类，只有对线上OOM问题清晰的认识和分类才能更好的感知问题变化和有针对性的治理
下面将会从虚拟内存结构入手详细地讲解一下导致虚拟内存寻址空间不足的原因，从下图内存结构看出去系统占据的1G外剩下3GB内存都是如何分配？通常我们在写 Native 代码的时候，并不会直接调用内核的 API 去申请物理内存，而是使用 malloc 族的函数进行内存申请，这时候返回的指针是指向虚拟内存中的地址空间，之后在这部分地址空间真的被使用的时候，才会发生缺页中断触发真实的物理内存分配，所以通常是两层分配结构，用户态的代码申请的内存来自于内存分配器的二次分配，常见的内存分配器有 JeMalloc、TcMalloc、PtMalloc 等等。这里也解答了上面的问题，手机物理内存或javaheap内存只使用不到50%的情况下，虚拟内存可能已经打满同样会触发OOM闪退。
