一，java技术体系
*Java程序设计语言
* 各种硬件平台上的Java虚拟机
* Class文件格式
* Java API类库
* 来自商业机构和开源社区的第三方Java类库
Java程序设计语言、Java虚拟机、JavaAPI类库统称为JDK(Java Development Kit), JDK是用于支持Java程序开发的最小环境。
Java API类库中的Java SE API子集 和 Java虚拟机这两部分统称为JRE(Java Runtime Environment), JRE是支持Java程序运行的标准环境。
按照Java技术关注的重点业务领域来划分，Java技术体系可以分为四个平台:
* Java Card : 支持一些Java小程序（Applets）运行在小内存设备（如智能卡）上的平台
* Java ME(Micro Edition):支持Java程序运行在移动终端（手机、PDA）上的平台，对Java API有所精简，并加入了针对移动终端的支持，这个版本以前称为J2ME.
* Java SE(Standard Edition):支持面向桌面级应用（如Windows下的应用程序）的Java平台，提供了完整的Java核心API,这个版本以前称为J2SE.
* Java EE(Enterprise Edition):支持使用多层架构的企业应用（如ERP、CRM应用）的Java平台，除了提供Java SE API外，还对其做了大量的扩充并提供了相关的部署支持，这个版本以前称为J2EE。
注：Java EE中的扩展一般以javax.*作为包名，而以java.*为包名的包都是Java SE API的核心包，但由于历史原因，一部分曾经是扩展包的API后来进入了核心包，因此核心包中也包含了不少javax.*的包名。
二，运行时数据区域
Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。 方法区（Method Area）、虚拟机栈（VM Stack）、本地方法栈（Native Method Stack）、堆（Heap）、程序计数器（Program Couter Register）。
1. 程序计数器是一块较小的内存空间，它的作用可以看作是当前线程所执行的字节码的行号指示器。字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令。
Java虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的。为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各个线程之间的计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。
注：如果线程正在执行的是一个Java方法，这个计数器记录的是正在执行的虚拟机字节码指令的地址：如果正在执行的是Native方法，这个计数器值则为空（Undefined）.
注：此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。
2.Java虚拟器栈（Java Virtual Machine Stacks）
Java虚拟机栈也是线程私有的。生命周期与线程相同，Java虚拟机栈描述的是Java方法执行的内存模型：每个方法被执行的时候都会同时创建一个栈帧（Stack Frame），用于存储局部变量表、操作栈、动态链接、方法出口等信息。
每个方法被调用直至执行完成的过程，就对应着一个栈帧在虚拟机中从入栈到出栈的过程。
局部变量表存放了编译器可知的各种基本数据类型、对象引用（可能是一个指向对象起始地址的引用指针）和returnAddress类型(指向一条字节码指令的地址)。
局部变量表所需的内存空间在编译期间完成分配，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。
Java虚拟器规范中，对这个区域规定了两种异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；如果虚拟机栈可以自动扩展，当扩展时无法申请到足够的内存时会抛出OutOfMemoryError异常。
3.本地方法栈（Native Method Stacks）
本地方法栈与虚拟机栈所发挥的作用非常类似。区别在于虚拟机栈为虚拟机执行Java方法（也就是字节码）服务，而本地方法栈是为虚拟机使用到的Native方法服务的。
本地方法栈也会抛出StackOverflowError和OutOfMemoryError异常
4.Java堆
Java堆（Java Heap）是Java虚拟机所管理的内存中最大的一块。是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例。
Java虚拟机规范规定：所有的对象实例以及数组都要在堆上分配。
Java堆是垃圾收集器管理的主要区域，因此很多时候也被称为“GC堆”（Garbage Collected Heap）.
Java虚拟机规范规定，Java堆可以处于物理上不连续的内存空间中，只要逻辑上连续即可。
当前驻留的虚拟机都是按照可扩展来实现的（通过-Xmx 和 -Xms控制）。如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError异常。
5.方法区
方法区（Method Area）与Java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。
Java虚拟机规范规定，当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。
6.运行时常量池
运行时常量池（Runtime Constant Pool）是方法区的一部分。Class文件中除了有类的版本、字段、方法、接口等描述信息外，还有一项信息是常量池（Constant Pool Table），用于存放编译期生成的各种字面量和符号引用。这部分内容将在类加载后存放到方法区的运行时常量池中。
运行时常量池相对于Class文件常量池的另外一个重要特征是具备动态性，不仅Class文件中的常量池的内容可以进入方法区运行时常量池，运行期间也可能将新的常量放入池中。
7.直接内存
直接内存（Direct Memory）并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范汇总定义的内存区域，例如, JDK1.4引入的NIO类，引入了基于通道（Channel）与缓冲区（Buffer）的I/O方式，它可以使用Native函数库直接分配堆外内存，然后通过一个存储在Java堆里面的DirectByteBuffer对象作为这块内存的引用进行操作。
注意：直接内存虽然不包含在堆内存中，但是它也是一块需要的内存区域，因此，在计算各个内存区域总和的时候要计算在内。
三、对象访问
对于Object obj = new Object();
"Object obj"这部分的语义将会反映到Java栈的本地变量表中，作为一个reference类型数据出现。
new Object()”这部分语义将会反映到Java堆中，形成一块存储了Object类型所有实例数据值的结构化内存。
由于reference类型在Java虚拟机规范里面只规定了一个指向对象的引用，因此不同的虚拟机实现会有不同的实现对象访问的方式，主流的访问方式有两种：使用句柄 和直接指针。
3.1使用句柄
使用该方式，Java堆中将会划分出一块内存来作为句柄池，reference中存储的就是对象的句柄地址，而句柄中存对象实例数据和类型数据的具体地址信息。如上图2。
3.2使用指针
reference中直接存储的就是对象地址；
句柄访问方式最大的好处是reference中存储的是稳定的句柄地址，在对象被移动时只会改变句柄中的实例数据指针，而reference本身不需要被修改。
直接指针访问方式的最大好处就是速度更快，它节省了一次指针定位的时间开销。Sun HotSpot虚拟机是使用第二种方式的。
4.实战：OutOfMemoryError异常
1、Java堆的溢出
通过指定VM Args参数，可以设置虚拟机的启动参数。-Xms参数指定堆的最小值， -Xmx参数指定堆的最大值，通过参数-XX:+HeapDumpOnOutOfMemoryError可以让虚拟机在出现内存溢出异常时Dump出当前的内存堆转储文件以便后续分析。
例如，在VM Arg参数中指定：-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:SurvivorRatio=8 -XX:+HeapDumpOnOutOfMemoryError
可以将堆的大小设置为20M(将堆的最小值-Xms参数与最大值-Xmx参数设置为一样即可避免堆自动扩展)，并导出Dump文件
如下程序：
2.虚拟机栈和本地方法栈溢出
VM Arg中 -Xoss参数可以设置本地方法栈大小（由于HotSpot虚拟机中并不区分虚拟机栈和本地方法栈，因此-Xoss参数是无效的），-Xss参数指定虚拟机栈的大小
关于虚拟机栈和本地方法栈，有两种可能的异常：StackOverflowError和OutOfMemoryError异常。
实验表明：在单个线程下，无论是由于栈帧太大，还是虚拟机栈容量太小，当内存无法分配时，虚拟机都会抛出StackOverflowError异常，不会抛出OutOfMemoryError异常。
注意：如果是建立过多线程导致的内存溢出，在不能减少线程数或者更换64位虚拟机的情况下，就只能通过减少最大堆和减少栈容量来换取更多的线程。
3.运行时常量池溢出（运行时常量池属于方法区方法区溢出）
常量池分配在方法区。通过-XX:PermSize和-XX:MaxPermSize可以限制方法区的大小，从而间接限制其中常量池的容量。
4.方法区溢出
方法区用于存放Class的相关信息，如类名、访问修饰符、常量池、字段描述、方法描述等。对这个区域的测试，基本思路是运行时产生大量的类去填满方法区，直到溢出。
CGLib (Code Generation Library) 是一个强大的,高性能,高质量的Code生成类库。它可以在运行期扩展Java类与实现Java接口。Hibernate用它来实现PO字节码的动态生成。CGLib 比 Java 的 java.lang.reflect.Proxy 类更强的在于它不仅可以接管接口类的方法，还可以接管普通类的方法。
CGLib 的底层是Java字节码操作框架 —— ASM。
当前的很多主流框架，如Spring和Hibernate对类进行增强时，都会使用到CGLib这类字节码技术，增强的类越多，就需要越大的方法区来保证动态生成的Class可以加载如内存。
5.本地直接内存溢出
DirectMemory容量可通过-XX:MaxDirectMemorySize指定，如果不指定，则默认与Java堆的最大值（-Xmx指定）一样
五、垃圾回收器
垃圾收集（Garbage Collection, GC），可以回收堆上的对象，还可以回收方法区的“废弃常量”和“无用的类”。
1、判断对象是否存活
GC在对堆进行回收之前，第一件事就是确定哪些对象可以回收。
方案一：引用计数算法（Reference Counting）
过程是：给对象中添加一个引用计数器，每当有一个地方引用它时，计数器值就加1；当引用失效时，计数器值就减1；任何时刻计数器都为0的对象就是不可能再被使用的，可以回收。
引用计数方案最大的问题是：很难解决对象之间的相互循环引用的问题。当两个对象没有其他对象引用，只是它们之间相互引用对方，此时这两个对象已经不能再被访问，但是引用计数都不为0；
方案二：根搜索算法（GC Roots Tracing）
思路是：通过一系列的名为“GC Roots”的对象作为起始点，从这些节点开始向下搜素，搜索所走过的路径称为引用链（Reference Chain）,当一个对象到GC Roots没有任何引用链相连（用图论的话来说就是从GC Roots到这个对象不可达）时，则证明此对象是不可用的。
在Java语言里，可作为GC Roots的对象包括以下几种：
** 虚拟机栈（栈帧中的本地变量表）中的引用的对象
** 方法区中的类静态属性引用的对象
** 方法区中的常量引用的对象。
** 本地方法栈中JNI(即一般说的Native方法)的引用的对象。
2、引用
在JDK 1.2之前， Java中引用的定义时：如果reference类型的数据中存储的数值代表的是另外一块内存的起始地址，就称这块内存代表着一个引用。
在JDK1.2之后，Java对引用的概念进行了扩充，将引用分为强引用（Strong Reference）、软引用（Soft Reference）、弱引用（Weak Reference）、虚引用（Phantom Reference）四种。这四种引用强度依次逐渐减弱。
** 强引用，就是指在程序代码之中普遍存在的，类似“Object obj = new Object()”这类的引用，只要强引用存在，垃圾回收器永远不会回收掉被引用的对象。
** 软引用， 是指一些有用，但并非必需的对象，对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中并进行第二次回收。如果这次回收还是没有足够的内存，才会抛出内存溢出异常。
** 弱引用，被弱引用关联的对象只能生存到下一次垃圾收集发生之前。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。
** 虚引用，一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的就是希望能在这个对象被收集器回收时收到一个系统通知。
3、关于对象的死亡的二次标记
要真正宣告一个对象死亡，至少要经历两次标记过程：如果对象在进行根搜索后发现是不可达的，那么它将会被第一次标记并且进行一次筛选，筛选的条件是此对象是否有必要执行finalize()方法。当对象没有覆盖finalize()方法或者finalize()方法已经被虚拟机调用过，这两种情况将被视为“没有必要执行finalize()”。
如果一个对象被判定为有必要执行finalize()方法，那么这个对象将会被放置在一个名为F-Queue的队列中，并在稍后由一条由虚拟机自动建立的、低优先级的Finalizer线程去执行调用finalize()，稍后GC将对F-Queue中的对象进行第二次小规模的标记，如果对象在finalize()中又重新关联到了GC Roots对象，那么第二次标记时它将被移除出“即将回收”的集合，否则，对象将被回收。
任何一个对象的finalize()方法都只会被系统自动调用一次，第二次面临回收时，它的finalize()方法不会再被调用。
4、回收方法区
Java虚拟机规范中并没有要求必须在方法区实现垃圾回收，在方法区进行垃圾收集的“性价比”一般比较低：在堆中，常规应用进行一次垃圾回收一般可以回收70%~80%的空间，而代码区（永久代）的垃圾回收效率远低于此。
代码区回收的内容有：废弃常量和无用的类。
回收废弃常量的方法与回收堆中的对象非常类似，常量池中的其他类（接口）、方法、字段的符号引用也与此类似。
回收“无用的类”的条件是：同时满足以下3个条件的类才算是“无用的类”：
** 该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例
** 加载该类的ClassLoader已经被回收。
** 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
注：是否对类进行回收，HotSpot虚拟机提供了-Xnoclassgc参数进行控制，还可以使用-verbose:class及-XX:+TraceClassLoading、-XX:+TraceClassUnLoading查看类的加载和卸载信息。
六、垃圾回收算法
1、标记-清除算法
“标记-清除”算法是最基础的垃圾回收算法，之所以说它是最基础的收集算法，是因为后续的收集算法都是基于这种思路并对其缺点进行改进得到的。
该算法分为两个阶段：“标记”和“清除”，首先标记出所有需要回收的对象，然后在标记完成后统一回收掉所有被标记的对象。
主要缺点有两个： 一个是效率问题，标记和清除过程的效率都不高；另外一个是空间问题,标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致，当程序在以后的运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发另外一次垃圾回收动作。
2.复制算法
为了解决效率问题，出现了“复制”的收集算法。
思路是：将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。
优点是：内存分配时不用考虑内存碎片等复杂情况，实现简单，运行高效
缺点是：可利用的内存空间缩小为原来的一半，内存利用率低。
3.标记-整理算法（Mark-Compact）
复制收集算法在对象存活率较高时就要执行较多的复制操作，效率将会变低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保。
算法思路：标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。
4.分代收集算法（Generational Collection）
该算法只是根据对象存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适合的收集算法。新生代中，每次来及收集时都发现有大批对象死去，只有少量存活，就选用复制算法。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清理”或“标记-整理”算法来回收。
内存回收与垃圾收集器在很多时候都是影响系统性能、并发能力的主要因素之一，虚拟机之所以提供多种不同的收集器及大量的调节参数，是因为只有根据实际应用需求、实现方式选择最优的收集方式才能获取最好的性能。