BAT、网易、蘑菇街面试题整理-4
2016-04-05 23:46
645 查看
36. 设计模式：单例、工厂、适配器、责任链、观察者等等
http://www.cnblogs.com/maowang1991/archive/2013/04/15/3023236.html
大话设计模式
37. JNI的使用
Java通过JNI调用本地方法，而本地方法是以库文件的形式存放的（在Windows平台下是DLL文件形式，在UNIX机器上是SO文件形式）。通过调用本地的库文件的内部方法，使Java可以实现和本地机器的紧密联系，调用系统级的各接口方法
[java] view
plain copy
static {
System.loadLibrary(“testdll”);
}
这里库的扩展名可以不用写出来，究竟是DLL还是SO，由系统自己判断
2、还需要对将要调用的方法做本地声明，关键字为native。且只需要声明，而不需要具体实现
[java] view
plain copy
public native static void set(int i);
public native static int get();
得到的Java程序如下：TestJNI.java
[java] view
plain copy
public class TestJNI {
static {
System.loadLibrary("testdll");
}
public native static int get();
public native static void set(int i);
public static void main(String[] args) {
testdll test = new testdll();
test.set(10);
System.out.println(test.get());
}
}
3、使用javac TestJNI.java编译它，得到TestJNI.class
再用javah TestJNI，则会在当前目录下生成TestJNI.h文件
注意：用javah命令生成相应h头文件的时候有可能会出现无法找到相应class文件的错误，建议使用如下格式在控制台生成.h头文件
D:\>javah -classpath . testdll
[cpp] view
plain copy
#include <windows.h>
#include "TestJNI.h"
int i = 0;
JNIEXPORT jint JNICALL Java_testdll_get (JNIEnv *, jclass)
{
return i;
}
JNIEXPORT void JNICALL Java_testdll_set (JNIEnv *, jclass, jint j)
{
i = j;
}
int WINAPI DllMain (HINSTANCE hInstance, DWORD fdwReason, PVOID pvReserved)
{
return TRUE ;
}
说明：
（1）必须有DllMain函数，并且DllMain必须返回TRUE，否则系统将终止程序并弹出一个“启动程序时出错”对话框，其他两个为Java中调用的两个函数的实现，解释见最后的补充
（2）把Java编译生成的TestJNI.h加入到C/C++的工程中，否则上面代码的include "TestJNI.h"无法引用到
2、编译上面的testdll.cpp文件，可以生成testdll.dll文件，但是这过程通常会出现：在TestJNI.h中找不到jni.h
解决方法：把Javajdk中的下面这些.h文件复制一份到Microsoft Visual Studio的安装目录下的\VC\include文件夹下，例如笔者的是D:\Program Files\Microsoft Visual Studio 10.0\VC\include
[plain] view
plain copy
\jdk\include\jni.h
\jdk\include\win32\jawt_md.h
\jdk\include\win32\jni_md.h
2、然后把该dll文件拷贝到TestJNI.class文件的目录下。
3、使用java testdll 运行它，就可以观察到结果
说明：如果运行java testdll 出现错误:“ 找不到或无法加载主类”，可能是环境变量的classpath键值的分号；掉了，一般掉了这个就会出现这种问题
plain copy
/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class TestJNI*/
#ifndef _Included_TestJNI
#define _Included_TestJNI
#ifdef __cplusplus
extern "C" {
#endif
/*
* Class: TestJNI
* Method: get
* Signature: ()I
*/
JNIEXPORT jint JNICALL Java_TestJNI_get (JNIEnv *, jclass);
/*
* Class: TestJNI
* Method: set
* Signature: (I)V
*/
JNIEXPORT void JNICALL Java_TestJNI_set (JNIEnv *, jclass, jint);
#ifdef __cplusplus
}
#endif
#endif
在具体实现的时候，我们只关心两个函数原型
JNIEXPORT jint JNICALL Java_TestJNI_get (JNIEnv *, jclass); 和
JNIEXPORT void JNICALL Java_TestJNI_set (JNIEnv *, jclass, jint);
这里JNIEXPORT和JNICALL都是JNI的关键字，表示此函数是要被JNI调用的。而jint是以JNI为中介使JAVA的int类型与本地的int沟通的一种类型，我们可以视而不见，就当做int使用。函数的名称是JAVA_再加上java程序的package路径再加函数名组成的。参数中，我们也只需要关心在JAVA程序中存在的参数，至于JNIEnv*和jclass我们一般没有必要去碰它。
1. 内存模型以及分区，需要详细到每个区放什么。
一、JVM内存模型
JVM主要管理两种类型内存：堆(Heap)和非堆（Permanent区域）。
1、Heap是运行时数据区域，所有类实例和数组的内存均从此处分配。Heap区分两大块，一块是 Young Generation，另一块是Old Generation：
1）在Young Generation中，有一个叫Eden Space的空间，主要是用来存放新生的对象，还有两个Survivor Spaces（from,to），它们的大小总是一样，它们用来存放每次垃圾回收后存活下来的对象。
2）在Old Generation中，主要存放应用程序中生命周期长的内存对象。
2、Permanent区：
Permanent Generation，主要是存储的是java的类信息，包括解析得到的方法、属性、字段等等。永久带基本不参与垃圾回收。Permanent generation 不是Heap的一部。
.
二、内存大小
1、Heap内存分配
JVM初始分配的内存由-Xms指定，默认是物理内存的1/64；
JVM最大分配的内存由-Xmx指 定，默认是物理内存的1/4。
默认空余堆内存小于40%时，JVM 就会增大堆直到-Xmx 的最大限制，可以由 -XX:MinHeapFreeRatio 指定。
默认空余堆内存大于70%时，JVM 会减少堆直到-Xms的最小限制，可以由 -XX:MaxHeapFreeRatio 指定，
2、Permanent区域内存分配
JVM使用-XX:PermSize设置非堆内存初始值，默认是物理内存的1/64；
由XX:MaxPermSize设置最大非堆内存的大小，默认是物理内存的1/4。
三、JVM内存分配过程
1、JVM 会试图为相关Java对象在Eden中初始化一块内存区域。
2、当Eden空间足够时，内存申请结束；否则到下一步。
3、JVM 试图释放在Eden中所有不活跃的对象（这属于1或更高级的垃圾回收）。释放后若Eden空间仍然不足以放入新对象，则试图将部分Eden中活跃对象放入Survivor区。
4、Survivor区被用来作为Eden及Old的中间交换区域，当Old区空间足够时，Survivor区的对象会被移到Old区，否则会被保留在Survivor区。
5、当Old区空间不够时，JVM 会在Old区进行完全的垃圾收集（0级）。
6、完全垃圾收集后，若Survivor及Old区仍然无法存放从Eden复制过来的部分对象，导致JVM无法在Eden区为新对象创建内存区域，则出现”out of memory”错误。
堆里面的分区：Eden，survival from to，老年代，各自的特点。
java对象的创建过程：
对象的创建开始：
虚拟机遇到new 关键字的时候，首先去常量池中寻找有没有这个类的符号引用，并且检查该引用的类是否已经被加载，解析，和初始化过，如果没有则会先执行该类的加载过程， 在通过检查后，虚拟机为该新生对象分配内存。
分配内存：
为对象分配内存有俩种方式：
一种分配方式是“指针碰撞"，在内存规整的时候，已使用的内存在一侧，未使用的内存在一侧时，中间为指示器指针，这个时候的内存分配就是把指示器指针向未使用的区域移动至创建的对象大小相等的距离。
另一种分配方式是“空闲列表”,当内存不规整时，虚拟机必须在不连续的内存空间寻找一块适合对象大小的内存区域，并使用一个列表去维护创建的每一个区域，并更新列表上的记录。
选择那种分配方式是由堆内存是否规整决定，又由所采用的gc是否带有压缩整理功能决定。
当面临并发时时，有可能存在，虚拟机给对象A分配内存时指针还未来得及改变，这个时候同时又有B对象使用指针来分配内存解决这个问题的两种式：
一种是对分配内存空间的操作进行同步处理 ，虚拟机采用的CAS（见http://www.blogjava.net/xylz/archive/2010/07/04/325206.html） 和失败重试的方式保证更新操作的原子性，另一种是把内存分配的动作按照线程划分在不同的空间进行，即每一个线程都在java堆中预先分配一小块内存。又称本地线程分配缓冲(Thread Local Allocation Buffer,简称TLAB)。 TLAB用完时分配新的TLAB 时需要同步锁定操作。虚拟机设置使用TLAB，可以通过-XX:+/UseTLAB参数设定。
初始化对象内存空间：
内存分配完成之后，虚拟机对该对象分到的内存空间初始化为零值（除了对象头），如果使用了TLAB ,这一工作也可以提前至TLAB分配时进行。 初始化零值这一步也是为什么对象刚创建就可以使用的原因。
对象设置：
虚拟机对对象进行设置，比如对象是那个类的实例，对象的哈希值，gc分带年龄等，这些信息都存在对象的头之中。之后就是执行<init>方法，到此类创建结束。
java对象的内存布局：
对象在内存中分三块区域， 对象头，实例数据，对齐填充。
java对象头部分俩个部分：一部分是用来存对象本身的运行时数据，比如：哈希code, gc分带年龄，锁状态标志，线程持有的锁，偏向线程ID,偏向时间戳等
另一部分是类型的指针，指向类元数据，虚拟机通过这个指针确定它属于那个类的实例，查找对象的元数据信息，并不一定需要经过对象本身。
实例数据部分是对象真正存储的有效信息，也是代码中所定义的类型的字段内容，无论是父类还是子类的都需要记录。
对齐填充不是必然存在的，它只是起占位符的作用，HotSpot VM的自动内存管理系统要求对象的起始地址必须是8字节的整数倍，如果不是则需要通过对齐填充来补全。
对象的访问定位：
一种是通过句柄访问，reference中存储的是句柄地址，这种方式首先需要在java堆中划分一块内存作为句柄池，这种方法的好处是，当对象指针发生改变比如：对象被移动，这个时候reference本身不需要改变。
另一种是直接指针访问，reference直接指向java堆中的类对象地址。对象访问在java虚拟机中很频繁，所以第一种方法会造成一定的开销成本。
JAVA 垃圾回收机制
什么是垃圾回收机：释放那些不再持有引用的对象的内存
怎么判断一个对象是否需要收集？
引用计数（最简单古老的方法）：指将资源（可以是对象、内存或磁盘空间等等）的被引用次数保存起来，当被引用次数变为零时就将其释放的过程
对象引用遍历（现在大多数 jvm 使用的方法）：对象引用遍历从一组对象开始，沿着整个对象图上的每条链接，递归确定可到达（reachable）的对象。如果某对象不能从这些根对象的一个（至少一个）到达，则将它作为垃圾收集
几种垃圾回收机制
标记回收法：遍历对象图并且记录可到达的对象，以便删除不可到达的对象，一般使用单线程工作并且可能产生内存碎片
标记-压缩回收法：前期与第一种方法相同，只是多了一步，将所有的存活对象压缩到内存的一端，这样内存碎片就可以合成一大块可再利用的内存区域，提高了内存利用率
复制回收法：把现有内存空间分成两部分，gc运行时，它把可到达对象复制到另一半空间，再清空正在使用的空间的全部对象。这种方法适用于短生存期的对象，持续复制长生存期的对象则导致效率降低。
分代回收发：把内存空间分为两个或者多个域，如年轻代和老年代，年轻代的特点是对象会很快被回收，因此在年轻代使用效率比较高的算法。当一个对象经过几次回收后依然存活，对象就会被放入称为老年的内存空间，老年代则采取标记-压缩算法
4. GC的两种判定方法：引用计数与引用链
怎么判断一个对象是否需要收集？
引用计数（最简单古老的方法）：指将资源（可以是对象、内存或磁盘空间等等）的被引用次数保存起来，当被引用次数变为零时就将其释放的过程
对象引用遍历（现在大多数 jvm 使用的方法）：对象引用遍历从一组对象开始，沿着整个对象图上的每条链接，递归确定可到达（reachable）的对象。如果某对象不能从这些根对象的一个（至少一个）到达，则将它作为垃圾收集
5.GC的三种收集方法：标记清除、标记整理、复制算法的原理与特点，分别用在什么地方，如果让你优化收集方法，有什么思路？
GC收集器有哪些？CMS收集器与G1收集器的特点。
上面有7中收集器，分为两块，上面为新生代收集器，下面是老年代收集器。如果两个收集器之间存在连线，就说明它们可以搭配使用。
Serial收集器是一个新生代收集器，单线程执行，使用复制算法。它在进行垃圾收集时，必须暂停其他所有的工作线程(用户线程)。是Jvm client模式下默认的新生代收集器。对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。
ParNew收集器其实就是serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为与Serial收集器一样。
Parallel Scavenge收集器也是一个新生代收集器，它也是使用复制算法的收集器，又是并行多线程收集器。parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而parallel Scavenge收集器的目标则是达到一个可控制的吞吐量。吞吐量= 程序运行时间/(程序运行时间 + 垃圾收集时间)，虚拟机总共运行了100分钟。其中垃圾收集花掉1分钟，那吞吐量就是99%。
①.初始标记(CMS initial mark)
②.并发标记(CMS concurrenr mark)
③.重新标记(CMS remark)
④.并发清除(CMS concurrent sweep)
其中初始标记、重新标记这两个步骤任然需要停顿其他用户线程。初始标记仅仅只是标记出GC ROOTS能直接关联到的对象，速度很快，并发标记阶段是进行GC ROOTS 根搜索算法阶段，会判定对象是否存活。而重新标记阶段则是为了修正并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间会被初始标记阶段稍长，但比并发标记阶段要短。
由于整个过程中耗时最长的并发标记和并发清除过程中，收集器线程都可以与用户线程一起工作，所以整体来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。
CMS收集器的优点：并发收集、低停顿，但是CMS还远远达不到完美，器主要有三个显著缺点：
CMS收集器对CPU资源非常敏感。在并发阶段，虽然不会导致用户线程停顿，但是会占用CPU资源而导致引用程序变慢，总吞吐量下降。CMS默认启动的回收线程数是：(CPU数量+3) / 4。
CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure“，失败后而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行，伴随程序的运行自热会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在本次收集中处理它们，只好留待下一次GC时将其清理掉。这一部分垃圾称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行，
即需要预留足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分内存空间提供并发收集时的程序运作使用。在默认设置下，CMS收集器在老年代使用了68%的空间时就会被激活，也可以通过参数-XX:CMSInitiatingOccupancyFraction的值来提供触发百分比，以降低内存回收次数提高性能。要是CMS运行期间预留的内存无法满足程序其他线程需要，就会出现“Concurrent Mode Failure”失败，这时候虚拟机将启动后备预案：临时启用Serial
Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。所以说参数-XX:CMSInitiatingOccupancyFraction设置的过高将会很容易导致“Concurrent Mode Failure”失败，性能反而降低。
最后一个缺点，CMS是基于“标记-清除”算法实现的收集器，使用“标记-清除”算法收集后，会产生大量碎片。空间碎片太多时，将会给对象分配带来很多麻烦，比如说大对象，内存空间找不到连续的空间来分配不得不提前触发一次Full GC。为了解决这个问题，CMS收集器提供了一个-XX:UseCMSCompactAtFullCollection开关参数，用于在Full GC之后增加一个碎片整理过程，还可通过-XX:CMSFullGCBeforeCompaction参数设置执行多少次不压缩的Full GC之后，跟着来一次碎片整理过程。
-XX:+<option> 启用选项
-XX:-<option> 不启用选项
-XX:<option>=<number>
-XX:<option>=<string>
Client、Server模式默认GC
Sun/oracle JDK GC组合方式
7.Minor GC与Full GC分别在什么时候发生？
首页
所有文章
资讯
Web
架构
基础技术
书籍
教程
我要投稿
更多频道 »
- 导航条 -
首页所有文章
资讯Web
架构基础技术
书籍教程
我要投稿更多频道 »
- iOS- Python
- Android- Web前端
2015/04/24 | 分类： 基础技术 | 0
条评论 | 标签： JAVA GC
分享到：5
本文由 ImportNew - 光光头去打酱油 翻译自 javacodegeeks。欢迎加入翻译小组。转载请见文末要求。
在 Plumbr 从事 GC 暂停检测相关功能的工作时，我被迫用自己的方式，通过大量文章、书籍和演讲来介绍我所做的工作。在整个过程中，经常对 Minor、Major、和 Full GC 事件的使用感到困惑。这也是我写这篇博客的原因，我希望能清楚地解释这其中的一些疑惑。
文章要求读者熟悉 JVM 内置的通用垃圾回收原则。堆内存划分为 Eden、Survivor 和 Tenured/Old 空间，代假设和其他不同的 GC 算法超出了本文讨论的范围。
从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor GC。这一定义既清晰又易于理解。但是，当发生Minor GC事件的时候，有一些有趣的地方需要注意到：
当 JVM 无法为一个新的对象分配空间时会触发 Minor GC，比如当 Eden 区满了。所以分配率越高，越频繁执行 Minor GC。
内存池被填满的时候，其中的内容全部会被复制，指针会从0开始跟踪空闲内存。Eden 和 Survivor 区进行了标记和复制操作，取代了经典的标记、扫描、压缩、清理操作。所以 Eden 和 Survivor 区不存在内存碎片。写指针总是停留在所使用内存池的顶部。
执行 Minor GC 操作时，不会影响到永久代。从永久代到年轻代的引用被当成 GC roots，从年轻代到永久代的引用在标记阶段被直接忽略掉。
质疑常规的认知，所有的 Minor GC 都会触发“全世界的暂停（stop-the-world）”，停止应用程序的线程。对于大部分应用程序，停顿导致的延迟都是可以忽略不计的。其中的真相就
是，大部分 Eden 区中的对象都能被认为是垃圾，永远也不会被复制到 Survivor 区或者老年代空间。如果正好相反，Eden 区大部分新生对象不符合 GC 条件，Minor GC 执行时暂停的时间将会长很多。
所以 Minor GC 的情况就相当清楚了——每次 Minor GC 会清理年轻代的内存。
大家应该注意到，目前，这些术语无论是在 JVM 规范还是在垃圾收集研究论文中都没有正式的定义。但是我们一看就知道这些在我们已经知道的基础之上做出的定义是正确的，Minor GC 清理年轻带内存应该被设计得简单：
Major GC 是清理永久代。
Full GC 是清理整个堆空间—包括年轻代和永久代。
很不幸，实际上它还有点复杂且令人困惑。首先，许多 Major GC 是由 Minor GC 触发的，所以很多情况下将这两种 GC 分离是不太可能的。另一方面，许多现代垃圾收集机制会清理部分永久代空间，所以使用“cleaning”一词只是部分正确。
这使得我们不用去关心到底是叫 Major GC 还是 Full GC，大家应该关注当前的 GC 是否停止了所有应用程序的线程，还是能够并发的处理而不用停掉应用程序的线程。
这种混乱甚至内置到 JVM 标准工具。下面一个例子很好的解释了我的意思。让我们比较两个不同的工具 Concurrent Mark 和 Sweep collector (-XX:+UseConcMarkSweepGC)在 JVM 中运行时输出的跟踪记录。
第一次尝试通过 jstat 输出：
这个片段是 JVM 启动后第17秒提取的。基于该信息，我们可以得出这样的结果，运行了12次 Minor GC、2次 Full GC，时间总跨度为50毫秒。通过 jconsole 或者 jvisualvm 这样的基于GUI的工具你能得到同样的结果。
在点头同意这个结论之前，让我们看看来自同一个 JVM 启动收集的垃圾收集日志的输出。显然- XX ： + PrintGCDetails 告诉我们一个不同且更详细的故事：
基于这些信息，我们可以看到12次 Minor GC 后开始有些和上面不一样了。没有运行两次 Full GC，这不同的地方在于单个 GC 在永久代中不同阶段运行了两次：
最初的标记阶段，用了0.0041705秒也就是4ms左右。这个阶段会暂停“全世界（ stop-the-world）”的事件，停止所有应用程序的线程，然后开始标记。
并行执行标记和清洗阶段。这些都是和应用程序线程并行的。
最后 Remark 阶段，花费了0.0462010秒约46ms。这个阶段会再次暂停所有的事件。
并行执行清理操作。正如其名，此阶段也是并行的，不会停止其他线程。
所以，正如我们从垃圾回收日志中所看到的那样，实际上只是执行了 Major GC 去清理老年代空间而已，而不是执行了两次 Full GC。
如果你是后期做决 定的话，那么由 jstat 提供的数据会引导你做出正确的决策。它正确列出的两个暂停所有事件的情况，导致所有线程停止了共计50ms。但是如果你试图优化吞吐量，你会被误导的。清 单只列出了回收初始标记和最终 Remark 阶段，jstat的输出看不到那些并发完成的工作。
考虑到这种情况，最好避免以 Minor、Major、Full GC 这种方式来思考问题。而应该监控应用延迟或者吞吐量，然后将 GC 事件和结果联系起来。
随着这些 GC 事件的发生，你需要额外的关注某些信息，GC 事件是强制所有应用程序线程停止了还是并行的处理了部分事件。
如果你喜欢这篇我们垃圾回收手册的示例篇，那么请关注一下，整个教程将在2015年3月左右发布。
8.几种常用的内存调试工具;jmap、Jconsole、jstack、
9.类加载的五个过程:加载、验证、准备、解析、初始化
首页
所有文章
资讯
Web
架构
基础技术
书籍
教程
我要投稿
更多频道 »
- 导航条 -
首页所有文章
资讯Web
架构基础技术
书籍教程
我要投稿更多频道 »
- iOS- Python
- Android- Web前端
2015/04/24 | 分类： 基础技术 | 0
条评论 | 标签： JAVA GC
分享到：5
本文由 ImportNew - 光光头去打酱油 翻译自 javacodegeeks。欢迎加入翻译小组。转载请见文末要求。
在 Plumbr 从事 GC 暂停检测相关功能的工作时，我被迫用自己的方式，通过大量文章、书籍和演讲来介绍我所做的工作。在整个过程中，经常对 Minor、Major、和 Full GC 事件的使用感到困惑。这也是我写这篇博客的原因，我希望能清楚地解释这其中的一些疑惑。
文章要求读者熟悉 JVM 内置的通用垃圾回收原则。堆内存划分为 Eden、Survivor 和 Tenured/Old 空间，代假设和其他不同的 GC 算法超出了本文讨论的范围。
从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor GC。这一定义既清晰又易于理解。但是，当发生Minor GC事件的时候，有一些有趣的地方需要注意到：
当 JVM 无法为一个新的对象分配空间时会触发 Minor GC，比如当 Eden 区满了。所以分配率越高，越频繁执行 Minor GC。
内存池被填满的时候，其中的内容全部会被复制，指针会从0开始跟踪空闲内存。Eden 和 Survivor 区进行了标记和复制操作，取代了经典的标记、扫描、压缩、清理操作。所以 Eden 和 Survivor 区不存在内存碎片。写指针总是停留在所使用内存池的顶部。
执行 Minor GC 操作时，不会影响到永久代。从永久代到年轻代的引用被当成 GC roots，从年轻代到永久代的引用在标记阶段被直接忽略掉。
质疑常规的认知，所有的 Minor GC 都会触发“全世界的暂停（stop-the-world）”，停止应用程序的线程。对于大部分应用程序，停顿导致的延迟都是可以忽略不计的。其中的真相就
是，大部分 Eden 区中的对象都能被认为是垃圾，永远也不会被复制到 Survivor 区或者老年代空间。如果正好相反，Eden 区大部分新生对象不符合 GC 条件，Minor GC 执行时暂停的时间将会长很多。
所以 Minor GC 的情况就相当清楚了——每次 Minor GC 会清理年轻代的内存。
大家应该注意到，目前，这些术语无论是在 JVM 规范还是在垃圾收集研究论文中都没有正式的定义。但是我们一看就知道这些在我们已经知道的基础之上做出的定义是正确的，Minor GC 清理年轻带内存应该被设计得简单：
Major GC 是清理永久代。
Full GC 是清理整个堆空间—包括年轻代和永久代。
很不幸，实际上它还有点复杂且令人困惑。首先，许多 Major GC 是由 Minor GC 触发的，所以很多情况下将这两种 GC 分离是不太可能的。另一方面，许多现代垃圾收集机制会清理部分永久代空间，所以使用“cleaning”一词只是部分正确。
这使得我们不用去关心到底是叫 Major GC 还是 Full GC，大家应该关注当前的 GC 是否停止了所有应用程序的线程，还是能够并发的处理而不用停掉应用程序的线程。
这种混乱甚至内置到 JVM 标准工具。下面一个例子很好的解释了我的意思。让我们比较两个不同的工具 Concurrent Mark 和 Sweep collector (-XX:+UseConcMarkSweepGC)在 JVM 中运行时输出的跟踪记录。
第一次尝试通过 jstat 输出：
这个片段是 JVM 启动后第17秒提取的。基于该信息，我们可以得出这样的结果，运行了12次 Minor GC、2次 Full GC，时间总跨度为50毫秒。通过 jconsole 或者 jvisualvm 这样的基于GUI的工具你能得到同样的结果。
在点头同意这个结论之前，让我们看看来自同一个 JVM 启动收集的垃圾收集日志的输出。显然- XX ： + PrintGCDetails 告诉我们一个不同且更详细的故事：
基于这些信息，我们可以看到12次 Minor GC 后开始有些和上面不一样了。没有运行两次 Full GC，这不同的地方在于单个 GC 在永久代中不同阶段运行了两次：
最初的标记阶段，用了0.0041705秒也就是4ms左右。这个阶段会暂停“全世界（ stop-the-world）”的事件，停止所有应用程序的线程，然后开始标记。
并行执行标记和清洗阶段。这些都是和应用程序线程并行的。
最后 Remark 阶段，花费了0.0462010秒约46ms。这个阶段会再次暂停所有的事件。
并行执行清理操作。正如其名，此阶段也是并行的，不会停止其他线程。
所以，正如我们从垃圾回收日志中所看到的那样，实际上只是执行了 Major GC 去清理老年代空间而已，而不是执行了两次 Full GC。
如果你是后期做决 定的话，那么由 jstat 提供的数据会引导你做出正确的决策。它正确列出的两个暂停所有事件的情况，导致所有线程停止了共计50ms。但是如果你试图优化吞吐量，你会被误导的。清 单只列出了回收初始标记和最终 Remark 阶段，jstat的输出看不到那些并发完成的工作。
考虑到这种情况，最好避免以 Minor、Major、Full GC 这种方式来思考问题。而应该监控应用延迟或者吞吐量，然后将 GC 事件和结果联系起来。
随着这些 GC 事件的发生，你需要额外的关注某些信息，GC 事件是强制所有应用程序线程停止了还是并行的处理了部分事件。
如果你喜欢这篇我们垃圾回收手册的示例篇，那么请关注一下，整个教程将在2015年3月左右发布。
9. 类加载的五个过程：加载、验证、准备、解析、初始化
JVM把class文件加载的内存，并对数据进行校验、转换解析和初始化，最终形成JVM可以直接使用的Java类型的过程就是加载机制。
类从被加载到虚拟机内存中开始，到卸载出内存为止，它的生命周期包括了：加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)、卸载(Unloading)七个阶段，其中验证、准备、解析三个部分统称链接。
加载(装载)、验证、准备、初始化和卸载这五个阶段顺序是固定的，类的加载过程必须按照这种顺序开始，而解析阶段不一定；它在某些情况下可以在初始化之后再开始，这是为了运行时动态绑定特性。值得注意的是：这些阶段通常都是互相交叉的混合式进行的，通常会在一个阶段执行的过程中调用或激活另外一个阶段。
加载+验证+准备+解析+初始化
1、“加载”阶段，虚拟机需要完成以下三件事情：
（1）通过一个类的权限定名来获取定义此类的二进制字节流
（2）将这个字节流所代表的静态存储结构转化为方法去的运行时数据结构
（3）在java堆中生成一个代表这个类的java.lang.Class对象，作为方法去这些数据的访问入口。
2、验证
（1）文件格式验证--验证class文件格式规范，例如： class文件是否已魔术0xCAFEBABE开头 ， 主、次版本号是否在当前虚拟机处理范围之内等
（2）元数据验证--这个阶段是对字节码描述的信息进行语义分析，以保证起描述的信息符合java语言规范要求。验证点可能包括：这个类是否有父类(除了java.lang.Object之外，所有的类都应当有父类)、这个类是否继承了不允许被继承的类(被final修饰的)、如果这个类的父类是抽象类，是否实现了起父类或接口中要求实现的所有方法。
（3）字节码验证--进行数据流和控制流分析，这个阶段对类的方法体进行校验分析，这个阶段的任务是保证被校验类的方法在运行时不会做出危害虚拟机安全的行为.如：保证访法体中的类型转换有效，例如可以把一个子类对象赋值给父类数据类型，这是安全的，但不能把一个父类对象赋值给子类数据类型、保证跳转命令不会跳转到方法体以外的字节码命令上。
（4）符号引用验证--符号引用中通过字符串描述的全限定名是否能找到对应的类、符号引用类中的类，字段和方法的访问性(private、protected、public、default)是否可被当前类访问。
3、准备
准备阶段是正式为类变量分配内存并设置变量初始值的阶段，这些内存都将在方法去中进行分配。
注意：（1）进行内存分配的仅包括类变量（被static修饰的变量），而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在java堆中
（2）初始值是指数据类型的零值，例如：
public static int value = 123;
那么变量value在准备阶段过后的值是0，而不是123，因为这时候尚未开始执行任何java方法。
再看：public static final int value = 123;
final修饰的字段，子啊准备阶段虚拟机就会根据赋值，value的值为123.
4、解析
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程
符号引用：符号引用是一组符号来描述所引用的目标对象，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标对象并不一定已经加载到内存中。
直接引用：直接引用可以是直接指向目标对象的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是与虚拟机内存布局实现相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同，如果有了直接引用，那引用的目标必定已经在内存中存在。
虚拟机规范并没有规定解析阶段发生的具体时间，只要求了在执行anewarry、checkcast、getfield、instanceof、invokeinterface、invokespecial、invokestatic、invokevirtual、multianewarray、new、putfield和putstatic这13个用于操作符号引用的字节码指令之前，先对它们使用的符号引用进行解析，所以虚拟机实现会根据需要来判断，到底是在类被加载器加载时就对常量池中的符号引用进行解析，还是等到一个符号引用将要被使用前才去解析它。
(1)类或接口的解析
(2)字段解析：首先解析出类的方法表的class_index项中索引的字段所属的类或接口的符号引用，然后继续搜索：
先在类本身中查找字段
再在类的实现的接口中查找字段
然后在类的父类中查找字段
否则，查找失败
(3)类方法解析：首先解析出类的方法表的class_index项中索引的方法所属的类或接口的符号引用，然后继续搜索：
类方法和接口方法符号引用的常量类型定义是分开的，如果在类方法表中发现class_index中索引的是个接口，直接报错。
在类中递归查找是否有简单名称和描述符都与目标相匹配的方法，如果有直接返回
在类实现的父类中查找是否有简单名称和描述符都与目标相匹配的方法，如果有直接返回
在类实现的接口列表及他们的父接口中查找是否有简单名称和描述符都与目标相匹配的方法，如果有直接报错
否则，查找失败
(4)接口方法解析：首先解析出类的方法表的class_index项中索引的方法所属的类或接口的符号引用。正好与接口相反。
5、初始化
初始化阶段才真正开始执行类中定义的java程序代码
初始化阶段是执行类构造器<clinit>()方法的过程。在以下四种情况下初始化过程会被触发执行：
1.遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，如果类没有进行过初始化，则需先触发其初始化。生成这4条指令的最常见的java代码场景是：使用new关键字实例化对象、读取或设置一个类的静态字段(被final修饰、已在编译器把结果放入常量池的静态字段除外)的时候，以及调用类的静态方法的时候。
2.使用java.lang.reflect包的方法对类进行反射调用的时候
3.当初始化一个类的时候，如果发现其父类还没有进行过初始化、则需要先出发其父类的初始化
4.jvm启动时，用户指定一个执行的主类(包含main方法的那个类)，虚拟机会先初始化这个类
在准备阶段，变量已经赋过一次系统要求的初始值，二在初始阶段，则是根据程序员通过程序制定的主观计划去初始化类变量和其他资源。
10. 双亲委派模型：Bootstrap ClassLoader、Extension ClassLoader、ApplicationClassLoader
JVM预定义的三种类型类加载器：
启动（Bootstrap）类加载器：是用本地代码实现的类装入器，它负责将
标准扩展（Extension）类加载器：是由 Sun 的
系统（System）类加载器：是由 Sun 的
除了以上列举的三种类加载器，还有一种比较特殊的类型 — 线程上下文类加载器。
双亲委派机制描述
某个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父类加载器，依次递归，如果父类加载器可以完成类加载任务，就成功返回；只有父类加载器无法完成此加载任务时，才自己去加载。
Java虚拟机的第一个类加载器是Bootstrap，这个加载器很特殊，它不是Java类，因此它不需要被别人加载，它嵌套在Java虚拟机内核里面，也就是JVM启动的时候Bootstrap就已经启动，它是用C++写的二进制代码（不是字节码），它可以去加载别的类。
这也是我们在测试时为什么发现
委托机制具体含义
当Java虚拟机要加载一个类时，到底派出哪个类加载器去加载呢？
首先当前线程的类加载器去加载线程中的第一个类（假设为类A）。
注：当前线程的类加载器可以通过Thread类的getContextClassLoader()获得，也可以通过setContextClassLoader()自己设置类加载器。
如果类A中引用了类B，Java虚拟机将使用加载类A的类加载器去加载类B。
还可以直接调用
委托机制的意义 — 防止内存中出现多份同样的字节码
比如两个类A和类B都要加载System类：
如果不用委托而是自己加载自己的，那么类A就会加载一份System字节码，然后类B又会加载一份System字节码，这样内存中就出现了两份System字节码。
如果使用委托机制，会递归的向父类查找，也就是首选用Bootstrap尝试加载，如果找不到再向下。这里的System就能在Bootstrap中找到然后加载，如果此时类B也要加载System，也从Bootstrap开始，此时Bootstrap发现已经加载过了System那么直接返回内存中的System即可而不需要重新加载，这样内存中就只有一份System的字节码了。
能不能自己写个类叫
答案：通常不可以，但可以采取另类方法达到这个需求。
解释：为了不让我们写System类，类加载采用委托机制，这样可以保证爸爸们优先，爸爸们能找到的类，儿子就没有机会加载。而System类是Bootstrap加载器加载的，就算自己重写，也总是使用Java系统提供的System，自己写的System类根本没有机会得到加载。
但是，我们可以自己定义一个类加载器来达到这个目的，为了避免双亲委托机制，这个类加载器也必须是特殊的。由于系统自带的三个类加载器都加载特定目录下的类，如果我们自己的类加载器放在一个特殊的目录，那么系统的加载器就无法加载，也就是最终还是由我们自己的加载器加载。
我们知道，计算机只认识0 和 1, 所以我们写的程序需要被编译器翻译成由0和1构成的二进制格式才能被计算机执行。经过几十年的发展，计算机仍然只能认识0和1，但是由于最近10年内虚拟机及建立在虚拟机之上的大量程序语言如雨后春笋般出现并蓬勃发展，将我们编写的程序编译成二进制本地机器码已不再是唯一的选择，越来越多的语言选择了与操作系统和机器指令集无关的、平台中立的格式作为程序编译后的存储格式。
Java的跨平台性，所谓的“一次编写，到处运行”的原理也就建立在这个基础之上。
所以我们提到的类的加载过程，不是机器码二进制文件的加载，而是Java的字节码形式的Class文件。
Class类文件的结构是怎样的呢？
Class文件是一组以8位字节为基础单位的二进制流，各个数据项目严格按照顺序紧凑地排列在Class文件当中，中间没有添加任何分隔符，这使得整个Class文件中存储的内容几乎全部都是程序运行的必要数据，没有空隙存在。当遇到需要占用8位字节以上空间的数据项时，则会按照高位在前的方式分隔成若干个8位字节进行存储。
大体上分为 魔数，常量池，访问标识，类索引、父类索引、接口索引、字段表集合、方法表集合、属性表集合。
虚拟机把描述类的数据从Class文件加载到内存，并多数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。
与那些在编译时需要进行链接工作的语言不同，在Java语言里面，类型的加载和链接过程都是在程序运行期间完成的（其实C++也是分为静态链接库和动态链接库的），这样会在类加载时稍微增加一些性能开销，但是却能为Java应用程序提供高度的灵活性，Java中天生可以动态扩展的语言特性就是依赖运行期动态加载和动态链接这个特点实现的。例如，如果编写一个使用接口的应用程序，运行时再指定其实际的表现。
类加载过程
类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载七个阶段。其中验证、准备和解析三个部分统称为连接，它们开始的顺序如下图所示：
<img src="https://pic2.zhimg.com/86e2e4a282814a1cd630062e4d29bc6d_b.png" data-rawwidth="559" data-rawheight="159" class="origin_image zh-lightbox-thumb" width="559" data-original="https://pic2.zhimg.com/86e2e4a282814a1cd630062e4d29bc6d_r.png">
<img
src="https://pic1.zhimg.com/821c7fc42e69a78032bec9bb56e47310_b.png" data-rawwidth="820" data-rawheight="279" class="origin_image zh-lightbox-thumb" width="820" data-original="https://pic1.zhimg.com/821c7fc42e69a78032bec9bb56e47310_r.png">
其中类加载的过程包括了加载、验证、准备、解析、初始化五个阶段。在这五个阶段中，加载、验证、准备和初始化这四个阶段发生的顺序是确定的，而解析阶段则不一定，它在某些情况下可以在初始化阶段之后开始，这是为了支持Java语言的运行时绑定（也成为动态绑定或晚期绑定）。另外注意这里的几个阶段是按顺序开始，而不是按顺序进行或完成，因为这些阶段通常都是互相交叉地混合进行的，通常在一个阶段执行的过程中调用或激活另一个阶段。
这里简要说明下Java中的绑定：绑定指的是把一个方法的调用与方法所在的类(方法主体)关联起来，对java来说，绑定分为静态绑定和动态绑定：
静态绑定：即前期绑定。在程序执行前方法已经被绑定，此时由编译器或其它连接程序实现。针对java，简单的可以理解为程序编译期的绑定。java当中的方法只有final，static，private和构造方法是前期绑定的。
动态绑定：即晚期绑定，也叫运行时绑定。在运行时根据具体对象的类型进行绑定。在java中，几乎所有的方法都是后期绑定的。
下面详细讲述类加载过程中每个阶段所做的工作。
加载
加载时类加载过程的第一个阶段，在加载阶段，虚拟机需要完成以下三件事情：
1、通过一个类的全限定名来获取其定义的二进制字节流。
2、将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3、在Java堆中生成一个代表这个类的java.lang.Class对象，作为对方法区中这些数据的访问入口。
注意，这里第1条中的二进制字节流并不只是单纯地从Class文件中获取，比如它还可以从Jar包中获取、从网络中获取（最典型的应用便是Applet）、由其他文件生成（JSP应用）等。
相对于类加载的其他阶段而言，加载阶段（准确地说，是加载阶段获取类的二进制字节流的动作）是可控性最强的阶段，因为开发人员既可以使用系统提供的类加载器来完成加载，也可以自定义自己的类加载器来完成加载。
加载阶段完成后，虚拟机外部的 二进制字节流就按照虚拟机所需的格式存储在方法区之中，而且在Java堆中也创建一个java.lang.Class类的对象，这样便可以通过该对象访问方法区中的这些数据。
说到加载，不得不提到类加载器，下面就具体讲述下类加载器。
类加载器虽然只用于实现类的加载动作，但它在Java程序中起到的作用却远远不限于类的加载阶段。对于任意一个类，都需要由它的类加载器和这个类本身一同确定其在就Java虚拟机中的唯一性，也就是说，即使两个类来源于同一个Class文件，只要加载它们的类加载器不同，那这两个类就必定不相等。这里的“相等”包括了代表类的Class对象的equals（）、isAssignableFrom（）、isInstance（）等方法的返回结果，也包括了使用instanceof关键字对对象所属关系的判定结果。
站在Java虚拟机的角度来讲，只存在两种不同的类加载器：
启动类加载器：它使用C++实现（这里仅限于Hotspot，也就是JDK1.5之后默认的虚拟机，有很多其他的虚拟机是用Java语言实现的），是虚拟机自身的一部分。
所有其他的类加载器：这些类加载器都由Java语言实现，独立于虚拟机之外，并且全部继承自抽象类java.lang.ClassLoader，这些类加载器需要由启动类加载器加载到内存中之后才能去加载其他的类。
站在Java开发人员的角度来看，类加载器可以大致划分为以下三类：
启动类加载器：Bootstrap ClassLoader，跟上面相同。它负责加载存放在JDK\jre\lib(JDK代表JDK的安装目录，下同)下，或被-Xbootclasspath参数指定的路径中的，并且能被虚拟机识别的类库（如rt.jar，所有的java.*开头的类均被Bootstrap ClassLoader加载）。启动类加载器是无法被Java程序直接引用的。
扩展类加载器：Extension ClassLoader，该加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载JDK\jre\lib\ext目录中，或者由java.ext.dirs系统变量指定的路径中的所有类库（如javax.*开头的类），开发者可以直接使用扩展类加载器。
应用程序类加载器：Application ClassLoader，该类加载器由sun.misc.Launcher$AppClassLoader来实现，它负责加载用户类路径（ClassPath）所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
应用程序都是由这三种类加载器互相配合进行加载的，如果有必要，我们还可以加入自定义的类加载器。因为JVM自带的ClassLoader只是懂得从本地文件系统加载标准的java class文件，因此如果编写了自己的ClassLoader，便可以做到如下几点：
1）在执行非置信代码之前，自动验证数字签名。
2）动态地创建符合用户特定需要的定制化构建类。
3）从特定的场所取得java class，例如数据库中和网络中。
事实上当使用Applet的时候，就用到了特定的ClassLoader，因为这时需要从网络上加载java class，并且要检查相关的安全信息，应用服务器也大都使用了自定义的ClassLoader技术。
这几种类加载器的层次关系如下图所示：
<img src="https://pic3.zhimg.com/ad1e4be1cb0d77cdd948336a093dd8a6_b.png" data-rawwidth="212" data-rawheight="438" class="content_image" width="212">
这种层次关系称为类加载器的双亲委派模型。我们把每一层上面的类加载器叫做当前层类加载器的父加载器，当然，它们之间的父子关系并不是通过继承关系来实现的，而是使用组合关系来复用父加载器中的代码。该模型在JDK1.2期间被引入并广泛应用于之后几乎所有的Java程序中，但它并不是一个强制性的约束模型，而是Java设计者们推荐给开发者的一种类的加载器实现方式。
双亲委派模型的工作流程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把请求委托给父加载器去完成，依次向上，因此，所有的类加载请求最终都应该被传递到顶层的启动类加载器中，只有当父加载器在它的搜索范围中没有找到所需的类时，即无法完成该加载，子加载器才会尝试自己去加载该类。
使用双亲委派模型来组织类加载器之间的关系，有一个很明显的好处，就是Java类随着它的类加载器（说白了，就是它所在的目录）一起具备了一种带有优先级的层次关系，这对于保证Java程序的稳定运作很重要。例如，类java.lang.Object类存放在JDK\jre\lib下的rt.jar之中，因此无论是哪个类加载器要加载此类，最终都会委派给启动类加载器进行加载，这边保证了Object类在程序中的各种类加载器中都是同一个类。
验证
验证的目的是为了确保Class文件中的字节流包含的信息符合当前虚拟机的要求，而且不会危害虚拟机自身的安全。不同的虚拟机对类验证的实现可能会有所不同，但大致都会完成以下四个阶段的验证：文件格式的验证、元数据的验证、字节码验证和符号引用验证。
文件格式的验证：验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理，该验证的主要目的是保证输入的字节流能正确地解析并存储于方法区之内。经过该阶段的验证后，字节流才会进入内存的方法区中进行存储，后面的三个验证都是基于方法区的存储结构进行的。
元数据验证：对类的元数据信息进行语义校验（其实就是对类中的各数据类型进行语法校验），保证不存在不符合Java语法规范的元数据信息。
字节码验证：该阶段验证的主要工作是进行数据流和控制流分析，对类的方法体进行校验分析，以保证被校验的类的方法在运行时不会做出危害虚拟机安全的行为。
符号引用验证：这是最后一个阶段的验证，它发生在虚拟机将符号引用转化为直接引用的时候（解析阶段中发生该转化，后面会有讲解），主要是对类自身以外的信息（常量池中的各种符号引用）进行匹配性的校验。
准备
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。对于该阶段有以下几点需要注意：
1、这时候进行内存分配的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在Java堆中。
2、这里所设置的初始值通常情况下是数据类型默认的零值（如0、0L、null、false等），而不是被在Java代码中被显式地赋予的值。
假设一个类变量的定义为：
public static int value = 3；
那么变量value在准备阶段过后的初始值为0，而不是3，因为这时候尚未开始执行任何Java方法，而把value赋值为3的putstatic指令是在程序编译后，存放于类构造器<clinit>（）方法之中的，所以把value赋值为3的动作将在初始化阶段才会执行。
下表列出了Java中所有基本数据类型以及reference类型的默认零值：
<img src="https://pic4.zhimg.com/fb0794ced9fd6f7a09eb52e96adb5b33_b.png" data-rawwidth="348" data-rawheight="431" class="content_image" width="348">
这里还需要注意如下几点：
对基本数据类型来说，对于类变量（static）和全局变量，如果不显式地对其赋值而直接使用，则系统会为其赋予默认的零值，而对于局部变量来说，在使用前必须显式地为其赋值，否则编译时不通过。
对于同时被static和final修饰的常量，必须在声明的时候就为其显式地赋值，否则编译时不通过；而只被final修饰的常量则既可以在声明时显式地为其赋值，也可以在类初始化时显式地为其赋值，总之，在使用前必须为其显式地赋值，系统不会为其赋予默认零值。
对于引用数据类型reference来说，如数组引用、对象引用等，如果没有对其进行显式地赋值而直接使用，系统都会为其赋予默认的零值，即null。
如果在数组初始化时没有对数组中的各元素赋值，那么其中的元素将根据对应的数据类型而被赋予默认的零值。
3、如果类字段的字段属性表中存在ConstantValue属性，即同时被final和static修饰，那么在准备阶段变量value就会被初始化为ConstValue属性所指定的值。
假设上面的类变量value被定义为：
public static final int value = 3；
编译时Javac将会为value生成ConstantValue属性，在准备阶段虚拟机就会根据ConstantValue的设置将value赋值为3。回忆上一篇博文中对象被动引用的第2个例子，便是这种情况。我们可以理解为static
final常量在编译期就将其结果放入了调用它的类的常量池中。
解析
解析阶段是虚拟机将常量池中的符号引用转化为直接引用的过程。在Class类文件结构一文中已经比较过了符号引用和直接引用的区别和关联，这里不再赘述。前面说解析阶段可能开始于初始化之前，也可能在初始化之后开始，虚拟机会根据需要来判断，到底是在类被加载器加载时就对常量池中的符号引用进行解析（初始化之前），还是等到一个符号引用将要被使用前才去解析它（初始化之后）。
对同一个符号引用进行多次解析请求时很常见的事情，虚拟机实现可能会对第一次解析的结果进行缓存（在运行时常量池中记录直接引用，并把常量标示为已解析状态），从而避免解析动作重复进行。
解析动作主要针对类或接口、字段、类方法、接口方法四类符号引用进行，分别对应于常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_InterfaceMethodref_info四种常量类型。
1、类或接口的解析：判断所要转化成的直接引用是对数组类型，还是普通的对象类型的引用，从而进行不同的解析。
2、字段解析：对字段进行解析时，会先在本类中查找是否包含有简单名称和字段描述符都与目标相匹配的字段，如果有，则查找结束；如果没有，则会按照继承关系从上往下递归搜索该类所实现的各个接口和它们的父接口，还没有，则按照继承关系从上往下递归搜索其父类，直至查找结束，查找流程如下图所示：
<img src="https://pic2.zhimg.com/c6aab61c996d47f5a3d339d204e32dcd_b.png" data-rawwidth="577" data-rawheight="161" class="origin_image zh-lightbox-thumb" width="577" data-original="https://pic2.zhimg.com/c6aab61c996d47f5a3d339d204e32dcd_r.png">从下面一段代码的执行结果中很容易看出来字段解析的搜索顺序：
从下面一段代码的执行结果中很容易看出来字段解析的搜索顺序：
执行结果如下：
执行了super类静态语句块
执行了父类静态语句块
33
如果注释掉Father类中对m定义的那一行，则输出结果如下：
执行了super类静态语句块
11
另外，很明显这就是上篇博文中的第1个例子的情况，这里我们便可以分析如下：static变量发生在静态解析阶段，也即是初始化之前，此时已经将字段的符号引用转化为了内存引用，也便将它与对应的类关联在了一起，由于在子类中没有查找到与m相匹配的字段，那么m便不会与子类关联在一起，因此并不会触发子类的初始化。
最后需要注意：理论上是按照上述顺序进行搜索解析，但在实际应用中，虚拟机的编译器实现可能要比上述规范要求的更严格一些。如果有一个同名字段同时出现在该类的接口和父类中，或同时在自己或父类的接口中出现，编译器可能会拒绝编译。如果对上面的代码做些修改，将Super改为接口，并将Child类继承Father类且实现Super接口，那么在编译时会报出如下错误：
StaticTest.java:24: 对 m 的引用不明确，Father 中的 变量 m 和 Super 中的 变量 m
都匹配
System.out.println(Child.m);
^
1 错误
3、类方法解析：对类方法的解析与对字段解析的搜索步骤差不多，只是多了判断该方法所处的是类还是接口的步骤，而且对类方法的匹配搜索，是先搜索父类，再搜索接口。
4、接口方法解析：与类方法解析步骤类似，知识接口不会有父类，因此，只递归向上搜索父接口就行了。
初始化 初始化是类加载过程的最后一步，到了此阶段，才真正开始执行类中定义的Java程序代码。在准备阶段，类变量已经被赋过一次系统要求的初始值，而在初始化阶段，则是根据程序员通过程序指定的主观计划去初始化类变量和其他资源，或者可以从另一个角度来表达：初始化阶段是执行类构造器<clinit>()方法的过程。
这里简单说明下<clinit>（）方法的执行规则:
1、<clinit>（）方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句中可以赋值，但是不能访问。
2、<clinit>（）方法与实例构造器<init>（）方法（类的构造函数）不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的<clinit>（）方法执行之前，父类的<clinit>（）方法已经执行完毕。因此，在虚拟机中第一个被执行的<clinit>（）方法的类肯定是java.lang.Object。
3、<clinit>（）方法对于类或接口来说并不是必须的，如果一个类中没有静态语句块，也没有对类变量的赋值操作，那么编译器可以不为这个类生成<clinit>（）方法。
4、接口中不能使用静态语句块，但仍然有类变量（final static）初始化的赋值操作，因此接口与类一样会生成<clinit>（）方法。但是接口鱼类不同的是：执行接口的<clinit>（）方法不需要先执行父接口的<clinit>（）方法，只有当父接口中定义的变量被使用时，父接口才会被初始化。另外，接口的实现类在初始化时也一样不会执行接口的<clinit>（）方法。
5、虚拟机会保证一个类的<clinit>（）方法在多线程环境中被正确地加锁和同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>（）方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>（）方法完毕。如果在一个类的<clinit>（）方法中有耗时很长的操作，那就可能造成多个线程阻塞，在实际应用中这种阻塞往往是很隐蔽的。
下面给出一个简单的例子，以便更清晰地说明如上规则：
执行上面的代码，会打印出2，也就是说b的值被赋为了2。
我们来看得到该结果的步骤。首先在准备阶段为类变量分配内存并设置类变量初始值，这样A和B均被赋值为默认值0，而后再在调用<clinit>（）方法时给他们赋予程序中指定的值。当我们调用Child.b时，触发Child的<clinit>（）方法，根据规则2，在此之前，要先执行完其父类Father的<clinit>（）方法，又根据规则1，在执行<clinit>（）方法时，需要按static语句或static变量赋值操作等在代码中出现的顺序来执行相关的static语句，因此当触发执行Father的<clinit>（）方法时，会先将a赋值为1，再执行static语句块中语句，将a赋值为2，而后再执行Child类的<clinit>（）方法，这样便会将b的赋值为2.
如果我们颠倒一下Father类中“public static int a = 1;”语句和“static语句块”的顺序，程序执行后，则会打印出1。很明显是根据规则1，执行Father的<clinit>（）方法时，根据顺序先执行了static语句块中的内容，后执行了“public static int a = 1;”语句。
另外，在颠倒二者的顺序之后，如果在static语句块中对a进行访问（比如将a赋给某个变量），在编译时将会报错，因为根据规则1，它只能对a进行赋值，而不能访问。
总结 整个类加载过程中，除了在加载阶段用户应用程序可以自定义类加载器参与之外，其余所有的动作完全由虚拟机主导和控制。到了初始化才开始执行类中定义的Java程序代码（亦及字节码），但这里的执行代码只是个开端，它仅限于<clinit>（）方法。类加载过程中主要是将Class文件（准确地讲，应该是类的二进制字节流）加载到虚拟机内存中，真正执行字节码的操作，在加载完成后才真正开始。
作者：郭无心
链接：http://www.zhihu.com/question/29125656/answer/74503568
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
11. 分派：静态分派与动态分派。
本文以Java多态的一些基本特征来谈一下分派调用。
在开始，依旧用常用方式，例子来引入，看一看下面例子的输出：
?
输出结果：
hello, guy!
hello, guy!
没错，程序就是大家熟悉的重载（Overload），而且大家也应该能知道输出结果，但是为什么输出结果会是这个呢？
先来谈一下以下代码的定义：
?
我们把 Human称为变量的 静态类型， Man称为变量的 实际类型。
其中，变量的静态类型和动态类型在程序中都可以发生变化，而区别是变量的静态类型是在编译阶段就可知的，但是动态类型要在运行期才可以确定，编译器在编译的时候并不知道变量的实际类型是什么（个人认为可能也是因为要实现多态，所以才会这样设定）。
现在回到代码中，由于方法的接受者已经确定是StaticDispatch的实例sd了，所以最终调用的是哪个重载版本也就取决于传入参数的类型了。
实际上，虚拟机（应该说是编译器）在重载时时通过参数的静态类型来当判定依据的，而且静态类型在编译期就可知，所以编译器在编译阶段就可根据静态类型来判定究竟使用哪个重载版本。于是对于例子中的两个方法的调用都是以Human为参数的版本。
Java中，所有以静态类型来定位方法执行版本的分派动作，都称为静态分派。
再来看动态分派，它和多态的另外一个重要体现有很大的关联，这个体现是什么，可能大家也能猜出，没错，就是重写（override）。
例子如下：
?
输出结果：
hello man!
hello women!
hello women!
这个结果已经没什么好说的了，而虚拟机是如何知道要调用哪个方法的呢？
其实由两次改变man变量的实际类型导致调用函数版本不同，我们就可以知道，虚拟机是根据变量的实际类型来调用重写方法的。
我们也可以从例子中看出，变量的实际类型是在运行期确定的，重写方法的调用也是根据实际类型来调用的。
我们把这种在运行期根据实际类型来确定方法执行版本的分派动作，称为动态分派。
Class 文件的编译过程中不包含传统编译中的连接步骤，一切方法调用在 Class 文件里面存储的都只是符号引用，而不是方法在实际运行时内存布局中的入口地址。这个特性给 Java 带来了更强大的动态扩展能力，使得可以在类运行期间才能确定某些目标方法的直接引用，称为动态连接，也有一部分方法的符号引用在类加载阶段或第一次使用时转化为直接引用，这种转化称为静态解析。这在前面的“Java
内存区域与内存溢出”一文中有提到。
静态解析成立的前提是：方法在程序真正执行前就有一个可确定的调用版本，并且这个方法的调用版本在运行期是不可改变的。换句话说，调用目标在编译器进行编译时就必须确定下来，这类方法的调用称为解析。
在 Java 语言中，符合“编译器可知，运行期不可变”这个要求的方法主要有静态方法和私有方法两大类，前者与类型直接关联，后者在外部不可被访问，这两种方法都不可能通过继承或别的方式重写出其他的版本，因此它们都适合在类加载阶段进行解析。
Java 虚拟机里共提供了四条方法调用字节指令，分别是：
invokestatic：调用静态方法。
invokespecial：调用实例构造器方法、私有方法和父类方法。
invokevirtual：调用所有的虚方法。
invokeinterface：调用接口方法，会在运行时再确定一个实现此接口的对象。
只要能被 invokestatic 和 invokespecial 指令调用的方法，都可以在解析阶段确定唯一的调用版本，符合这个条件的有静态方法、私有方法、实例构造器和父类方法四类，它们在类加载时就会把符号引用解析为该方法的直接引用。这些方法可以称为非虚方法（还包括 final 方法），与之相反，其他方法就称为虚方法（final 方法除外）。这里要特别说明下 final 方法，虽然调用 final 方法使用的是 invokevirtual 指令，但是由于它无法覆盖，没有其他版本，所以也无需对方发接收者进行多态选择。Java
语言规范中明确说明了 final 方法是一种非虚方法。
解析调用一定是个静态过程，在编译期间就完全确定，在类加载的解析阶段就会把涉及的符号引用转化为可确定的直接引用，不会延迟到运行期再去完成。而分派调用则可能是静态的也可能是动态的，根据分派依据的宗量数（方法的调用者和方法的参数统称为方法的宗量）又可分为单分派和多分派。两类分派方式两两组合便构成了静态单分派、静态多分派、动态单分派、动态多分派四种分派情况。
所有依赖静态类型来定位方法执行版本的分派动作，都称为静态分派，静态分派的最典型应用就是多态性中的方法重载。静态分派发生在编译阶段，因此确定静态分配的动作实际上不是由虚拟机来执行的。下面通过一段方法重载的示例程序来更清晰地说明这种分派机制：
上面代码的执行结果如下：
以上结果的得出应该不难分析。在分析为什么会选择参数类型为 Human 的重载方法去执行之前，先看如下代码：
我们把上面代码中的“Human”称为变量的静态类型，后面的“Man”称为变量的实际类型。静态类型和实际类型在程序中都可以发生一些变化，区别是静态类型的变化仅仅在使用时发生，变量本身的静态类型不会被改变，并且最终的静态类型是在编译期可知的，而实际类型变化的结果在运行期才可确定。
回到上面的代码分析中，在调用 say()方法时，方法的调用者（回忆上面关于宗量的定义，方法的调用者属于宗量）都为 sp 的前提下，使用哪个重载版本，完全取决于传入参数的数量和数据类型（方法的参数也是数据宗量）。代码中刻意定义了两个静态类型相同、实际类型不同的变量，可见编译器（不是虚拟机，因为如果是根据静态类型做出的判断，那么在编译期就确定了）在重载时是通过参数的静态类型而不是实际类型作为判定依据的。并且静态类型是编译期可知的，所以在编译阶段，javac 编译器就根据参数的静态类型决定使用哪个重载版本。这就是静态分派最典型的应用。
动态分派与多态性的另一个重要体现——方法覆写有着很紧密的关系。向上转型后调用子类覆写的方法便是一个很好地说明动态分派的例子。这种情况很常见，因此这里不再用示例程序进行分析。很显然，在判断执行父类中的方法还是子类中覆盖的方法时，如果用静态类型来判断，那么无论怎么进行向上转型，都只会调用父类中的方法，但实际情况是，根据对父类实例化的子类的不同，调用的是不同子类中覆写的方法，很明显，这里是要根据变量的实际类型来分派方法的执行版本的。而实际类型的确定需要在程序运行时才能确定下来，这种在运行期根据实际类型确定方法执行版本的分派过程称为动态分派。
前面给出：方法的接受者（亦即方法的调用者）与方法的参数统称为方法的宗量。但分派是根据一个宗量对目标方法进行选择，多分派是根据多于一个宗量对目标方法进行选择。
为了方便理解，下面给出一段示例代码：
运行结果应该很容易预测到，如下：
我们首先来看编译阶段编译器的选择过程，即静态分派过程。这时候选择目标方法的依据有两点：一是方法的接受者（即调用者）的静态类型是 Father 还是 Child，二是方法参数类型是 Eat 还是 Drink。因为是根据两个宗量进行选择，所以 Java 语言的静态分派属于多分派类型。
再来看运行阶段虚拟机的选择，即动态分派过程。由于编译期已经了确定了目标方法的参数类型（编译期根据参数的静态类型进行静态分派），因此唯一可以影响到虚拟机选择的因素只有此方法的接受者的实际类型是 Father 还是 Child。因为只有一个宗量作为选择依据，所以 Java 语言的动态分派属于单分派类型。
根据以上论证，我们可以总结如下：目前的 Java 语言（JDK1.6）是一门静态多分派、动态单分派的语言。
http://www.cnblogs.com/maowang1991/archive/2013/04/15/3023236.html
大话设计模式
37. JNI的使用
Java通过JNI调用本地方法，而本地方法是以库文件的形式存放的（在Windows平台下是DLL文件形式，在UNIX机器上是SO文件形式）。通过调用本地的库文件的内部方法，使Java可以实现和本地机器的紧密联系，调用系统级的各接口方法
使用的简单流程：
一、Java中所需要做的工作
1、在Java程序中，首先需要在类中声明所调用的库名称，如[java] view
plain copy
static {
System.loadLibrary(“testdll”);
}
这里库的扩展名可以不用写出来，究竟是DLL还是SO，由系统自己判断
2、还需要对将要调用的方法做本地声明，关键字为native。且只需要声明，而不需要具体实现
[java] view
plain copy
public native static void set(int i);
public native static int get();
得到的Java程序如下：TestJNI.java
[java] view
plain copy
public class TestJNI {
static {
System.loadLibrary("testdll");
}
public native static int get();
public native static void set(int i);
public static void main(String[] args) {
testdll test = new testdll();
test.set(10);
System.out.println(test.get());
}
}
3、使用javac TestJNI.java编译它，得到TestJNI.class
再用javah TestJNI，则会在当前目录下生成TestJNI.h文件
注意：用javah命令生成相应h头文件的时候有可能会出现无法找到相应class文件的错误，建议使用如下格式在控制台生成.h头文件
D:\>javah -classpath . testdll
二、C/C++中所需要做的工作
1、打开VC++，新建工程->win32 DLL，在向导中选择空工程。然后编写testdll.cpp文件[cpp] view
plain copy
#include <windows.h>
#include "TestJNI.h"
int i = 0;
JNIEXPORT jint JNICALL Java_testdll_get (JNIEnv *, jclass)
{
return i;
}
JNIEXPORT void JNICALL Java_testdll_set (JNIEnv *, jclass, jint j)
{
i = j;
}
int WINAPI DllMain (HINSTANCE hInstance, DWORD fdwReason, PVOID pvReserved)
{
return TRUE ;
}
说明：
（1）必须有DllMain函数，并且DllMain必须返回TRUE，否则系统将终止程序并弹出一个“启动程序时出错”对话框，其他两个为Java中调用的两个函数的实现，解释见最后的补充
（2）把Java编译生成的TestJNI.h加入到C/C++的工程中，否则上面代码的include "TestJNI.h"无法引用到
2、编译上面的testdll.cpp文件，可以生成testdll.dll文件，但是这过程通常会出现：在TestJNI.h中找不到jni.h
解决方法：把Javajdk中的下面这些.h文件复制一份到Microsoft Visual Studio的安装目录下的\VC\include文件夹下，例如笔者的是D:\Program Files\Microsoft Visual Studio 10.0\VC\include
[plain] view
plain copy
\jdk\include\jni.h
\jdk\include\win32\jawt_md.h
\jdk\include\win32\jni_md.h
三、结合起来
1、生成的DLL文件的名称要跟Java代码中需要调用的testdll一样，如果不同可以修改文件名，这里是testdll.dll2、然后把该dll文件拷贝到TestJNI.class文件的目录下。
3、使用java testdll 运行它，就可以观察到结果
说明：如果运行java testdll 出现错误:“ 找不到或无法加载主类”，可能是环境变量的classpath键值的分号；掉了，一般掉了这个就会出现这种问题
四、最后对TestJNI.h的内容理解补充
[plain] viewplain copy
/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class TestJNI*/
#ifndef _Included_TestJNI
#define _Included_TestJNI
#ifdef __cplusplus
extern "C" {
#endif
/*
* Class: TestJNI
* Method: get
* Signature: ()I
*/
JNIEXPORT jint JNICALL Java_TestJNI_get (JNIEnv *, jclass);
/*
* Class: TestJNI
* Method: set
* Signature: (I)V
*/
JNIEXPORT void JNICALL Java_TestJNI_set (JNIEnv *, jclass, jint);
#ifdef __cplusplus
}
#endif
#endif
在具体实现的时候，我们只关心两个函数原型
JNIEXPORT jint JNICALL Java_TestJNI_get (JNIEnv *, jclass); 和
JNIEXPORT void JNICALL Java_TestJNI_set (JNIEnv *, jclass, jint);
这里JNIEXPORT和JNICALL都是JNI的关键字，表示此函数是要被JNI调用的。而jint是以JNI为中介使JAVA的int类型与本地的int沟通的一种类型，我们可以视而不见，就当做int使用。函数的名称是JAVA_再加上java程序的package路径再加函数名组成的。参数中，我们也只需要关心在JAVA程序中存在的参数，至于JNIEnv*和jclass我们一般没有必要去碰它。
1. 内存模型以及分区，需要详细到每个区放什么。
一、JVM内存模型
JVM主要管理两种类型内存：堆(Heap)和非堆（Permanent区域）。
1、Heap是运行时数据区域，所有类实例和数组的内存均从此处分配。Heap区分两大块，一块是 Young Generation，另一块是Old Generation：
1）在Young Generation中，有一个叫Eden Space的空间，主要是用来存放新生的对象，还有两个Survivor Spaces（from,to），它们的大小总是一样，它们用来存放每次垃圾回收后存活下来的对象。
2）在Old Generation中，主要存放应用程序中生命周期长的内存对象。
2、Permanent区：
Permanent Generation，主要是存储的是java的类信息，包括解析得到的方法、属性、字段等等。永久带基本不参与垃圾回收。Permanent generation 不是Heap的一部。
.
二、内存大小
1、Heap内存分配
JVM初始分配的内存由-Xms指定，默认是物理内存的1/64；
JVM最大分配的内存由-Xmx指 定，默认是物理内存的1/4。
默认空余堆内存小于40%时，JVM 就会增大堆直到-Xmx 的最大限制，可以由 -XX:MinHeapFreeRatio 指定。
默认空余堆内存大于70%时，JVM 会减少堆直到-Xms的最小限制，可以由 -XX:MaxHeapFreeRatio 指定，
2、Permanent区域内存分配
JVM使用-XX:PermSize设置非堆内存初始值，默认是物理内存的1/64；
由XX:MaxPermSize设置最大非堆内存的大小，默认是物理内存的1/4。
三、JVM内存分配过程
1、JVM 会试图为相关Java对象在Eden中初始化一块内存区域。
2、当Eden空间足够时，内存申请结束；否则到下一步。
3、JVM 试图释放在Eden中所有不活跃的对象（这属于1或更高级的垃圾回收）。释放后若Eden空间仍然不足以放入新对象，则试图将部分Eden中活跃对象放入Survivor区。
4、Survivor区被用来作为Eden及Old的中间交换区域，当Old区空间足够时，Survivor区的对象会被移到Old区，否则会被保留在Survivor区。
5、当Old区空间不够时，JVM 会在Old区进行完全的垃圾收集（0级）。
6、完全垃圾收集后，若Survivor及Old区仍然无法存放从Eden复制过来的部分对象，导致JVM无法在Eden区为新对象创建内存区域，则出现”out of memory”错误。
堆里面的分区：Eden，survival from to，老年代，各自的特点。
java对象的创建过程：
对象的创建开始：
虚拟机遇到new 关键字的时候，首先去常量池中寻找有没有这个类的符号引用，并且检查该引用的类是否已经被加载，解析，和初始化过，如果没有则会先执行该类的加载过程， 在通过检查后，虚拟机为该新生对象分配内存。
分配内存：
为对象分配内存有俩种方式：
一种分配方式是“指针碰撞"，在内存规整的时候，已使用的内存在一侧，未使用的内存在一侧时，中间为指示器指针，这个时候的内存分配就是把指示器指针向未使用的区域移动至创建的对象大小相等的距离。
另一种分配方式是“空闲列表”,当内存不规整时，虚拟机必须在不连续的内存空间寻找一块适合对象大小的内存区域，并使用一个列表去维护创建的每一个区域，并更新列表上的记录。
选择那种分配方式是由堆内存是否规整决定，又由所采用的gc是否带有压缩整理功能决定。
当面临并发时时，有可能存在，虚拟机给对象A分配内存时指针还未来得及改变，这个时候同时又有B对象使用指针来分配内存解决这个问题的两种式：
一种是对分配内存空间的操作进行同步处理 ，虚拟机采用的CAS（见http://www.blogjava.net/xylz/archive/2010/07/04/325206.html） 和失败重试的方式保证更新操作的原子性，另一种是把内存分配的动作按照线程划分在不同的空间进行，即每一个线程都在java堆中预先分配一小块内存。又称本地线程分配缓冲(Thread Local Allocation Buffer,简称TLAB)。 TLAB用完时分配新的TLAB 时需要同步锁定操作。虚拟机设置使用TLAB，可以通过-XX:+/UseTLAB参数设定。
初始化对象内存空间：
内存分配完成之后，虚拟机对该对象分到的内存空间初始化为零值（除了对象头），如果使用了TLAB ,这一工作也可以提前至TLAB分配时进行。 初始化零值这一步也是为什么对象刚创建就可以使用的原因。
对象设置：
虚拟机对对象进行设置，比如对象是那个类的实例，对象的哈希值，gc分带年龄等，这些信息都存在对象的头之中。之后就是执行<init>方法，到此类创建结束。
java对象的内存布局：
对象在内存中分三块区域， 对象头，实例数据，对齐填充。
java对象头部分俩个部分：一部分是用来存对象本身的运行时数据，比如：哈希code, gc分带年龄，锁状态标志，线程持有的锁，偏向线程ID,偏向时间戳等
另一部分是类型的指针，指向类元数据，虚拟机通过这个指针确定它属于那个类的实例，查找对象的元数据信息，并不一定需要经过对象本身。
实例数据部分是对象真正存储的有效信息，也是代码中所定义的类型的字段内容，无论是父类还是子类的都需要记录。
对齐填充不是必然存在的，它只是起占位符的作用，HotSpot VM的自动内存管理系统要求对象的起始地址必须是8字节的整数倍，如果不是则需要通过对齐填充来补全。
对象的访问定位：
一种是通过句柄访问，reference中存储的是句柄地址，这种方式首先需要在java堆中划分一块内存作为句柄池，这种方法的好处是，当对象指针发生改变比如：对象被移动，这个时候reference本身不需要改变。
另一种是直接指针访问，reference直接指向java堆中的类对象地址。对象访问在java虚拟机中很频繁，所以第一种方法会造成一定的开销成本。
JAVA 垃圾回收机制
什么是垃圾回收机：释放那些不再持有引用的对象的内存
怎么判断一个对象是否需要收集？
引用计数（最简单古老的方法）：指将资源（可以是对象、内存或磁盘空间等等）的被引用次数保存起来，当被引用次数变为零时就将其释放的过程
对象引用遍历（现在大多数 jvm 使用的方法）：对象引用遍历从一组对象开始，沿着整个对象图上的每条链接，递归确定可到达（reachable）的对象。如果某对象不能从这些根对象的一个（至少一个）到达，则将它作为垃圾收集
几种垃圾回收机制
标记回收法：遍历对象图并且记录可到达的对象，以便删除不可到达的对象，一般使用单线程工作并且可能产生内存碎片
标记-压缩回收法：前期与第一种方法相同，只是多了一步，将所有的存活对象压缩到内存的一端，这样内存碎片就可以合成一大块可再利用的内存区域，提高了内存利用率
复制回收法：把现有内存空间分成两部分，gc运行时，它把可到达对象复制到另一半空间，再清空正在使用的空间的全部对象。这种方法适用于短生存期的对象，持续复制长生存期的对象则导致效率降低。
分代回收发：把内存空间分为两个或者多个域，如年轻代和老年代，年轻代的特点是对象会很快被回收，因此在年轻代使用效率比较高的算法。当一个对象经过几次回收后依然存活，对象就会被放入称为老年的内存空间，老年代则采取标记-压缩算法
4. GC的两种判定方法：引用计数与引用链
怎么判断一个对象是否需要收集？
引用计数（最简单古老的方法）：指将资源（可以是对象、内存或磁盘空间等等）的被引用次数保存起来，当被引用次数变为零时就将其释放的过程
对象引用遍历（现在大多数 jvm 使用的方法）：对象引用遍历从一组对象开始，沿着整个对象图上的每条链接，递归确定可到达（reachable）的对象。如果某对象不能从这些根对象的一个（至少一个）到达，则将它作为垃圾收集
5.GC的三种收集方法：标记清除、标记整理、复制算法的原理与特点，分别用在什么地方，如果让你优化收集方法，有什么思路？
| 注：本文根据《深入理解Java虚拟机》第3章部分内容整理而成。 对象死亡历程 1.基本的mark&sweep是必须的，后续的都是对他的改进， 2.young代理的survivor就是使用了复制算法，避免碎片 3.还有标记整理算法(压缩)，就是将存活的对象移动到一块，空出连续的空间； 4.当然还有分代算法
JDK1.2之前，引用很纯粹，也很狭隘，对描述一些“食之无味，弃之可惜”的对象就显得无能为力。我们希望能描述这样一类对象：当内存空间还足够时，则能保留在内存之中；如果内存在进行垃圾收集后还是非常紧张，则可以抛弃这些对象。很多系统的缓存功能都符合这样的应用场景 强弱等级：强>软（oom之前回收）>弱(每次gc都回收)>虚(仅仅是为了gc的时候发个通知) http://www.congmo.net/blog/2012/07/04/java-death-of-object/ http://book.51cto.com/art/201107/278901.htm
标记-清除（Mark-Sweep）算法是最基础的算法，就如它的名字一样，算法分为”标记”和”清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收掉所有被标记的对象。之所以说它是最基础的收集算法，是因为后续的收集算法都是基于这种思路并对其缺点进行改进而得到的。它主要有两个缺点：一个是效率问题，标记和清楚过程的效率都不高；另外一个是空间问题，标记清楚后会产生大量不连续的内存碎片，空间碎片太多可能会导致，当程序在以后的运行过程中需要分配较大对象时无法找到足够连续的内存空间而不得不提前出发另一次垃圾收集动作。 一幅图足够解释标记-清楚算法，可清晰的看出确实会造成很多内存碎片。 复制算法为了解决效率问题，一种称为复制（Copying）的收集算法就出现了，它将可用内存按容量划分为大小相等的两块，每次只是用其中一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。这样使得每次都是对其中的一块进行内存回收，没存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将员村缩小为原来的一半，未免太高了一点。同样一幅图来说明回收算法在回收前后的内存变化。  现在的商业虚拟机都采用这种收集算法来回收新生代，IBM的专门研究表明，新生代中的对象98%是朝生夕死的，所以并不需要按照1：1的比例来划分内存空间，而是将内存分为一块较大的Eden空间和两块较小的Survivor空间，每次使用Eden和其中的一块Survivor。当回收时，将Eden和Survivor中还存活着的兑现个一次性地拷贝到另外一块Survivor空间上，最后清理掉Eden和刚才用过的Survivor的空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8：1，也就是每次新生代中可用内存空间为整个新生代容量的90%，只有10%的内存是会被浪费的。 标记-整理算法复制手机算法在对象存活率较高时就要执行较多的复制操作，效率将会贬低。更关键的是，如果不想浪费50%的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都100%存活的极端情况，所以在老年代一般不能直接选用这种算法。根据老年代的特点，有人提出了另外一种”标记-整理”算法，标记过程仍然与标记-清楚算法一样，但是后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界意外的内存。 图解标记-整理算法。  分代收集算法当前商业虚拟机的垃圾收集都采用分代收集（Generational Collection）算法，这种算法并没有什么新的思想，只是根据对象的存货周期的不同将内存划分为几块。一般是把Java堆分成新生代和老年代，这样就可以根据各个年代的特点采用最适当的手机算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那么就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用标记-清理或标记-整理算法来进行回收 |
HotSpot JVM收集器
上面有7中收集器，分为两块，上面为新生代收集器，下面是老年代收集器。如果两个收集器之间存在连线，就说明它们可以搭配使用。
Serial(串行GC)收集器
Serial收集器是一个新生代收集器，单线程执行，使用复制算法。它在进行垃圾收集时，必须暂停其他所有的工作线程(用户线程)。是Jvm client模式下默认的新生代收集器。对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。
ParNew(并行GC)收集器
ParNew收集器其实就是serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为与Serial收集器一样。
Parallel Scavenge(并行回收GC)收集器
Parallel Scavenge收集器也是一个新生代收集器，它也是使用复制算法的收集器，又是并行多线程收集器。parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而parallel Scavenge收集器的目标则是达到一个可控制的吞吐量。吞吐量= 程序运行时间/(程序运行时间 + 垃圾收集时间)，虚拟机总共运行了100分钟。其中垃圾收集花掉1分钟，那吞吐量就是99%。Serial Old(串行GC)收集器
Serial Old是Serial收集器的老年代版本，它同样使用一个单线程执行收集，使用“标记-整理”算法。主要使用在Client模式下的虚拟机。Parallel Old(并行GC)收集器
Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。CMS(并发GC)收集器
CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。CMS收集器是基于“标记-清除”算法实现的，整个收集过程大致分为4个步骤：①.初始标记(CMS initial mark)
②.并发标记(CMS concurrenr mark)
③.重新标记(CMS remark)
④.并发清除(CMS concurrent sweep)
其中初始标记、重新标记这两个步骤任然需要停顿其他用户线程。初始标记仅仅只是标记出GC ROOTS能直接关联到的对象，速度很快，并发标记阶段是进行GC ROOTS 根搜索算法阶段，会判定对象是否存活。而重新标记阶段则是为了修正并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间会被初始标记阶段稍长，但比并发标记阶段要短。
由于整个过程中耗时最长的并发标记和并发清除过程中，收集器线程都可以与用户线程一起工作，所以整体来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。
CMS收集器的优点：并发收集、低停顿，但是CMS还远远达不到完美，器主要有三个显著缺点：
CMS收集器对CPU资源非常敏感。在并发阶段，虽然不会导致用户线程停顿，但是会占用CPU资源而导致引用程序变慢，总吞吐量下降。CMS默认启动的回收线程数是：(CPU数量+3) / 4。
CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure“，失败后而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行，伴随程序的运行自热会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在本次收集中处理它们，只好留待下一次GC时将其清理掉。这一部分垃圾称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行，
即需要预留足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分内存空间提供并发收集时的程序运作使用。在默认设置下，CMS收集器在老年代使用了68%的空间时就会被激活，也可以通过参数-XX:CMSInitiatingOccupancyFraction的值来提供触发百分比，以降低内存回收次数提高性能。要是CMS运行期间预留的内存无法满足程序其他线程需要，就会出现“Concurrent Mode Failure”失败，这时候虚拟机将启动后备预案：临时启用Serial
Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。所以说参数-XX:CMSInitiatingOccupancyFraction设置的过高将会很容易导致“Concurrent Mode Failure”失败，性能反而降低。
最后一个缺点，CMS是基于“标记-清除”算法实现的收集器，使用“标记-清除”算法收集后，会产生大量碎片。空间碎片太多时，将会给对象分配带来很多麻烦，比如说大对象，内存空间找不到连续的空间来分配不得不提前触发一次Full GC。为了解决这个问题，CMS收集器提供了一个-XX:UseCMSCompactAtFullCollection开关参数，用于在Full GC之后增加一个碎片整理过程，还可通过-XX:CMSFullGCBeforeCompaction参数设置执行多少次不压缩的Full GC之后，跟着来一次碎片整理过程。
G1收集器
G1(Garbage First)收集器是JDK1.7提供的一个新收集器，G1收集器基于“标记-整理”算法实现，也就是说不会产生内存碎片。还有一个特点之前的收集器进行收集的范围都是整个新生代或老年代，而G1将整个Java堆(包括新生代，老年代)。
垃圾收集器参数总结
-XX:+<option> 启用选项-XX:-<option> 不启用选项
-XX:<option>=<number>
-XX:<option>=<string>
| 参数 | 描述 |
|---|---|
| -XX:+UseSerialGC | Jvm运行在Client模式下的默认值，打开此开关后，使用Serial + Serial Old的收集器组合进行内存回收 |
| -XX:+UseParNewGC | 打开此开关后，使用ParNew + Serial Old的收集器进行垃圾回收 |
| -XX:+UseConcMarkSweepGC | 使用ParNew + CMS + Serial Old的收集器组合进行内存回收，Serial Old作为CMS出现“Concurrent Mode Failure”失败后的后备收集器使用。 |
| -XX:+UseParallelGC | Jvm运行在Server模式下的默认值，打开此开关后，使用Parallel Scavenge + Serial Old的收集器组合进行回收 |
| -XX:+UseParallelOldGC | 使用Parallel Scavenge + Parallel Old的收集器组合进行回收 |
| -XX:SurvivorRatio | 新生代中Eden区域与Survivor区域的容量比值，默认为8，代表Eden:Subrvivor = 8:1 |
| -XX:PretenureSizeThreshold | 直接晋升到老年代对象的大小，设置这个参数后，大于这个参数的对象将直接在老年代分配 |
| -XX:MaxTenuringThreshold | 晋升到老年代的对象年龄，每次Minor GC之后，年龄就加1，当超过这个参数的值时进入老年代 |
| -XX:UseAdaptiveSizePolicy | 动态调整java堆中各个区域的大小以及进入老年代的年龄 |
| -XX:+HandlePromotionFailure | 是否允许新生代收集担保，进行一次minor gc后, 另一块Survivor空间不足时，将直接会在老年代中保留 |
| -XX:ParallelGCThreads | 设置并行GC进行内存回收的线程数 |
| -XX:GCTimeRatio | GC时间占总时间的比列，默认值为99，即允许1%的GC时间，仅在使用Parallel Scavenge 收集器时有效 |
| -XX:MaxGCPauseMillis | 设置GC的最大停顿时间，在Parallel Scavenge 收集器下有效 |
| -XX:CMSInitiatingOccupancyFraction | 设置CMS收集器在老年代空间被使用多少后出发垃圾收集，默认值为68%，仅在CMS收集器时有效，-XX:CMSInitiatingOccupancyFraction=70 |
| -XX:+UseCMSCompactAtFullCollection | 由于CMS收集器会产生碎片，此参数设置在垃圾收集器后是否需要一次内存碎片整理过程，仅在CMS收集器时有效 |
| -XX:+CMSFullGCBeforeCompaction | 设置CMS收集器在进行若干次垃圾收集后再进行一次内存碎片整理过程，通常与UseCMSCompactAtFullCollection参数一起使用 |
| -XX:+UseFastAccessorMethods | 原始类型优化 |
| -XX:+DisableExplicitGC | 是否关闭手动System.gc |
| -XX:+CMSParallelRemarkEnabled | 降低标记停顿 |
| -XX:LargePageSizeInBytes | 内存页的大小不可设置过大，会影响Perm的大小，-XX:LargePageSizeInBytes=128m |
| 新生代GC方式 | 老年代和持久代GC方式 | |
|---|---|---|
| Client | Serial 串行GC | Serial Old 串行GC |
| Server | Parallel Scavenge 并行回收GC | Parallel Old 并行GC |
| 新生代GC方式 | 老年代和持久代GC方式 | |
|---|---|---|
| -XX:+UseSerialGC | Serial 串行GC | Serial Old 串行GC |
| -XX:+UseParallelGC | Parallel Scavenge 并行回收GC | Serial Old 并行GC |
| -XX:+UseConcMarkSweepGC | ParNew 并行GC | CMS 并发GC 当出现“Concurrent Mode Failure”时 采用Serial Old 串行GC |
| -XX:+UseParNewGC | ParNew 并行GC | Serial Old 串行GC |
| -XX:+UseParallelOldGC | Parallel Scavenge 并行回收GC | Parallel Old 并行GC |
| -XX:+UseConcMarkSweepGC -XX:+UseParNewGC | Serial 串行GC | CMS 并发GC 当出现“Concurrent Mode Failure”时 采用Serial Old 串行GC |
首页
所有文章
资讯
Web
架构
基础技术
书籍
教程
我要投稿
更多频道 »
- 导航条 -
首页所有文章
资讯Web
架构基础技术
书籍教程
我要投稿更多频道 »
- iOS- Python
- Android- Web前端
Minor GC、Major GC和Full GC之间的区别
2015/04/24 | 分类： 基础技术 | 0条评论 | 标签： JAVA GC
分享到：5
本文由 ImportNew - 光光头去打酱油 翻译自 javacodegeeks。欢迎加入翻译小组。转载请见文末要求。
在 Plumbr 从事 GC 暂停检测相关功能的工作时，我被迫用自己的方式，通过大量文章、书籍和演讲来介绍我所做的工作。在整个过程中，经常对 Minor、Major、和 Full GC 事件的使用感到困惑。这也是我写这篇博客的原因，我希望能清楚地解释这其中的一些疑惑。
文章要求读者熟悉 JVM 内置的通用垃圾回收原则。堆内存划分为 Eden、Survivor 和 Tenured/Old 空间，代假设和其他不同的 GC 算法超出了本文讨论的范围。
Minor GC
从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor GC。这一定义既清晰又易于理解。但是，当发生Minor GC事件的时候，有一些有趣的地方需要注意到：当 JVM 无法为一个新的对象分配空间时会触发 Minor GC，比如当 Eden 区满了。所以分配率越高，越频繁执行 Minor GC。
内存池被填满的时候，其中的内容全部会被复制，指针会从0开始跟踪空闲内存。Eden 和 Survivor 区进行了标记和复制操作，取代了经典的标记、扫描、压缩、清理操作。所以 Eden 和 Survivor 区不存在内存碎片。写指针总是停留在所使用内存池的顶部。
执行 Minor GC 操作时，不会影响到永久代。从永久代到年轻代的引用被当成 GC roots，从年轻代到永久代的引用在标记阶段被直接忽略掉。
质疑常规的认知，所有的 Minor GC 都会触发“全世界的暂停（stop-the-world）”，停止应用程序的线程。对于大部分应用程序，停顿导致的延迟都是可以忽略不计的。其中的真相就
是，大部分 Eden 区中的对象都能被认为是垃圾，永远也不会被复制到 Survivor 区或者老年代空间。如果正好相反，Eden 区大部分新生对象不符合 GC 条件，Minor GC 执行时暂停的时间将会长很多。
所以 Minor GC 的情况就相当清楚了——每次 Minor GC 会清理年轻代的内存。
Major GC vs Full GC
大家应该注意到，目前，这些术语无论是在 JVM 规范还是在垃圾收集研究论文中都没有正式的定义。但是我们一看就知道这些在我们已经知道的基础之上做出的定义是正确的，Minor GC 清理年轻带内存应该被设计得简单：Major GC 是清理永久代。
Full GC 是清理整个堆空间—包括年轻代和永久代。
很不幸，实际上它还有点复杂且令人困惑。首先，许多 Major GC 是由 Minor GC 触发的，所以很多情况下将这两种 GC 分离是不太可能的。另一方面，许多现代垃圾收集机制会清理部分永久代空间，所以使用“cleaning”一词只是部分正确。
这使得我们不用去关心到底是叫 Major GC 还是 Full GC，大家应该关注当前的 GC 是否停止了所有应用程序的线程，还是能够并发的处理而不用停掉应用程序的线程。
这种混乱甚至内置到 JVM 标准工具。下面一个例子很好的解释了我的意思。让我们比较两个不同的工具 Concurrent Mark 和 Sweep collector (-XX:+UseConcMarkSweepGC)在 JVM 中运行时输出的跟踪记录。
第一次尝试通过 jstat 输出：
基于这些信息，我们可以看到12次 Minor GC 后开始有些和上面不一样了。没有运行两次 Full GC，这不同的地方在于单个 GC 在永久代中不同阶段运行了两次：
最初的标记阶段，用了0.0041705秒也就是4ms左右。这个阶段会暂停“全世界（ stop-the-world）”的事件，停止所有应用程序的线程，然后开始标记。
并行执行标记和清洗阶段。这些都是和应用程序线程并行的。
最后 Remark 阶段，花费了0.0462010秒约46ms。这个阶段会再次暂停所有的事件。
并行执行清理操作。正如其名，此阶段也是并行的，不会停止其他线程。
所以，正如我们从垃圾回收日志中所看到的那样，实际上只是执行了 Major GC 去清理老年代空间而已，而不是执行了两次 Full GC。
如果你是后期做决 定的话，那么由 jstat 提供的数据会引导你做出正确的决策。它正确列出的两个暂停所有事件的情况，导致所有线程停止了共计50ms。但是如果你试图优化吞吐量，你会被误导的。清 单只列出了回收初始标记和最终 Remark 阶段，jstat的输出看不到那些并发完成的工作。
结论
考虑到这种情况，最好避免以 Minor、Major、Full GC 这种方式来思考问题。而应该监控应用延迟或者吞吐量，然后将 GC 事件和结果联系起来。随着这些 GC 事件的发生，你需要额外的关注某些信息，GC 事件是强制所有应用程序线程停止了还是并行的处理了部分事件。
如果你喜欢这篇我们垃圾回收手册的示例篇，那么请关注一下，整个教程将在2015年3月左右发布。
8.几种常用的内存调试工具;jmap、Jconsole、jstack、
9.类加载的五个过程:加载、验证、准备、解析、初始化
首页
所有文章
资讯
Web
架构
基础技术
书籍
教程
我要投稿
更多频道 »
- 导航条 -
首页所有文章
资讯Web
架构基础技术
书籍教程
我要投稿更多频道 »
- iOS- Python
- Android- Web前端
Minor GC、Major GC和Full GC之间的区别
2015/04/24 | 分类： 基础技术 | 0条评论 | 标签： JAVA GC
分享到：5
本文由 ImportNew - 光光头去打酱油 翻译自 javacodegeeks。欢迎加入翻译小组。转载请见文末要求。
在 Plumbr 从事 GC 暂停检测相关功能的工作时，我被迫用自己的方式，通过大量文章、书籍和演讲来介绍我所做的工作。在整个过程中，经常对 Minor、Major、和 Full GC 事件的使用感到困惑。这也是我写这篇博客的原因，我希望能清楚地解释这其中的一些疑惑。
文章要求读者熟悉 JVM 内置的通用垃圾回收原则。堆内存划分为 Eden、Survivor 和 Tenured/Old 空间，代假设和其他不同的 GC 算法超出了本文讨论的范围。
Minor GC
从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor GC。这一定义既清晰又易于理解。但是，当发生Minor GC事件的时候，有一些有趣的地方需要注意到：当 JVM 无法为一个新的对象分配空间时会触发 Minor GC，比如当 Eden 区满了。所以分配率越高，越频繁执行 Minor GC。
内存池被填满的时候，其中的内容全部会被复制，指针会从0开始跟踪空闲内存。Eden 和 Survivor 区进行了标记和复制操作，取代了经典的标记、扫描、压缩、清理操作。所以 Eden 和 Survivor 区不存在内存碎片。写指针总是停留在所使用内存池的顶部。
执行 Minor GC 操作时，不会影响到永久代。从永久代到年轻代的引用被当成 GC roots，从年轻代到永久代的引用在标记阶段被直接忽略掉。
质疑常规的认知，所有的 Minor GC 都会触发“全世界的暂停（stop-the-world）”，停止应用程序的线程。对于大部分应用程序，停顿导致的延迟都是可以忽略不计的。其中的真相就
是，大部分 Eden 区中的对象都能被认为是垃圾，永远也不会被复制到 Survivor 区或者老年代空间。如果正好相反，Eden 区大部分新生对象不符合 GC 条件，Minor GC 执行时暂停的时间将会长很多。
所以 Minor GC 的情况就相当清楚了——每次 Minor GC 会清理年轻代的内存。
Major GC vs Full GC
大家应该注意到，目前，这些术语无论是在 JVM 规范还是在垃圾收集研究论文中都没有正式的定义。但是我们一看就知道这些在我们已经知道的基础之上做出的定义是正确的，Minor GC 清理年轻带内存应该被设计得简单：Major GC 是清理永久代。
Full GC 是清理整个堆空间—包括年轻代和永久代。
很不幸，实际上它还有点复杂且令人困惑。首先，许多 Major GC 是由 Minor GC 触发的，所以很多情况下将这两种 GC 分离是不太可能的。另一方面，许多现代垃圾收集机制会清理部分永久代空间，所以使用“cleaning”一词只是部分正确。
这使得我们不用去关心到底是叫 Major GC 还是 Full GC，大家应该关注当前的 GC 是否停止了所有应用程序的线程，还是能够并发的处理而不用停掉应用程序的线程。
这种混乱甚至内置到 JVM 标准工具。下面一个例子很好的解释了我的意思。让我们比较两个不同的工具 Concurrent Mark 和 Sweep collector (-XX:+UseConcMarkSweepGC)在 JVM 中运行时输出的跟踪记录。
第一次尝试通过 jstat 输出：
基于这些信息，我们可以看到12次 Minor GC 后开始有些和上面不一样了。没有运行两次 Full GC，这不同的地方在于单个 GC 在永久代中不同阶段运行了两次：
最初的标记阶段，用了0.0041705秒也就是4ms左右。这个阶段会暂停“全世界（ stop-the-world）”的事件，停止所有应用程序的线程，然后开始标记。
并行执行标记和清洗阶段。这些都是和应用程序线程并行的。
最后 Remark 阶段，花费了0.0462010秒约46ms。这个阶段会再次暂停所有的事件。
并行执行清理操作。正如其名，此阶段也是并行的，不会停止其他线程。
所以，正如我们从垃圾回收日志中所看到的那样，实际上只是执行了 Major GC 去清理老年代空间而已，而不是执行了两次 Full GC。
如果你是后期做决 定的话，那么由 jstat 提供的数据会引导你做出正确的决策。它正确列出的两个暂停所有事件的情况，导致所有线程停止了共计50ms。但是如果你试图优化吞吐量，你会被误导的。清 单只列出了回收初始标记和最终 Remark 阶段，jstat的输出看不到那些并发完成的工作。
结论
考虑到这种情况，最好避免以 Minor、Major、Full GC 这种方式来思考问题。而应该监控应用延迟或者吞吐量，然后将 GC 事件和结果联系起来。随着这些 GC 事件的发生，你需要额外的关注某些信息，GC 事件是强制所有应用程序线程停止了还是并行的处理了部分事件。
如果你喜欢这篇我们垃圾回收手册的示例篇，那么请关注一下，整个教程将在2015年3月左右发布。
9. 类加载的五个过程：加载、验证、准备、解析、初始化
JVM把class文件加载的内存，并对数据进行校验、转换解析和初始化，最终形成JVM可以直接使用的Java类型的过程就是加载机制。
类从被加载到虚拟机内存中开始，到卸载出内存为止，它的生命周期包括了：加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)、卸载(Unloading)七个阶段，其中验证、准备、解析三个部分统称链接。
加载(装载)、验证、准备、初始化和卸载这五个阶段顺序是固定的，类的加载过程必须按照这种顺序开始，而解析阶段不一定；它在某些情况下可以在初始化之后再开始，这是为了运行时动态绑定特性。值得注意的是：这些阶段通常都是互相交叉的混合式进行的，通常会在一个阶段执行的过程中调用或激活另外一个阶段。
加载+验证+准备+解析+初始化
1、“加载”阶段，虚拟机需要完成以下三件事情：
（1）通过一个类的权限定名来获取定义此类的二进制字节流
（2）将这个字节流所代表的静态存储结构转化为方法去的运行时数据结构
（3）在java堆中生成一个代表这个类的java.lang.Class对象，作为方法去这些数据的访问入口。
2、验证
（1）文件格式验证--验证class文件格式规范，例如： class文件是否已魔术0xCAFEBABE开头 ， 主、次版本号是否在当前虚拟机处理范围之内等
（2）元数据验证--这个阶段是对字节码描述的信息进行语义分析，以保证起描述的信息符合java语言规范要求。验证点可能包括：这个类是否有父类(除了java.lang.Object之外，所有的类都应当有父类)、这个类是否继承了不允许被继承的类(被final修饰的)、如果这个类的父类是抽象类，是否实现了起父类或接口中要求实现的所有方法。
（3）字节码验证--进行数据流和控制流分析，这个阶段对类的方法体进行校验分析，这个阶段的任务是保证被校验类的方法在运行时不会做出危害虚拟机安全的行为.如：保证访法体中的类型转换有效，例如可以把一个子类对象赋值给父类数据类型，这是安全的，但不能把一个父类对象赋值给子类数据类型、保证跳转命令不会跳转到方法体以外的字节码命令上。
（4）符号引用验证--符号引用中通过字符串描述的全限定名是否能找到对应的类、符号引用类中的类，字段和方法的访问性(private、protected、public、default)是否可被当前类访问。
3、准备
准备阶段是正式为类变量分配内存并设置变量初始值的阶段，这些内存都将在方法去中进行分配。
注意：（1）进行内存分配的仅包括类变量（被static修饰的变量），而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在java堆中
（2）初始值是指数据类型的零值，例如：
public static int value = 123;
那么变量value在准备阶段过后的值是0，而不是123，因为这时候尚未开始执行任何java方法。
再看：public static final int value = 123;
final修饰的字段，子啊准备阶段虚拟机就会根据赋值，value的值为123.
4、解析
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程
符号引用：符号引用是一组符号来描述所引用的目标对象，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标对象并不一定已经加载到内存中。
直接引用：直接引用可以是直接指向目标对象的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是与虚拟机内存布局实现相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同，如果有了直接引用，那引用的目标必定已经在内存中存在。
虚拟机规范并没有规定解析阶段发生的具体时间，只要求了在执行anewarry、checkcast、getfield、instanceof、invokeinterface、invokespecial、invokestatic、invokevirtual、multianewarray、new、putfield和putstatic这13个用于操作符号引用的字节码指令之前，先对它们使用的符号引用进行解析，所以虚拟机实现会根据需要来判断，到底是在类被加载器加载时就对常量池中的符号引用进行解析，还是等到一个符号引用将要被使用前才去解析它。
(1)类或接口的解析
(2)字段解析：首先解析出类的方法表的class_index项中索引的字段所属的类或接口的符号引用，然后继续搜索：
先在类本身中查找字段
再在类的实现的接口中查找字段
然后在类的父类中查找字段
否则，查找失败
(3)类方法解析：首先解析出类的方法表的class_index项中索引的方法所属的类或接口的符号引用，然后继续搜索：
类方法和接口方法符号引用的常量类型定义是分开的，如果在类方法表中发现class_index中索引的是个接口，直接报错。
在类中递归查找是否有简单名称和描述符都与目标相匹配的方法，如果有直接返回
在类实现的父类中查找是否有简单名称和描述符都与目标相匹配的方法，如果有直接返回
在类实现的接口列表及他们的父接口中查找是否有简单名称和描述符都与目标相匹配的方法，如果有直接报错
否则，查找失败
(4)接口方法解析：首先解析出类的方法表的class_index项中索引的方法所属的类或接口的符号引用。正好与接口相反。
5、初始化
初始化阶段才真正开始执行类中定义的java程序代码
初始化阶段是执行类构造器<clinit>()方法的过程。在以下四种情况下初始化过程会被触发执行：
1.遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，如果类没有进行过初始化，则需先触发其初始化。生成这4条指令的最常见的java代码场景是：使用new关键字实例化对象、读取或设置一个类的静态字段(被final修饰、已在编译器把结果放入常量池的静态字段除外)的时候，以及调用类的静态方法的时候。
2.使用java.lang.reflect包的方法对类进行反射调用的时候
3.当初始化一个类的时候，如果发现其父类还没有进行过初始化、则需要先出发其父类的初始化
4.jvm启动时，用户指定一个执行的主类(包含main方法的那个类)，虚拟机会先初始化这个类
在准备阶段，变量已经赋过一次系统要求的初始值，二在初始阶段，则是根据程序员通过程序制定的主观计划去初始化类变量和其他资源。
10. 双亲委派模型：Bootstrap ClassLoader、Extension ClassLoader、ApplicationClassLoader
关于Java类加载双亲委派机制的思考（附一道面试题）
预定义类加载器和双亲委派机制
JVM预定义的三种类型类加载器：启动（Bootstrap）类加载器：是用本地代码实现的类装入器，它负责将
<Java_Runtime_Home>/lib下面的类库加载到内存中（比如
rt.jar）。由于引导类加载器涉及到虚拟机本地实现细节，开发者无法直接获取到启动类加载器的引用，所以不允许直接通过引用进行操作。
标准扩展（Extension）类加载器：是由 Sun 的
ExtClassLoader（sun.misc.Launcher$ExtClassLoader）实现的。它负责将
< Java_Runtime_Home >/lib/ext或者由系统变量
java.ext.dir指定位置中的类库加载到内存中。开发者可以直接使用标准扩展类加载器。
系统（System）类加载器：是由 Sun 的
AppClassLoader（sun.misc.Launcher$AppClassLoader）实现的。它负责将系统类路径（
CLASSPATH）中指定的类库加载到内存中。开发者可以直接使用系统类加载器。
除了以上列举的三种类加载器，还有一种比较特殊的类型 — 线程上下文类加载器。
双亲委派机制描述
某个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父类加载器，依次递归，如果父类加载器可以完成类加载任务，就成功返回；只有父类加载器无法完成此加载任务时，才自己去加载。
几点思考
Java虚拟机的第一个类加载器是Bootstrap，这个加载器很特殊，它不是Java类，因此它不需要被别人加载，它嵌套在Java虚拟机内核里面，也就是JVM启动的时候Bootstrap就已经启动，它是用C++写的二进制代码（不是字节码），它可以去加载别的类。这也是我们在测试时为什么发现
System.class.getClassLoader()结果为null的原因，这并不表示System这个类没有类加载器，而是它的加载器比较特殊，是
BootstrapClassLoader，由于它不是Java类，因此获得它的引用肯定返回null。
委托机制具体含义
当Java虚拟机要加载一个类时，到底派出哪个类加载器去加载呢？
首先当前线程的类加载器去加载线程中的第一个类（假设为类A）。
注：当前线程的类加载器可以通过Thread类的getContextClassLoader()获得，也可以通过setContextClassLoader()自己设置类加载器。
如果类A中引用了类B，Java虚拟机将使用加载类A的类加载器去加载类B。
还可以直接调用
ClassLoader.loadClass()方法来指定某个类加载器去加载某个类。
委托机制的意义 — 防止内存中出现多份同样的字节码
比如两个类A和类B都要加载System类：
如果不用委托而是自己加载自己的，那么类A就会加载一份System字节码，然后类B又会加载一份System字节码，这样内存中就出现了两份System字节码。
如果使用委托机制，会递归的向父类查找，也就是首选用Bootstrap尝试加载，如果找不到再向下。这里的System就能在Bootstrap中找到然后加载，如果此时类B也要加载System，也从Bootstrap开始，此时Bootstrap发现已经加载过了System那么直接返回内存中的System即可而不需要重新加载，这样内存中就只有一份System的字节码了。
一道面试题
能不能自己写个类叫java.lang.System？
答案：通常不可以，但可以采取另类方法达到这个需求。
解释：为了不让我们写System类，类加载采用委托机制，这样可以保证爸爸们优先，爸爸们能找到的类，儿子就没有机会加载。而System类是Bootstrap加载器加载的，就算自己重写，也总是使用Java系统提供的System，自己写的System类根本没有机会得到加载。
但是，我们可以自己定义一个类加载器来达到这个目的，为了避免双亲委托机制，这个类加载器也必须是特殊的。由于系统自带的三个类加载器都加载特定目录下的类，如果我们自己的类加载器放在一个特殊的目录，那么系统的加载器就无法加载，也就是最终还是由我们自己的加载器加载。
我们知道，计算机只认识0 和 1, 所以我们写的程序需要被编译器翻译成由0和1构成的二进制格式才能被计算机执行。经过几十年的发展，计算机仍然只能认识0和1，但是由于最近10年内虚拟机及建立在虚拟机之上的大量程序语言如雨后春笋般出现并蓬勃发展，将我们编写的程序编译成二进制本地机器码已不再是唯一的选择，越来越多的语言选择了与操作系统和机器指令集无关的、平台中立的格式作为程序编译后的存储格式。
Java的跨平台性，所谓的“一次编写，到处运行”的原理也就建立在这个基础之上。
所以我们提到的类的加载过程，不是机器码二进制文件的加载，而是Java的字节码形式的Class文件。
Class类文件的结构是怎样的呢？
Class文件是一组以8位字节为基础单位的二进制流，各个数据项目严格按照顺序紧凑地排列在Class文件当中，中间没有添加任何分隔符，这使得整个Class文件中存储的内容几乎全部都是程序运行的必要数据，没有空隙存在。当遇到需要占用8位字节以上空间的数据项时，则会按照高位在前的方式分隔成若干个8位字节进行存储。
大体上分为 魔数，常量池，访问标识，类索引、父类索引、接口索引、字段表集合、方法表集合、属性表集合。
虚拟机把描述类的数据从Class文件加载到内存，并多数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。
与那些在编译时需要进行链接工作的语言不同，在Java语言里面，类型的加载和链接过程都是在程序运行期间完成的（其实C++也是分为静态链接库和动态链接库的），这样会在类加载时稍微增加一些性能开销，但是却能为Java应用程序提供高度的灵活性，Java中天生可以动态扩展的语言特性就是依赖运行期动态加载和动态链接这个特点实现的。例如，如果编写一个使用接口的应用程序，运行时再指定其实际的表现。
类加载过程
类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载七个阶段。其中验证、准备和解析三个部分统称为连接，它们开始的顺序如下图所示：
<img src="https://pic2.zhimg.com/86e2e4a282814a1cd630062e4d29bc6d_b.png" data-rawwidth="559" data-rawheight="159" class="origin_image zh-lightbox-thumb" width="559" data-original="https://pic2.zhimg.com/86e2e4a282814a1cd630062e4d29bc6d_r.png">
<img
src="https://pic1.zhimg.com/821c7fc42e69a78032bec9bb56e47310_b.png" data-rawwidth="820" data-rawheight="279" class="origin_image zh-lightbox-thumb" width="820" data-original="https://pic1.zhimg.com/821c7fc42e69a78032bec9bb56e47310_r.png">
其中类加载的过程包括了加载、验证、准备、解析、初始化五个阶段。在这五个阶段中，加载、验证、准备和初始化这四个阶段发生的顺序是确定的，而解析阶段则不一定，它在某些情况下可以在初始化阶段之后开始，这是为了支持Java语言的运行时绑定（也成为动态绑定或晚期绑定）。另外注意这里的几个阶段是按顺序开始，而不是按顺序进行或完成，因为这些阶段通常都是互相交叉地混合进行的，通常在一个阶段执行的过程中调用或激活另一个阶段。
这里简要说明下Java中的绑定：绑定指的是把一个方法的调用与方法所在的类(方法主体)关联起来，对java来说，绑定分为静态绑定和动态绑定：
静态绑定：即前期绑定。在程序执行前方法已经被绑定，此时由编译器或其它连接程序实现。针对java，简单的可以理解为程序编译期的绑定。java当中的方法只有final，static，private和构造方法是前期绑定的。
动态绑定：即晚期绑定，也叫运行时绑定。在运行时根据具体对象的类型进行绑定。在java中，几乎所有的方法都是后期绑定的。
下面详细讲述类加载过程中每个阶段所做的工作。
加载
加载时类加载过程的第一个阶段，在加载阶段，虚拟机需要完成以下三件事情：
1、通过一个类的全限定名来获取其定义的二进制字节流。
2、将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3、在Java堆中生成一个代表这个类的java.lang.Class对象，作为对方法区中这些数据的访问入口。
注意，这里第1条中的二进制字节流并不只是单纯地从Class文件中获取，比如它还可以从Jar包中获取、从网络中获取（最典型的应用便是Applet）、由其他文件生成（JSP应用）等。
相对于类加载的其他阶段而言，加载阶段（准确地说，是加载阶段获取类的二进制字节流的动作）是可控性最强的阶段，因为开发人员既可以使用系统提供的类加载器来完成加载，也可以自定义自己的类加载器来完成加载。
加载阶段完成后，虚拟机外部的 二进制字节流就按照虚拟机所需的格式存储在方法区之中，而且在Java堆中也创建一个java.lang.Class类的对象，这样便可以通过该对象访问方法区中的这些数据。
说到加载，不得不提到类加载器，下面就具体讲述下类加载器。
类加载器虽然只用于实现类的加载动作，但它在Java程序中起到的作用却远远不限于类的加载阶段。对于任意一个类，都需要由它的类加载器和这个类本身一同确定其在就Java虚拟机中的唯一性，也就是说，即使两个类来源于同一个Class文件，只要加载它们的类加载器不同，那这两个类就必定不相等。这里的“相等”包括了代表类的Class对象的equals（）、isAssignableFrom（）、isInstance（）等方法的返回结果，也包括了使用instanceof关键字对对象所属关系的判定结果。
站在Java虚拟机的角度来讲，只存在两种不同的类加载器：
启动类加载器：它使用C++实现（这里仅限于Hotspot，也就是JDK1.5之后默认的虚拟机，有很多其他的虚拟机是用Java语言实现的），是虚拟机自身的一部分。
所有其他的类加载器：这些类加载器都由Java语言实现，独立于虚拟机之外，并且全部继承自抽象类java.lang.ClassLoader，这些类加载器需要由启动类加载器加载到内存中之后才能去加载其他的类。
站在Java开发人员的角度来看，类加载器可以大致划分为以下三类：
启动类加载器：Bootstrap ClassLoader，跟上面相同。它负责加载存放在JDK\jre\lib(JDK代表JDK的安装目录，下同)下，或被-Xbootclasspath参数指定的路径中的，并且能被虚拟机识别的类库（如rt.jar，所有的java.*开头的类均被Bootstrap ClassLoader加载）。启动类加载器是无法被Java程序直接引用的。
扩展类加载器：Extension ClassLoader，该加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载JDK\jre\lib\ext目录中，或者由java.ext.dirs系统变量指定的路径中的所有类库（如javax.*开头的类），开发者可以直接使用扩展类加载器。
应用程序类加载器：Application ClassLoader，该类加载器由sun.misc.Launcher$AppClassLoader来实现，它负责加载用户类路径（ClassPath）所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
应用程序都是由这三种类加载器互相配合进行加载的，如果有必要，我们还可以加入自定义的类加载器。因为JVM自带的ClassLoader只是懂得从本地文件系统加载标准的java class文件，因此如果编写了自己的ClassLoader，便可以做到如下几点：
1）在执行非置信代码之前，自动验证数字签名。
2）动态地创建符合用户特定需要的定制化构建类。
3）从特定的场所取得java class，例如数据库中和网络中。
事实上当使用Applet的时候，就用到了特定的ClassLoader，因为这时需要从网络上加载java class，并且要检查相关的安全信息，应用服务器也大都使用了自定义的ClassLoader技术。
这几种类加载器的层次关系如下图所示：
<img src="https://pic3.zhimg.com/ad1e4be1cb0d77cdd948336a093dd8a6_b.png" data-rawwidth="212" data-rawheight="438" class="content_image" width="212">
这种层次关系称为类加载器的双亲委派模型。我们把每一层上面的类加载器叫做当前层类加载器的父加载器，当然，它们之间的父子关系并不是通过继承关系来实现的，而是使用组合关系来复用父加载器中的代码。该模型在JDK1.2期间被引入并广泛应用于之后几乎所有的Java程序中，但它并不是一个强制性的约束模型，而是Java设计者们推荐给开发者的一种类的加载器实现方式。
双亲委派模型的工作流程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把请求委托给父加载器去完成，依次向上，因此，所有的类加载请求最终都应该被传递到顶层的启动类加载器中，只有当父加载器在它的搜索范围中没有找到所需的类时，即无法完成该加载，子加载器才会尝试自己去加载该类。
使用双亲委派模型来组织类加载器之间的关系，有一个很明显的好处，就是Java类随着它的类加载器（说白了，就是它所在的目录）一起具备了一种带有优先级的层次关系，这对于保证Java程序的稳定运作很重要。例如，类java.lang.Object类存放在JDK\jre\lib下的rt.jar之中，因此无论是哪个类加载器要加载此类，最终都会委派给启动类加载器进行加载，这边保证了Object类在程序中的各种类加载器中都是同一个类。
验证
验证的目的是为了确保Class文件中的字节流包含的信息符合当前虚拟机的要求，而且不会危害虚拟机自身的安全。不同的虚拟机对类验证的实现可能会有所不同，但大致都会完成以下四个阶段的验证：文件格式的验证、元数据的验证、字节码验证和符号引用验证。
文件格式的验证：验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理，该验证的主要目的是保证输入的字节流能正确地解析并存储于方法区之内。经过该阶段的验证后，字节流才会进入内存的方法区中进行存储，后面的三个验证都是基于方法区的存储结构进行的。
元数据验证：对类的元数据信息进行语义校验（其实就是对类中的各数据类型进行语法校验），保证不存在不符合Java语法规范的元数据信息。
字节码验证：该阶段验证的主要工作是进行数据流和控制流分析，对类的方法体进行校验分析，以保证被校验的类的方法在运行时不会做出危害虚拟机安全的行为。
符号引用验证：这是最后一个阶段的验证，它发生在虚拟机将符号引用转化为直接引用的时候（解析阶段中发生该转化，后面会有讲解），主要是对类自身以外的信息（常量池中的各种符号引用）进行匹配性的校验。
准备
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。对于该阶段有以下几点需要注意：
1、这时候进行内存分配的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在Java堆中。
2、这里所设置的初始值通常情况下是数据类型默认的零值（如0、0L、null、false等），而不是被在Java代码中被显式地赋予的值。
假设一个类变量的定义为：
public static int value = 3；
那么变量value在准备阶段过后的初始值为0，而不是3，因为这时候尚未开始执行任何Java方法，而把value赋值为3的putstatic指令是在程序编译后，存放于类构造器<clinit>（）方法之中的，所以把value赋值为3的动作将在初始化阶段才会执行。
下表列出了Java中所有基本数据类型以及reference类型的默认零值：
<img src="https://pic4.zhimg.com/fb0794ced9fd6f7a09eb52e96adb5b33_b.png" data-rawwidth="348" data-rawheight="431" class="content_image" width="348">
这里还需要注意如下几点：
对基本数据类型来说，对于类变量（static）和全局变量，如果不显式地对其赋值而直接使用，则系统会为其赋予默认的零值，而对于局部变量来说，在使用前必须显式地为其赋值，否则编译时不通过。
对于同时被static和final修饰的常量，必须在声明的时候就为其显式地赋值，否则编译时不通过；而只被final修饰的常量则既可以在声明时显式地为其赋值，也可以在类初始化时显式地为其赋值，总之，在使用前必须为其显式地赋值，系统不会为其赋予默认零值。
对于引用数据类型reference来说，如数组引用、对象引用等，如果没有对其进行显式地赋值而直接使用，系统都会为其赋予默认的零值，即null。
如果在数组初始化时没有对数组中的各元素赋值，那么其中的元素将根据对应的数据类型而被赋予默认的零值。
3、如果类字段的字段属性表中存在ConstantValue属性，即同时被final和static修饰，那么在准备阶段变量value就会被初始化为ConstValue属性所指定的值。
假设上面的类变量value被定义为：
public static final int value = 3；
编译时Javac将会为value生成ConstantValue属性，在准备阶段虚拟机就会根据ConstantValue的设置将value赋值为3。回忆上一篇博文中对象被动引用的第2个例子，便是这种情况。我们可以理解为static
final常量在编译期就将其结果放入了调用它的类的常量池中。
解析
解析阶段是虚拟机将常量池中的符号引用转化为直接引用的过程。在Class类文件结构一文中已经比较过了符号引用和直接引用的区别和关联，这里不再赘述。前面说解析阶段可能开始于初始化之前，也可能在初始化之后开始，虚拟机会根据需要来判断，到底是在类被加载器加载时就对常量池中的符号引用进行解析（初始化之前），还是等到一个符号引用将要被使用前才去解析它（初始化之后）。
对同一个符号引用进行多次解析请求时很常见的事情，虚拟机实现可能会对第一次解析的结果进行缓存（在运行时常量池中记录直接引用，并把常量标示为已解析状态），从而避免解析动作重复进行。
解析动作主要针对类或接口、字段、类方法、接口方法四类符号引用进行，分别对应于常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_InterfaceMethodref_info四种常量类型。
1、类或接口的解析：判断所要转化成的直接引用是对数组类型，还是普通的对象类型的引用，从而进行不同的解析。
2、字段解析：对字段进行解析时，会先在本类中查找是否包含有简单名称和字段描述符都与目标相匹配的字段，如果有，则查找结束；如果没有，则会按照继承关系从上往下递归搜索该类所实现的各个接口和它们的父接口，还没有，则按照继承关系从上往下递归搜索其父类，直至查找结束，查找流程如下图所示：
<img src="https://pic2.zhimg.com/c6aab61c996d47f5a3d339d204e32dcd_b.png" data-rawwidth="577" data-rawheight="161" class="origin_image zh-lightbox-thumb" width="577" data-original="https://pic2.zhimg.com/c6aab61c996d47f5a3d339d204e32dcd_r.png">从下面一段代码的执行结果中很容易看出来字段解析的搜索顺序：
从下面一段代码的执行结果中很容易看出来字段解析的搜索顺序：
class Super{
public static int m = 11;
static{
System.out.println("执行了super类静态语句块");
}
}
class Father extends Super{
public static int m = 33;
static{
System.out.println("执行了父类静态语句块");
}
}
class Child extends Father{
static{
System.out.println("执行了子类静态语句块");
}
}
public class StaticTest{
public static void main(String[] args){
System.out.println(Child.m);
}
}执行结果如下：
执行了super类静态语句块
执行了父类静态语句块
33
如果注释掉Father类中对m定义的那一行，则输出结果如下：
执行了super类静态语句块
11
另外，很明显这就是上篇博文中的第1个例子的情况，这里我们便可以分析如下：static变量发生在静态解析阶段，也即是初始化之前，此时已经将字段的符号引用转化为了内存引用，也便将它与对应的类关联在了一起，由于在子类中没有查找到与m相匹配的字段，那么m便不会与子类关联在一起，因此并不会触发子类的初始化。
最后需要注意：理论上是按照上述顺序进行搜索解析，但在实际应用中，虚拟机的编译器实现可能要比上述规范要求的更严格一些。如果有一个同名字段同时出现在该类的接口和父类中，或同时在自己或父类的接口中出现，编译器可能会拒绝编译。如果对上面的代码做些修改，将Super改为接口，并将Child类继承Father类且实现Super接口，那么在编译时会报出如下错误：
StaticTest.java:24: 对 m 的引用不明确，Father 中的 变量 m 和 Super 中的 变量 m
都匹配
System.out.println(Child.m);
^
1 错误
3、类方法解析：对类方法的解析与对字段解析的搜索步骤差不多，只是多了判断该方法所处的是类还是接口的步骤，而且对类方法的匹配搜索，是先搜索父类，再搜索接口。
4、接口方法解析：与类方法解析步骤类似，知识接口不会有父类，因此，只递归向上搜索父接口就行了。
初始化 初始化是类加载过程的最后一步，到了此阶段，才真正开始执行类中定义的Java程序代码。在准备阶段，类变量已经被赋过一次系统要求的初始值，而在初始化阶段，则是根据程序员通过程序指定的主观计划去初始化类变量和其他资源，或者可以从另一个角度来表达：初始化阶段是执行类构造器<clinit>()方法的过程。
这里简单说明下<clinit>（）方法的执行规则:
1、<clinit>（）方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句中可以赋值，但是不能访问。
2、<clinit>（）方法与实例构造器<init>（）方法（类的构造函数）不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的<clinit>（）方法执行之前，父类的<clinit>（）方法已经执行完毕。因此，在虚拟机中第一个被执行的<clinit>（）方法的类肯定是java.lang.Object。
3、<clinit>（）方法对于类或接口来说并不是必须的，如果一个类中没有静态语句块，也没有对类变量的赋值操作，那么编译器可以不为这个类生成<clinit>（）方法。
4、接口中不能使用静态语句块，但仍然有类变量（final static）初始化的赋值操作，因此接口与类一样会生成<clinit>（）方法。但是接口鱼类不同的是：执行接口的<clinit>（）方法不需要先执行父接口的<clinit>（）方法，只有当父接口中定义的变量被使用时，父接口才会被初始化。另外，接口的实现类在初始化时也一样不会执行接口的<clinit>（）方法。
5、虚拟机会保证一个类的<clinit>（）方法在多线程环境中被正确地加锁和同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>（）方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>（）方法完毕。如果在一个类的<clinit>（）方法中有耗时很长的操作，那就可能造成多个线程阻塞，在实际应用中这种阻塞往往是很隐蔽的。
下面给出一个简单的例子，以便更清晰地说明如上规则：
class Father{
public static int a = 1;
static{
a = 2;
}
}
class Child extends Father{
public static int b = a;
}
public class ClinitTest{
public static void main(String[] args){
System.out.println(Child.b);
}
}执行上面的代码，会打印出2，也就是说b的值被赋为了2。
我们来看得到该结果的步骤。首先在准备阶段为类变量分配内存并设置类变量初始值，这样A和B均被赋值为默认值0，而后再在调用<clinit>（）方法时给他们赋予程序中指定的值。当我们调用Child.b时，触发Child的<clinit>（）方法，根据规则2，在此之前，要先执行完其父类Father的<clinit>（）方法，又根据规则1，在执行<clinit>（）方法时，需要按static语句或static变量赋值操作等在代码中出现的顺序来执行相关的static语句，因此当触发执行Father的<clinit>（）方法时，会先将a赋值为1，再执行static语句块中语句，将a赋值为2，而后再执行Child类的<clinit>（）方法，这样便会将b的赋值为2.
如果我们颠倒一下Father类中“public static int a = 1;”语句和“static语句块”的顺序，程序执行后，则会打印出1。很明显是根据规则1，执行Father的<clinit>（）方法时，根据顺序先执行了static语句块中的内容，后执行了“public static int a = 1;”语句。
另外，在颠倒二者的顺序之后，如果在static语句块中对a进行访问（比如将a赋给某个变量），在编译时将会报错，因为根据规则1，它只能对a进行赋值，而不能访问。
总结 整个类加载过程中，除了在加载阶段用户应用程序可以自定义类加载器参与之外，其余所有的动作完全由虚拟机主导和控制。到了初始化才开始执行类中定义的Java程序代码（亦及字节码），但这里的执行代码只是个开端，它仅限于<clinit>（）方法。类加载过程中主要是将Class文件（准确地讲，应该是类的二进制字节流）加载到虚拟机内存中，真正执行字节码的操作，在加载完成后才真正开始。
作者：郭无心
链接：http://www.zhihu.com/question/29125656/answer/74503568
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
11. 分派：静态分派与动态分派。
本文以Java多态的一些基本特征来谈一下分派调用。
在开始，依旧用常用方式，例子来引入，看一看下面例子的输出：
?
hello, guy!
hello, guy!
没错，程序就是大家熟悉的重载（Overload），而且大家也应该能知道输出结果，但是为什么输出结果会是这个呢？
先来谈一下以下代码的定义：
?
其中，变量的静态类型和动态类型在程序中都可以发生变化，而区别是变量的静态类型是在编译阶段就可知的，但是动态类型要在运行期才可以确定，编译器在编译的时候并不知道变量的实际类型是什么（个人认为可能也是因为要实现多态，所以才会这样设定）。
现在回到代码中，由于方法的接受者已经确定是StaticDispatch的实例sd了，所以最终调用的是哪个重载版本也就取决于传入参数的类型了。
实际上，虚拟机（应该说是编译器）在重载时时通过参数的静态类型来当判定依据的，而且静态类型在编译期就可知，所以编译器在编译阶段就可根据静态类型来判定究竟使用哪个重载版本。于是对于例子中的两个方法的调用都是以Human为参数的版本。
Java中，所有以静态类型来定位方法执行版本的分派动作，都称为静态分派。
再来看动态分派，它和多态的另外一个重要体现有很大的关联，这个体现是什么，可能大家也能猜出，没错，就是重写（override）。
例子如下：
?
hello man!
hello women!
hello women!
这个结果已经没什么好说的了，而虚拟机是如何知道要调用哪个方法的呢？
其实由两次改变man变量的实际类型导致调用函数版本不同，我们就可以知道，虚拟机是根据变量的实际类型来调用重写方法的。
我们也可以从例子中看出，变量的实际类型是在运行期确定的，重写方法的调用也是根据实际类型来调用的。
我们把这种在运行期根据实际类型来确定方法执行版本的分派动作，称为动态分派。
方法解析
Class 文件的编译过程中不包含传统编译中的连接步骤，一切方法调用在 Class 文件里面存储的都只是符号引用，而不是方法在实际运行时内存布局中的入口地址。这个特性给 Java 带来了更强大的动态扩展能力，使得可以在类运行期间才能确定某些目标方法的直接引用，称为动态连接，也有一部分方法的符号引用在类加载阶段或第一次使用时转化为直接引用，这种转化称为静态解析。这在前面的“Java内存区域与内存溢出”一文中有提到。
静态解析成立的前提是：方法在程序真正执行前就有一个可确定的调用版本，并且这个方法的调用版本在运行期是不可改变的。换句话说，调用目标在编译器进行编译时就必须确定下来，这类方法的调用称为解析。
在 Java 语言中，符合“编译器可知，运行期不可变”这个要求的方法主要有静态方法和私有方法两大类，前者与类型直接关联，后者在外部不可被访问，这两种方法都不可能通过继承或别的方式重写出其他的版本，因此它们都适合在类加载阶段进行解析。
Java 虚拟机里共提供了四条方法调用字节指令，分别是：
invokestatic：调用静态方法。
invokespecial：调用实例构造器方法、私有方法和父类方法。
invokevirtual：调用所有的虚方法。
invokeinterface：调用接口方法，会在运行时再确定一个实现此接口的对象。
只要能被 invokestatic 和 invokespecial 指令调用的方法，都可以在解析阶段确定唯一的调用版本，符合这个条件的有静态方法、私有方法、实例构造器和父类方法四类，它们在类加载时就会把符号引用解析为该方法的直接引用。这些方法可以称为非虚方法（还包括 final 方法），与之相反，其他方法就称为虚方法（final 方法除外）。这里要特别说明下 final 方法，虽然调用 final 方法使用的是 invokevirtual 指令，但是由于它无法覆盖，没有其他版本，所以也无需对方发接收者进行多态选择。Java
语言规范中明确说明了 final 方法是一种非虚方法。
解析调用一定是个静态过程，在编译期间就完全确定，在类加载的解析阶段就会把涉及的符号引用转化为可确定的直接引用，不会延迟到运行期再去完成。而分派调用则可能是静态的也可能是动态的，根据分派依据的宗量数（方法的调用者和方法的参数统称为方法的宗量）又可分为单分派和多分派。两类分派方式两两组合便构成了静态单分派、静态多分派、动态单分派、动态多分派四种分派情况。
静态分派
所有依赖静态类型来定位方法执行版本的分派动作，都称为静态分派，静态分派的最典型应用就是多态性中的方法重载。静态分派发生在编译阶段，因此确定静态分配的动作实际上不是由虚拟机来执行的。下面通过一段方法重载的示例程序来更清晰地说明这种分派机制：class Human{
}
class Man extends Human{
}
class Woman extends Human{
}
public class StaticPai{
public void say(Human hum){
System.out.println("I am human");
}
public void say(Man hum){
System.out.println("I am man");
}
public void say(Woman hum){
System.out.println("I am woman");
}
public static void main(String[] args){
Human man = new Man();
Human woman = new Woman();
StaticPai sp = new StaticPai();
sp.say(man);
sp.say(woman);
}
}上面代码的执行结果如下：
I am human I am human
以上结果的得出应该不难分析。在分析为什么会选择参数类型为 Human 的重载方法去执行之前，先看如下代码：
Human man = new Man（）;
我们把上面代码中的“Human”称为变量的静态类型，后面的“Man”称为变量的实际类型。静态类型和实际类型在程序中都可以发生一些变化，区别是静态类型的变化仅仅在使用时发生，变量本身的静态类型不会被改变，并且最终的静态类型是在编译期可知的，而实际类型变化的结果在运行期才可确定。
回到上面的代码分析中，在调用 say()方法时，方法的调用者（回忆上面关于宗量的定义，方法的调用者属于宗量）都为 sp 的前提下，使用哪个重载版本，完全取决于传入参数的数量和数据类型（方法的参数也是数据宗量）。代码中刻意定义了两个静态类型相同、实际类型不同的变量，可见编译器（不是虚拟机，因为如果是根据静态类型做出的判断，那么在编译期就确定了）在重载时是通过参数的静态类型而不是实际类型作为判定依据的。并且静态类型是编译期可知的，所以在编译阶段，javac 编译器就根据参数的静态类型决定使用哪个重载版本。这就是静态分派最典型的应用。
动态分派
动态分派与多态性的另一个重要体现——方法覆写有着很紧密的关系。向上转型后调用子类覆写的方法便是一个很好地说明动态分派的例子。这种情况很常见，因此这里不再用示例程序进行分析。很显然，在判断执行父类中的方法还是子类中覆盖的方法时，如果用静态类型来判断，那么无论怎么进行向上转型，都只会调用父类中的方法，但实际情况是，根据对父类实例化的子类的不同，调用的是不同子类中覆写的方法，很明显，这里是要根据变量的实际类型来分派方法的执行版本的。而实际类型的确定需要在程序运行时才能确定下来，这种在运行期根据实际类型确定方法执行版本的分派过程称为动态分派。
单分派和多分派
前面给出：方法的接受者（亦即方法的调用者）与方法的参数统称为方法的宗量。但分派是根据一个宗量对目标方法进行选择，多分派是根据多于一个宗量对目标方法进行选择。为了方便理解，下面给出一段示例代码：
class Eat{
}
class Drink{
}
class Father{
public void doSomething(Eat arg){
System.out.println("爸爸在吃饭");
}
public void doSomething(Drink arg){
System.out.println("爸爸在喝水");
}
}
class Child extends Father{
public void doSomething(Eat arg){
System.out.println("儿子在吃饭");
}
public void doSomething(Drink arg){
System.out.println("儿子在喝水");
}
}
public class SingleDoublePai{
public static void main(String[] args){
Father father = new Father();
Father child = new Child();
father.doSomething(new Eat());
child.doSomething(new Drink());
}
}运行结果应该很容易预测到，如下：
爸爸在吃饭 儿子在喝水
我们首先来看编译阶段编译器的选择过程，即静态分派过程。这时候选择目标方法的依据有两点：一是方法的接受者（即调用者）的静态类型是 Father 还是 Child，二是方法参数类型是 Eat 还是 Drink。因为是根据两个宗量进行选择，所以 Java 语言的静态分派属于多分派类型。
再来看运行阶段虚拟机的选择，即动态分派过程。由于编译期已经了确定了目标方法的参数类型（编译期根据参数的静态类型进行静态分派），因此唯一可以影响到虚拟机选择的因素只有此方法的接受者的实际类型是 Father 还是 Child。因为只有一个宗量作为选择依据，所以 Java 语言的动态分派属于单分派类型。
根据以上论证，我们可以总结如下：目前的 Java 语言（JDK1.6）是一门静态多分派、动态单分派的语言。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- 大公司的PHP面试题
- php牛逼的面试题分享
- 码农小汪剑指Offer之37-平衡二叉树判定
- 11个提问频率最高的PHP面试题
- 面试题29 数组中出现次数超过一半的数字
- 程序Bug导致了天大的损失，要枪毙程序员吗？
- 面试_java：数组：旋转数组：rotate array(189)
- 面试题28 字符串排列
- 【笔试/面试】SQL 经典面试题
- 摘抄-程序员如何写出杀手级的简历
- PHP新浪面试题及完整答案
- 面试题27 二叉搜索树与双向链表
- 陈皓：一个 fork 的面试题
- 一道JAVA面试，线程安全和静态内部类
- 面试题26 复杂链表的复制
- 数据库基本概念类 面试题
- [leetcode-328]Odd Even Linked List
- 码农小汪-设计模式之-策略模式
- Oralce数据库的优化(面试必问题)
- 让别人舒服的程度决定你路的高度