本节书摘来自异步社区《深入解析Android 虚拟机》一书中的第2章，第2.5节，作者：钟世礼著，更多章节内容可以访问云栖社区“异步社区”公众号查看
2.5 内存异常和垃圾处理
对于C和C++的开发人员来说，在内存管理领域应该能够游刃有余。在计算机系统中，内存负责维护每一个对象生命的从开始到终结。Java内存分配与管理是Java的核心技术之一，通常Java在内存分配时会涉及到以下区域。
寄存器：在程序中无法控制。
栈：存放基本类型的数据和对象的引用，但对象本身不存放在栈中，而是存放在堆中。
堆：存放用new产生的数据。
静态域：存放在对象中用static定义的静态成员。
常量池：存放常量。
非RAM存储：硬盘等永久存储空间。
2.5.1 内存分配中的栈和堆
1．栈
在函数中定义的一些基本类型的变量数据，还有对象的引用变量都在函数的栈内存中分配。当在一段代码块中定义一个变量时，Java就在栈中为这个变量分配内存空间；当该变量退出该作用域后，Java会自动释放掉为该变量所分配的内存空间，该内存空间可以立即被另作他用。
栈也称为栈内存，是Java程序的运行区，是在线程创建时创建，它的生命期跟随着线程的生命期，线程结束栈内存也就释放。对于栈来说不存在垃圾回收问题，只要线程一结束，该栈就被释放。问题出来了：栈中存的是那些数据呢？又什么是格式呢？
栈中的数据都是以栈帧（Stack Frame）的格式存在，栈帧是一个内存区块，是一个数据集，是一个有关方法（Method）和运行期数据的数据集。当一个方法A被调用时就产生了一个栈帧F1，并被压入到栈中，A方法又调用了B方法，于是产生栈帧F2也被压入栈；执行完毕后，先弹出F2栈帧，再弹出F1栈帧，遵循“先进后出”原则。
那栈帧中到底存在着什么数据呢？在栈帧中主要保存如下3类数据。
本地变量（Local Variables）：包括输入参数和输出参数以及方法内的变量。
栈操作（Operand Stack）：记录出栈、入栈的操作。
栈帧数据（Frame Data）：包括类文件、方法等。
光说比较枯燥，画个图来理解一下Java栈，如图2-6所示。
在图2-6中，一个栈中有两个栈帧，栈帧2是最先被调用的方法，先入栈，然后方法2又调用了方法1。栈帧1处于栈顶的位置，栈帧2处于栈底，执行完毕后，依次弹出栈帧1和栈帧2，线程结束，栈释放。
2．堆
堆内存用来存放由关键字new创建的对象和数组。在堆中分配的内存，由Java虚拟机的自动垃圾回收器来管理。
在堆中产生了一个数组或对象后，还可以在栈中定义一个特殊的变量，让栈中这个变量的取值等于数组或对象在堆内存中的首地址，栈中的这个变量就成了数组或对象的引用变量。引用变量就相当于是为数组或对象起的一个名称，以后就可以在程序中使用栈中的引用变量来访问堆中的数组或对象。引用变量就相当于是为数组或者对象起的一个名称。
引用变量是普通的变量，定义时在栈中分配，引用变量在程序运行到其作用域之外后被释放。而数组和对象本身在堆中分配，即使程序运行到使用new产生数组或者对象的语句所在的代码块之外，数组和对象本身占据的内存不会被释放，数组和对象在没有引用变量指向它的时候，才变为垃圾，不能再被使用，但仍然占据内存空间不放，在随后的一个不确定的时间被垃圾回收器收走（释放掉）。这也是 Java 比较占内存的原因。
实际上，栈中的变量指向堆内存中的变量，这就是Java中的指针。
3．常量池（constant pool）
常量池指的是在编译期被确定，并被保存在已编译的.class文件中的一些数据。除了包含代码中所定义的各种基本类型（如int、long等等）和对象型（如String及数组）的常量值（final）还包含一些以文本形式出现的符号引用，比如：
类和接口的全限定名；
字段的名称和描述符；
方法和名称和描述符。
虚拟机必须为每个被装载的类型维护一个常量池。常量池就是该类型所用到常量的一个有序集合，包括直接常量（string, integer和floating point常量）和对其他类型、字段和方法的符号引用。
对于String常量，它的值是在常量池中的。而JVM中的常量池在内存当中是以表的形式存在的，对于String类型，有一张固定长度的CONSTANT_String_info表用来存储文字字符串值，但是该表只存储文字字符串值，并不存储符号引用。在程序执行的时候，常量池会储存在Method Area（方法区域）中，而不是堆中。
一个JVM实例只存在一个堆内存，堆内存的大小是可以调节的。类加载器读取了类文件后，需要把类、方法、常变量放到堆内存中，以方便执行器执行。堆内存分为3部分。
（1）永久存储区（Permanent Space）。
永久存储区是一个常驻内存区域，用于存放JDK自身所携带的Class Interface的元数据。也就是说，它存储的是运行环境必须的类信息，被装载进此区域的数据是不会被垃圾回收器回收掉的，关闭JVM才会释放此区域所占用的内存。
（2）新生区（Young Generation Space）。
新生区是类的诞生、成长、消亡的区域，一个类在这里产生、应用，最后被垃圾回收器收集，结束生命。新生区又分为伊甸区（Eden space）和幸存者区（Survivor pace）两部分。所有的类都是在伊甸区被new（新建）出来的；幸存区有两个：0区（Survivor 0 space）和1区（Survivor 1 space）。当伊甸园的空间用完时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收，将伊甸园区中不再被其他对象所引用的对象进行销毁，然后将伊甸园中的剩余对象移动到幸存0区。若幸存0区也满了，再对该区进行垃圾回收，然后移动到1区。那如果1区也满了呢？再移动到养老区。
（3）养老区（Tenure Generation Space）。
养老区用于保存从新生区筛选出来的Java对象，一般池对象都在这个区域活跃。
上述3个区的示意图如图2-7所示。
2.5.2 运行时的数据区域
Java通过自身的动态内存分配和垃圾回收机制，可以使Java程序员不用像C++程序员那么头疼内存的分配与回收。对于这一点来说，相信熟悉COM机制的朋友对于引用计数管理内存的方式深有感触。通过Java虚拟机的自动内存管理机制，不仅降低了编码的难度，而且不容易出现内存泄露和内存溢出的问题。但是这过于理想的愿望正是由于把内存的控制权交给了Java虚拟机，一旦出现内存泄露和溢出，我们就必须翻过Java虚拟机自动内存管理这堵高墙去排查错误。
根据《Java虚拟机规范》的规定，Java虚拟机在执行Java程序时，即运行环境下会把其所管理的内存划分为几个不同的数据区域。有的区域伴随虚拟机进程的启动而创建，死亡而销毁；有些区域则是依赖用户线程的启动时创建，结束时销毁。所有线程共享方法区和堆，虚拟机栈、本地方法栈和程序计数器是线程隔离的数据区。Java虚拟机运行时的数据区结构如图2-8所示。
2.5.3 对象访问
JVM的逻辑内存模型如图2-9所示。
当建立一个对象时如何进行访问呢？在Java 语言中，对象访问是如何进行的？对象访问在Java语言中无处不在，是最普通的程序行为，但即使是最简单的访问，也会涉及Java栈、Java 堆、方法区这3个最重要内存区域之间的关联关系，如下面的代码：
Object obj = new Object();
假设这句代码出现在方法体中，那“Object obj”这部分的语义将会反映到Java栈的本地变量表中，作为一个reference类型数据出现。而“new Object()”这部分的语义将会反映到Java堆中，形成一块存储了Object类型所有实例数据值（Instance Data，对象中各个实例字段的数据）的结构化内存，根据具体类型以及虚拟机实现的对象内存布局（Object Memory Layout）的不同，这块内存的长度是不固定的。另外，在Java堆中还必须包含能查找到此对象类型数据（如对象类型、父类、实现的接口、方法等）的地址信息，这些类型数据则存储在方法区中。
由于reference类型在Java虚拟机规范中只规定了一个指向对象的引用，并没有定义这个引用应该通过哪种方式去定位，以及访问到Java堆中的对象的具体位置，因此不同虚拟机实现的对象访问方式会有所不同，主流的访问方式有使用句柄和直接指针两种。
（1）如果使用句柄访问方式，Java 堆中将会划分出一块内存来作为句柄池，reference中存储的就是对象的句柄地址，而句柄中包含了对象实例数据和类型数据各自的具体地址信息，如图2-10所示。
（2）如果使用直接指针访问方式，Java 堆对象的布局中就必须考虑如何放置访问类型数据的相关信息，reference中直接存储的就是对象地址，如图2-11所示。
这两种对象的访问方式各有优势，使用句柄访问方式的最大好处就是reference中存储的是稳定的句柄地址，在对象被移动（垃圾收集时移动对象是非常普遍的行为）时只会改变句柄中的实例数据指针，而reference 本身不需要被修改。
使用直接指针访问方式的最大好处就是速度更快，它节省了一次指针定位的时间开销，由于对象的访问在Java中非常频繁，因此这类开销积少成多后也是一项非常可观的执行成本。从整个软件开发的范围来看，各种语言和框架使用句柄来访问的情况也十分常见。
2.5.4 内存泄露
在计算机科学中，内存泄漏（Memory Leak）是指由于疏忽或错误造成程序未能释放已经不再使用的内存的情况。内存泄漏并非指内存在物理上的消失，而是应用程序分配某段内存后，由于设计错误，失去了对该段内存的控制，因而造成了内存的浪费。内存泄漏与许多其他问题有着相似的症状，并且通常情况下只能由那些可以获得程序源代码的程序员才可以分析出来。然而，有不少人习惯于把任何不需要的内存使用的增加描述为内存泄漏，严格意义上来说这是不准确的。一般常说的内存泄漏是指堆内存的泄漏。堆内存是指程序从堆中分配的、大小任意的（内存块的大小可以在程序运行期决定）、使用完后必须显式释放的内存。应用程序一般使用malloc、realloc、new等函数从堆中分配到一块内存，使用完后，程序必须负责相应的调用free或delete释放该内存块，否则这块内存就不能被再次使用，一般就说这块内存泄漏了。
通常可以将内存泄露分为以下4类。
（1）常发性内存泄漏。
发生内存泄漏的代码会被多次执行到，每次被执行的时候都会导致一块内存泄漏。
（2）偶发性内存泄漏。
发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生，常发性和偶发性是相对的。对于特定的环境，偶发性的也许就变成了常发性的。因此测试环境和测试方法对检测内存泄漏至关重要。
（3）一次性内存泄漏。
发生内存泄漏的代码只会被执行一次，或者由于算法上的缺陷，导致总会有一块且仅一块内存发生泄漏。比如，在一个Singleton类的构造函数中分配内存，在析构函数中却没有释放该内存。而Singleton类只存在一个实例，所以内存泄漏只会发生一次。
（4）隐式内存泄漏。
程序在运行过程中不停地分配内存，但是直到结束的时候才释放内存。严格地说，这里并没有发生内存泄漏，因为最终程序释放了所有申请的内存。但是对于一个服务器程序，需要运行几天、几周甚至几个月，不及时释放内存也可能导致最终耗尽系统的所有内存。因此，称这类内存泄漏为隐式内存泄漏。
2.5.5 JVM的垃圾收集策略
GC执行时要耗费一定的CPU资源和时间，因此在JDK1.2以后，JVM引入了分代收集的策略，其中对新生代采用“Mark-Compact“策略，而对老生代采用了“Mark-Sweep"的策略。其中新生代的垃圾收集器命名为“minor gc”，老生代的GC命名为“Full Gc”或“Major GC”。其中用System.gc()强制执行的是Full Gc。
1．Serial Collector
Serial Collector是指任何时刻都只有一个线程进行垃圾收集，这种策略有一个名字“stop the whole world”，它需要停止整个应用的执行。这种类型的收集器适合于单CPU的机器。
Serial Copying Collector
此种GC用-XX:UseSerialGC选项配置，它只用于新生代对象的收集。1.5.0以后-XX:Max TenuringThreshold来设置对象复制的次数。当eden空间不够时，GC会将eden的活跃对象和一个名叫From survivor空间中尚不够资格放入Old代的对象复制到另外一个名字叫To Survivor的空间。而此参数就是用来说明到底From survivor中的哪些对象不够资格，假如这个参数设置为31，那么也就是说只有对象复制31次以后才算是有资格的对象。
From Survivor和To Survivor的角色是不断变化的，同一时间只有一块空间处于使用状态，这个空间就叫做From Survivor区，当复制一次后角色就发生了变化。
如果复制的过程中发现To Survivor空间已经满了，那么就直接复制到Old Generation。
比较大的对象也会直接复制到Old Generation，在开发中，应该尽量避免这种情况的发生：
Serial Mark-Compact Collector
串行的标记-整理收集器是JDK5 update 6之前默认的老生代的垃圾收集器，此收集使得内存碎片最少化，但是它需要暂停的时间比较长
2．Parallel Collector
Parallel Collector主要是为了应对多CPU，大数据量的环境。Parallel Collector又可以分为以下两种。
（1）Parallel Copying Collector：此种GC用-XX:UseParNewGC参数配置，它主要用于新生代的收集，此GC可以配合CMS一起使用。
（2）在1.4.1版本以后用：
Parallel Mark-Compact Collector
此种GC用-XX:UseParallelOldGC参数配置，此GC主要用于老生代对象的收集。1.6.0后用：
Parallel scavenging Collector
此种GC用-XX:UseParallelGC参数配置，它是对新生代对象的垃圾收集器，但是它不能和CMS配合使用，它适合于比较大新生代的情况，此收集器起始于jdk 1.4.0。它比较适合于对吞吐量高于暂停时间的场合。
3．Concurrent Collector
Concurrent Collector通过并行的方式进行垃圾收集，这样就减少了垃圾收集器收集一次的时间，这种GC在实时性要求高于吞吐量的时候比较有用。此种GC可以用参数-XX:UseConcMarkSweepGC配置，此GC主要用于老生代和Perm代的收集。
2.5.6 垃圾收集器
如果说收集算法是内存回收的方法论，垃圾收集器就是内存回收的具体实现。Java虚拟机规范中对垃圾收集器应该如何实现并没有任何规定，因此不同的厂商、不同版本的虚拟机所提供的垃圾收集器都可能会有很大的差别，并且一般都会提供参数供用户根据自己的应用特点和要求组合出各个年代所使用的收集器。这里讨论的收集器基于Sun HotSpot虚拟机1.6版 Update 22，这个虚拟机包含的所有收集器如图2-12所示。
图2-12展示了7种作用于不同分代的收集器（包括JDK 1.6_Update14后引入的Early Access版G1收集器），如果两个收集器之间存在连线，就说明它们可以搭配使用。
在介绍这些收集器各自的特性之前，先来明确一个观点：虽然是在对各个收集器进行比较，但并非为了挑选一个最好的收集器出来。因为直到现在为止还没有最好的收集器出现，更加没有万能的收集器，所以本书选择的只是对具体应用最合适的收集器。这点不需要多加解释就能证明：如果有一种放之四海皆准、任何场景下都适用的完美收集器存在，那HotSpot虚拟机就没必要实现那么多不同的收集器了。
