android内存管理机制

对于一个Java程序员来说，大多数情况下的确是无需对内存的分配、释放做太多考虑，对Jvm也无需有多么深的理解的。 但是在写程序的过程中却也往往因为这样而造成了一些不容易察觉到的内存问题，并且在内存问题出现的时候，也不能很快的定位并解决。 因此，了解并掌握Java的内存管理是一个合格的Java程序员必需的技能，也只有这样才能写出更好的程序，更好地优化程序的性能。 一、背景知识 根据网络可以找到的资料以及笔者能够打听到的消息，目前国内外著名的几个大型互联网公司的语言选型概括如下： Google: C/C++ Go Python Java JavaScript，不得不提的是Google贡献给java社区的guava包质量非常高，非常值得学习和使用。 Youtube、豆瓣: Python Fackbook、Yahoo、Flickr、新浪： php(优化过的php vm) 网易、阿里、搜狐: Java、PHP、Node.js Twitter: Ruby->Java,之所以如此就在于与Jvm相比，Ruby的runtime是非常慢的。并且Ruby的应用比起Java还是比较小众的。不过最近twitter有往scala上迁移的趋势。 可见，虽然最近这些年很多言论都号称java已死或者不久即死，但是Java的语言应用占有率一直居高不下。 与高性能的C/C++相比，Java具有gc机制

之所以想到写本文，是因为看到鸿洋微博的RecyclerView实现抖音效果的文章。里面讲了ViewPager实现会OOM，RecyclerView不会。 第一个get的点，RecyclerView打造成ViewPager，这个就不用多说了，SnapHelper封装了这一切 第二个get的点，为什么RecyclerView不会OOM呢？ 这需要掌握RecyclerView一些浅显的原理。RecyclerView除了界面上显示的item，还有上下各2个供4个的预加载item。所以他内存中有 当前界面可见item数量+4 个数的item。他会在滑动的时候，不断bind新的数据。 ViewPager则是需要给他View的集合，你如果有10000个item，那内存中就必须有10000个item。 曾经我懵懂的时候问过Android老师，怎么才能只使用3个item去实现ViewPager？ 这个问题挺白痴的，因为很简单就能实现。但是没想到老师说的答案令我震惊了，你没必要这么搞，他会自动替你管理，你移动到哪里就会有对应的item的销毁和创建。我说，假如我要写一个电子书，他有10000页，我肯定不能让他有10000页在内存中的对吗。他说，现在手机硬件都很好了，你做的这点优化微不足道。。。 这里就不写后续剧情了。我们固然可以用少量的item去实现ViewPager

对于从事 C/C++ 程序开发的开发人员来说，在内存管理领域，他们既是拥有最高权力的帝皇，又是从事最基础工作的劳动人民——既拥有每一个对象的“所有权”，又担负着每一个对象生命从开始到终结的维护责任。 对于 Java 程序员来说，在虚拟机的自动内存管理机制的帮助下，不在需要为每一个 new 操作去写配对的 delete/free 代码，而且不容易出现内存泄漏和内存溢出问题，看起来由虚拟机管理内存一切都很美好。不过也正是因为 Java 程序员把内存控制权交给了 Java 虚拟机，一旦出现内存泄漏和溢出的问题，如果不了解虚拟机怎样使用内存的，那排查错误将会成为一项异常艰难的工作。 1. 什么是 JVM？ JVM（Java 虚拟机）是 Java Virtual Machine 的缩写，它是一个虚构出来的计算机，通过在实际的计算机上仿真模拟各种计算机功能来实现的。 JVM 有自己的硬件架构，如处理器、堆栈、寄存器等，还有对应分指令系统。 假如一个程序使用的内存区域是一个货架，那 JVM 就相当于是一个淘宝店铺，它不是真实存在的货架，但它和真实货架一样可以上架和下架商品，而且上架的商品数量也是有限的。 假如货架是在深圳，那 JVM 的平台无关性就相当于是客人可以在各个地方购买你在淘宝上发布的商品，不是只有在深圳才能购买货架上的商品。 2. 什么是 Java 内存模型？ Java

Android内存管理机制 Android内存管理主要有：LowMemory Killer机制，Ashmem，PMEM/ION及Native内存和Dalvik内存管理管理和JVM垃圾回收机制。 LowMemory Killer机制 源码位置drivers/staging/Android/lowmemorykiller.c Android是一个多任务系统，也就是说可以同时运行多个程序，这个大家应该很熟悉。一般来说，启动运行一个程序是有一定的时间开销的，因此为了 加快运行速度，当你退出一个程序时，Android并不会立即杀掉它，这样下次再运行该程序时，可以很快的启动。随着系统中保留的程序越来越多，内存肯定 会出现不足，low memory killer就是在系统内存低于某值时，清除相关的程序，保障系统保持拥有一定数量的空闲内存。 Low memorykiller根据两个原则，进程的重要性和释放这个进程可获取的空闲内存数量，来决定释放的进程。 进程的重要性，由task_struct->signal_struct->oom_adj决定， Android将程序的重要性分成以下几类，按照重要性依次降低的顺序，每个程序都会有一个oom_adj值，这个值越小，程序越重要，被杀的可能性越低： 除了上述程序重要性分类之外，Android系统还维护着另外一张表minfree用于维护内存警戒值

概述 在 android 的开发中，要时刻主要内存的分配和垃圾回收，因为系统为每一个 dalvik 虚拟机分配的内存是有限的，在 google 的 G1 中，分配的最大堆大小只有 16M ，后来的机器一般都为 24M ，实在是少的可怜。这样就需要我们在开发过程中要时刻注意。不要因为自己的代码问题而造成 OOM 错误。 JAVA 的内存管理 大家都知道， android 应用层是由 java 开发的， android 的 davlik 虚拟机与 jvm 也类似，只不过它是基于寄存器的。因此要了解 android 的内存管理就必须得了解 java 的内存分配和垃圾回收机制。 在 java 中，是通过 new 关键字来为对象分配内存的，而内存的释放是由垃圾收集器（ GC ）来回收的，工程师在开发的过程中，不需要显式的去管理内存。但是这样有可能在不知不觉中就会浪费了很多内存，最终导致 java 虚拟机花费很多时间去进行垃圾回收，更严重的是造成 JVM 的 OOM 。因此， java 工程师还是有必要了解 JAVA 的内存分配和垃圾回收机制。 内存结构 上面这张图是 JVM 的结构图，它主要四个部分组成： Class Loader 子系统和执行引擎，运行时方法区和本地方法区，我们主要来看下 RUNTIME DATA AREA区，也就是我们常说的JVM内存。从图中可以看出， RUNTIME