2、Java堆与Native堆：Java堆的结构与特点，Native堆的管理方式，两者如何协同工作。
说到Android内存管理，绕不开两个核心区域：Java堆和Native堆。很多刚入行的同学容易把它们搞混，或者以为它们是完全隔离的两个世界。其实不然，它们之间有着千丝万缕的联系。
我个人习惯把Java堆比作一个「管理严格的公寓」，而Native堆则像「自由市场」。为什么这么说？咱们慢慢聊。
Java堆：结构清晰，但规矩多
Java堆是ART/Dalvik虚拟机管理的核心区域。你写的所有new Object()，都分配在这里。它的结构非常清晰，但规矩也多——说白了，就是有GC（垃圾回收）管着你。
Java堆的典型分区
在ART中，Java堆通常分为以下几个区域：
| 区域 | 作用 | 特点 |
|---|---|---|
| Young Generation | 存放新创建的对象 | 分配快，GC频繁，存活率低 |
| Old Generation | 存放长期存活的对象 | GC次数少，但每次耗时较长 |
| Large Object Space | 存放超大对象（如Bitmap数据） | 直接分配，避免频繁移动 |
嗯，这里要注意：Large Object Space在ART中其实是一个独立区域，专门用来放那些「大块头」。我记得有一次排查内存泄漏，发现一个Bitmap对象一直没释放，结果就卡在Large Object Space里，GC怎么扫都扫不掉——因为还有Native层的引用没断。
Java堆的特点
- 自动管理：你只管new，GC帮你收尸。但代价是——你永远不知道它什么时候来收。
- 内存连续：分配时尽量保证连续性，这样访问效率高。但碎片化严重时，GC就得做「压缩」。
- 有上限：每个App的Java堆大小是有限制的，由
dalvik.heapsize等参数控制。超出就OOM。
核心要点：Java堆的分配速度很快，因为只需要移动一个指针（bump-the-pointer）。但GC暂停是个大问题，尤其是Full GC时，动不动就卡顿几十毫秒。
Native堆：自由，但容易失控
Native堆是C/C++代码直接管理的内存区域。你通过malloc、new、mmap等分配的内存，都在这里。它没有GC，没有自动回收，一切靠你自己。
Native堆的管理方式
Native堆的管理通常依赖系统分配器（如jemalloc、dlmalloc）或自定义分配器。Android系统默认使用jemalloc，它在多线程场景下表现不错，碎片控制也还行。
但说实话，Native堆的管理比Java堆复杂得多。你想想看：
- 没有GC帮你扫垃圾，忘记free就是泄漏。
- 分配和释放的时机必须精确匹配，否则就是野指针或double free。
- 碎片化问题更隐蔽，尤其是频繁分配小对象时。
避坑指南：我曾经在一个视频播放器项目中，因为Native层频繁分配解码缓冲区，导致Native堆碎片化严重，最终分配失败。排查了整整两天，才发现是jemalloc的arena配置不合理。从那以后，我养成了一个习惯——在Native层做内存池，减少频繁的malloc/free。
两者如何协同工作？
Java堆和Native堆不是孤立的。它们通过JNI（Java Native Interface）紧密协作。说白了，Java层调用Native方法时，数据需要在两个堆之间传递。
协同工作的典型场景
- Bitmap对象：Java层的
Bitmap对象本身很小（几十字节），但它的像素数据存在Native堆中。Java堆里的Bitmap对象只是一个「句柄」，指向Native堆里的真实数据。 - Direct ByteBuffer：Java层可以分配一块Direct Buffer，它的内存在Native堆中，但Java层可以直接操作。适合I/O密集型场景。
- JNI全局引用：Java对象通过JNI传给Native层时，Native层可以持有全局引用，防止Java对象被GC回收。但如果忘记释放，就会导致Java堆泄漏。
我的经验：在JNI中传递大对象时，尽量使用Direct Buffer或ByteBuffer.allocateDirect()，避免数据在Java堆和Native堆之间拷贝。我曾经优化过一个图像处理模块，把数据拷贝从Java堆改为Direct Buffer，性能提升了30%以上。
协同工作的核心机制
Java堆和Native堆的协同，本质上是通过内存映射和引用管理实现的。我画了一张图，帮你理清它们的关系：
从图中可以看出，Java堆里的对象（比如Bitmap对象）通过JNI全局引用，指向Native堆里的像素数据。当Java层的Bitmap对象被GC回收时，它会触发一个回调，通知Native层释放对应的像素数据。但如果这个回调没执行，或者Native层还持有其他引用，就会导致内存泄漏。
协同工作中的常见问题
在实际项目中，Java堆和Native堆的协同经常出问题。我总结了几种典型场景：
| 问题 | 表现 | 原因 |
|---|---|---|
| Java堆泄漏 | Java堆持续增长，GC无法回收 | Native层持有JNI全局引用未释放 |
| Native堆泄漏 | Native堆持续增长，但Java堆正常 | Native层malloc后忘记free |
| 跨堆引用导致GC暂停 | GC时出现长时间暂停 | GC需要扫描Native层的引用关系 |
避坑指南：我曾经在一个大型App中遇到一个诡异的问题——Java堆看起来很正常，但App的内存占用却越来越高。最后用malloc debug工具一查，发现是Native层的一个音频解码库，每次解码都分配一块缓冲区，但释放逻辑有bug。从那以后，我要求团队在Native层必须使用RAII（资源获取即初始化）模式，确保分配和释放成对出现。
总结一下
Java堆和Native堆的协同，说白了就是「Java管对象，Native管数据」。Java堆负责对象的生命周期管理，Native堆负责实际数据的存储和处理。两者通过JNI这座桥梁沟通，但这座桥梁如果没搭好，就容易出问题。
嗯，最后提醒一句：不要以为Java堆有GC就万事大吉。Native堆的泄漏往往更隐蔽，更难排查。我建议你在开发阶段就开启AddressSanitizer或malloc debug，尽早发现问题。
我的习惯：每次提交代码前，我都会用dumpsys meminfo和procrank检查一下Java堆和Native堆的变化。如果发现异常增长，立刻排查。这个习惯帮我避免了好几次线上事故。