内存管理
运行时的数据区包括：
程序计数器
一块较小的内存空间，可以看作是当前线程所执行的字节码的行号指示器。
每个下次都需要有一个独立的程序计数器，各线程间计数器互不影响，独立存储。
如果线程执行的饿是一个Java方法，计数器记录的是正在执行的虚拟机字节码指令的地址；如果执行的是Native方法，计数器值则为空。此内存区域是唯一一个Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。
Java虚拟机栈
虚拟机栈描述的是Java方法执行的内存模型：每个方法在执行的同时都会创建一个栈帧用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程。
局部变量表存放了编译器可知的各种基本数据类型（boolean, byte, char, short, int, float, long, double）、对象引用（reference类型，它不等同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄（这里的句柄似乎与引用不是同一个意思，这在之后的“对象访问定位”再深究吧）或其他与此对象相关的位置）和returnAddress类型（指向了一个字节码指令的地址）。
局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。
在Java虚拟机规范中，对这个区域规定了两种异常情况：如果线程请求的栈深度大于虚拟机所允许的深度，则抛出StackOverflowError异常；如果虚拟机栈可以动态拓展，如果拓展时无法申请到足够的内存，则抛出OutOfMemoryError异常。
本地方法栈
本地方法栈（Native Method Stack）与虚拟机栈的区别是虚拟机栈为虚拟机执行Java方法（字节码）服务，而本地方法栈则为虚拟机使用到的Native方法服务。
在Java虚拟机规范中对本地方法栈中方法使用的语言、使用方式与数据结构并没有强制规定，因此具体的虚拟机可以自由实现它。甚至有的虚拟机，譬如Sun HotSpot虚拟机直接合二为一。
与虚拟机栈一样，这个区域也会抛出StackOverflowError和OutOfMemoryError异常（Error和Exception的父类是Throwable，这里叫异常不知道是否合适）。
堆（线程共享）
在虚拟机启动时创建，此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例在这里分配。（随着JIT编译器的发展与逃逸分析技术的逐渐成熟，有的对象是在栈中分配的，见后面章节）
Java堆是垃圾收集器管理的主要区域，细分为新生代和老年代。
新生代分为Eden空间，From Survivor空间、To Survivor空间（现在商业虚拟机都采用“复制”的垃圾收集算法来回收新生代。），老年代为Tenured空间。
根据Java虚拟机规范，Java堆可以处于物理上不连续的内存空间中，只要逻辑上是连续的即可。
如果在堆中没有内存完成实例分配，并且堆也无法再拓展时，将会抛出OutOfMemoryError异常。
方法区（线程共享）
用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。别名Non-Heap。
在HotSpot虚拟机上，HotSpot设计团队使用永久代来实现方法区，这样HotSpot的垃圾收集器可以像管理Java堆一样管理这部分内存，能够省去专门为方法区编写内存管理代码的工作。所以很多人称这个区为永久区。事实上对其他虚拟机如BEA JRockit、IBM J9等，是不存在永久代的概念的。
现在看来，使用永久代来实现方法区并不是一个好的方法，这样更容易遇到内存溢出问题（不太懂）。因此，根据HotSpot官方发布的路线图信息，现在也有放弃永久代并逐步改为采用Native Memory来实现方法区的规划了。在JDK 1.7的HotSpot中，已把原来放在永久代的字符串常量池移出。
这区域的内存回收目标主要是针对常量池的回收和对类型的卸载，一般来说，这个区域的回收成绩比较难令人满意，但回收确实有必要。
当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。
运行时常量池
运行时常量池是方法区的一部分。Class文件除了有类的版本、字段、方法、接口等描述信息外，还有常量池（Constant Pool Table），用于存放编译期生成的各种字面量和符号引用，这部分内容在类加载后进入方法区的运行时常量池中存放。
运行时常量池具有动态性，Java语言并不要常量一定只有编译期才能产生，运行期间也可能讲新的常量放入池中，如String类的intern()方法。
当常量池无法再申请到内存时会抛出OutOfMemoryError异常。
垃圾收集算法
标记-清除算法
最基础的收集算法。
首先标记出所有需要回收的对象，在标记完成后统一回收。
主要不足：
效率问题，标记和清楚两个过程效率都不高空间问题，标记清楚后会产生大量不连续的内存碎片，空间碎屏太多可能导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前出发另一次垃圾收集动作。
复制算法
相对标记-清除算法，复制算法解决了效率问题。
将可用内存按容量划分为大小相等的两块，每次只使用其中一块，当这块内存用完后，就将还存活的对象复制到另外一块上面，然后再已使用过的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效，代价是将内存缩小为原来的一半。
现在在商业虚拟机都是用这种收集算法来处理新生代的，IBM公司专门研究表明，在新生代中的对象98%都是“朝生夕死”的。所以不需要1：1来分配内存。只需要用一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden空间和一块Survivor，垃圾回收时，把存活的对象一次性复制到另一块Survivor空间，然后清理掉Eden和Survivor空间即可。HotSpot默认Eden和Survivor的大小比例是8：1（参数 SurvivorRatio），也就是只有10%的被浪费。当Survivor空间不够时，就需要放进老年代了。
标记-整理算法
复制对象算法如果在对象存活较多时因为需要进行较多的复制操作，效率会变低（所以用在新生代）。而且如果不想浪费太多空间（即设置小一点的Survivor），就需要有额外的空间进行担保（当新生代的Survivor空间不够时，就需要放进老年代），所以在老年代不能使用这种算法。
根据老年代的特点，有人提出了“标记-整理”算法。先标记，然后让所有存活对象向一端移动，然后清理掉端边界以外的内存。
总结
当前商业虚拟机都是采用分代收集的策略。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存货，那就用复制算法，只需要付少量存活对象的复制成本就可以完成收集。而老年代因为对象存活率高、没有额外空间进行分配担保，就必须要用另外两种算法了。
具体实现有的复杂，没看太懂，看懂了再放上来吧
如何判断对象是否存活
最简单的是用引用计数器。给每个对象添加一个引用计数器，当有地方引用，就加一；引用失效，减一。0则表示对象不可能再被使用。
这样似乎实现简单，也挺高效，但没有考虑循环引用的问题。
比如有这样的代码：
class LoopRef{public Object instance=null;}LoopRef lrA=new LoopRef();LoopRef lrB=new LoopRef();lrA.instance=lrB;lrB.instance=lrA;lrA=null;lrB=null;System.gc();
如果用引用计数器的方法，是无法回收这两个对象的。但其实我们已经不可能再访问到这两个对象了。
目前主流是通过可达性分析来判断对象是否存活。
这种方法是通过称为“GC Roots”的对象为起始点，从这些点搜索其引用的对象，搜索所走过的路径成为引用链，当一个对象到GC Roots没有任何引用链相连时，则证明此对象不可用。
在Java中，可作为GC Roots的对象包括：
虚拟机栈中引用的对象方法区中静态属性引用的对象方法区中常量引用的对象本地方法栈中Java Native Interface（Native方法）引用的对象。
但是要宣告一个对象的死亡，除了GC Roots不可达外，还需要判断其是否执行了finalize()方法， 若没有覆盖该方法或已经执行过一次，则判断为死亡。若覆盖了但未执行，那么这个对象会放置在一个叫做F-Queue的队列中，并在稍后由一个虚拟机创建的、低优先级的Finalizer去执行，但不会保证等待它运行结束。所以一个对象可以覆盖finalize()方法来进行一次自救（譬如把自己复制给某个变量），那么这个对象的回收将不在这一次GC，而是下一次。
但是finalize()是尽量避免使用的，因为这是Java当时为了让C/C++程序员更容易接受而做的一个妥协，Java不需要析构函数，这些工作由虚拟机自动执行。且这个方法运行代价高，不确定性大。像那些关闭资源的工作，放到finally即可。
