java 内存分区
JVM所管理的内存分为以下几个运行时数据区：程序计数器、Java虚拟机栈、本地方法栈、Java堆、方法区。
程序计数器(Program Counter Register)
一块较小的内存空间，它是当前线程所执行的字节码的行号指示器，字节码解释器工作时通过改变该计数器的值来选择下一条需要执行的字节码指令，分支、跳转、循环等基础功能都要依赖它来实现。每条线程都有一个独立的的程序计数器，各线程间的计数器互不影响，因此该区域是线程私有的。
当线程在执行一个Java方法时，该计数器记录的是正在执行的虚拟机字节码指令的地址，当线程在执行的是Native方法（调用本地操作系统方法）时，该计数器的值为空。另外，该内存区域是唯一一个在Java虚拟机规范中么有规定任何OOM（内存溢出：OutOfMemoryError）情况的区域。
Java虚拟机栈（Java Virtual Machine Stacks）
该区域也是线程私有的，它的生命周期也与线程相同。虚拟机栈描述的是Java方法执行的内存模型：每个方法被执行的时候都会同时创建一个栈帧，栈它是用于支持续虚拟机进行方法调用和方法执行的数据结构。对于执行引擎来讲，活动线程中，只有栈顶的栈帧是有效的，称为当前栈帧，这个栈帧所关联的方法称为当前方法，执行引擎所运行的所有字节码指令都只针对当前栈帧进行操作。栈帧用于存储局部变量表、操作数栈、动态链接、方法返回地址和一些额外的附加信息。在编译程序代码时，栈帧中需要多大的局部变量表、多深的操作数栈都已经完全确定了，并且写入了方法表的Code属性之中。因此，一个栈帧需要分配多少内存，不会受到程序运行期变量数据的影响，而仅仅取决于具体的虚拟机实现。
本地方法栈（Native Method Stacks）
该区域与虚拟机栈所发挥的作用非常相似，只是虚拟机栈为虚拟机执行Java方法服务，而本地方法栈则为使用到的本地操作系统（Native）方法服务。
Java堆（Java Heap）
Java Heap是Java虚拟机所管理的内存中最大的一块，它是所有线程共享的一块内存区域。几乎所有的对象实例和数组都在这类分配内存。Java Heap是垃圾收集器管理的主要区域，因此很多时候也被称为“GC堆”。
根据Java虚拟机规范的规定，Java堆可以处在物理上不连续的内存空间中，只要逻辑上是连续的即可。如果在堆中没有内存可分配时，并且堆也无法扩展时，将会抛出OutOfMemoryError异常。
方法区（Method Area）
方法区也是各个线程共享的内存区域，它用于存储已经被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。方法区域又被称为“永久代”，但这仅仅对于Sun HotSpot来讲，JRockit和IBM J9虚拟机中并不存在永久代的概念。Java虚拟机规范把方法区描述为Java堆的一个逻辑部分，而且它和Java Heap一样不需要连续的内存，可以选择固定大小或可扩展，另外，虚拟机规范允许该区域可以选择不实现垃圾回收。相对而言，垃圾收集行为在这个区域比较少出现。该区域的内存回收目标主要针是对废弃常量的和无用类的回收。运行时常量池是方法区的一部分，Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池（Class文件常量池），用于存放编译器生成的各种字面量和符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。运行时常量池相对于Class文件常量池的另一个重要特征是具备动态性，Java语言并不要求常量一定只能在编译期产生，也就是并非预置入Class文件中的常量池的内容才能进入方法区的运行时常量池，运行期间也可能将新的常量放入池中，这种特性被开发人员利用比较多的是String类的intern（）方法。
JVM 垃圾回收器
垃圾回收器的类型大概有以下几种：
串行回收(Serial)和并行回收(Parallel)：串行回收就是不过有多少个CPU，始终只用一个CPU来执行垃圾回收操作，而并行回收就是把整个回收工作拆分成多个部分，每个部分由一个CPU来负责，从而让多个CPU并行回收，并行回收的执行效率很高，但是复杂度增加，另外一个使内存碎片会增加。
并发执行和应用程序停止：应用程序停止的垃圾回收方式会在执行垃圾回收的同时导致应用程序的暂停，并发执行的垃圾回收虽然不会导致应用程序的暂停，但是由于并发执行垃圾回收需要解决和应用程序的执行冲突(应用程序可能会在垃圾回收过程中修改对象），因此，可能执行开销比应用程序停止更高，而且执行时也需要更多的内存。
压缩和不压缩：为了减少内存碎片，支持压缩的垃圾回收器会把所有的获得对象搬迁到一起，然后边界之前的占用内存全部回收。优点是：解决了内存碎片问题。缺点是速度较慢。
不压缩的垃圾回收方式：回收速度快，但分配内存慢，且无法解决内存碎片问题。
新生代和老年代
垃圾回收算法大概可分为以下几种算法
复制式的垃圾回收：把可达的对象复制到另外一个区域，再对这个区域另外清楚，回收过程不会长生内存碎片，但是需要复制数据和额外的内存。
标记-清除：先遍历一次，可达的标为可达，然后再遍历一次，把没标记为可达的进行回收。
标记-整理：从根开始访问，标可达，再遍历，把可达的复制到一起，回收不可达的内存 分代回收：按对象的存活时间，我们知道java的 大多数对象存活时间比较短，分为三个代，按代回收。
现代垃圾回收器设计思想
现行的垃圾回收器采用分代的方式来采用不用的回收设计，分代的基本思路是根据对象生存时间的长短，把堆内存分成3个代：
Young(年轻代):由1个Eden区和2个Survior构成，绝大多数对象先分配到Eden区中，当垃圾回收机制来临的时候，会把Eden去还存活的对象复制到survior区（其中一个），当surivior区满的时候，会把surivior还存活的对象存放到另外一个survior去中，当这个survior去也满的时候，会把从第一个survior区复制过来还存活的对象存放到老年代
Old(年老代）:在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代中，因此可以说存放生命周期比较长的对象
Permanent(永久代): 用于存放静态文件，如今Java类、方法等。持久代对垃圾回收没有显著影响持久代大小通过-XX:MaxPermSize=
GC 的两种类型
GC有两种类型：Scavenge GC和Full GC。
Scavenge GC：一般情况下，当新对象生成，并且在Eden申请空间失败时，就会触发Scavenge GC，对Eden区域进行GC，清除非存活对象，并且把尚且存活的对象移动到Survivor区。然后整理Survivor的两个区。这种方式的GC是对年轻代的Eden区进行，不会影响到年老代。因为大部分对象都是从Eden区开始的，同时Eden区不会分配的很大，所以Eden区的GC会频繁进行。因而，一般在这里需要使用速度快、效率高的算法，使Eden去能尽快空闲出来。一般使用复制算法。
Full GC：对整个堆进行整理，包括Young、Tenured和Perm。Full GC因为需要对整个对进行回收，所以比Scavenge GC要慢，因此应该尽可能减少Full GC的次数。在对JVM调优的过程中，很大一部分工作就是对于FullGC的调节。有如下原因可能导致Full GC：
- 年老代（Tenured）被写满
- 持久代（Perm）被写满
- System.gc()被显示调用
- 上一次GC之后Heap的各域分配策略动态变化
对象如何实现自我救赎
我们知道要宣告一个对象死亡，至少需要两次标记。 第一次标记会从GC Root对象开始遍历，看是否存在相应的引用链，如果没有的话，那么 它 会被第一次标志并且进行第一次筛选，判断是否有必要执行筛选的条件是 是否覆盖了 Finalize（）方法 ，覆盖了，有必要执行，没覆盖，没必要执行 finilize方法 是否被虚拟机调用 过，没有的话，有覆盖finalize方法，执行筛选 如果这个对象 被判定有必要执行 finalize方法 ，会把它放到F-Queue的队列当中 ，随后jvm会启动一个低优先级的线程来执行，如果在执行finalize 方法的 时候该对象有引用指向它，那么它可以实现自我救赎。
类加载过程
类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括加载、验证、准备、解析、初始化、使用、卸载。
其中类加载的过程包括了加载、验证、准备、解析、初始化五个阶段。在这五个阶段中，加载、验证、准备和初始化这四个阶段发生的顺序是确定的，而解析阶段则不一定，它在某些情况下可以在初始化阶段之后开始，这是为了支持Java语言的运行时绑定（也成为动态绑定或晚期绑定）。另外注意这里的几个阶段是按顺序开始，而不是按顺序进行或完成，因为这些阶段通常都是互相交叉地混合进行的，通常在一个阶段执行的过程中调用或激活另一个阶段。
“加载”(Loading)阶段是“类加载”(Class Loading)过程的第一个阶段，在此阶段，虚拟机需要完成以下三件事情：
- 通过一个类的全限定名来获取定义此类的二进制字节流。
- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
- 在Java堆中生成一个代表这个类的java.lang.Class对象，作为方法区这些数据的访问入口。
验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
准备阶段是为类的静态变量分配内存并将其初始化为默认值，这些内存都将在方法区中进行分配。准备阶段不分配类中的实例变量的内存，实例变量将会在对象实例化时随着对象一起分配在Java堆中。
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。
类初始化是类加载过程的最后一步，前面的类加载过程，除了在加载阶段用户应用程序可以通过自定义类加载器参与之外，其余动作完全由虚拟机主导和控制。到了初始化阶段，才真正开始执行类中定义的Java程序代码。
双亲委托机制
双亲委派模型：Bootstrap ClassLoader、Extension ClassLoader、ApplicationClassLoader。
- 启动类加载器，负责将存放在
\lib目录中的，或者被-Xbootclasspath参数所指定的路径中，并且是虚拟机识别的（仅按照文件名识别，如rt.jar，名字不符合的类库即时放在lib目录中也不会被加载）类库加载到虚拟机内存中。启动类加载器无法被java程序直接引用。 - 扩展类加载器：负责加载
\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用该类加载器。 - 应用程序类加载器：负责加载用户路径上所指定的类库，开发者可以直接使用这个类加载器，也是默认的类加载器。 三种加载器的关系：启动类加载器->扩展类加载器->应用程序类加载器->自定义类加载器。
这种关系即为类加载器的双亲委派模型。其要求除启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系一般不以继承关系实现，而是用组合的方式来复用父类的代码。
双亲委派模型的工作过程：如果一个类加载器接收到了类加载的请求，它首先把这个请求委托给他的父类加载器去完成，每个层次的类加载器都是如此，因此所有的加载请求都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它在搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。
好处：java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar中，无论哪个类加载器要加载这个类，最终都会委派给启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果用户自己写了一个名为java.lang.Object的类，并放在程序的Classpath中，那系统中将会出现多个不同的Object类，java类型体系中最基础的行为也无法保证，应用程序也会变得一片混乱。
实现：在java.lang.ClassLoader的loadClass()方法中，先检查是否已经被加载过，若没有加载则调用父类加载器的loadClass()方法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父加载失败，则抛出ClassNotFoundException异常后，再调用自己的findClass()方法进行加载。