JVM学习笔记 类加载机制.docx
《JVM学习笔记 类加载机制.docx》由会员分享，可在线阅读，更多相关《JVM学习笔记 类加载机制.docx（18页珍藏版）》请在冰豆网上搜索。
JVM学习笔记类加载机制
JVM学习笔记类加载机制
类加载机制（还需深入）
类从倍加早到虚拟机内存中开始，到卸载出内存位置，它的整个生命周期包括：
加载（Loading）、验证（Vertification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）、卸载（Unloading）7个阶段。
其中验证、准备、解析3个阶段统称为：
连接（Linking）
1类加载过程
1.1加载Loading
加载是类加载过程中的一个阶段。
JVM做三件事：
通过一个类的全限定名来获取定义此类的二进制字节流；
将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构；
在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。
1.2验证Vertification
验证是连接阶段的第一步，这一阶段的目的：
是为了确保Class文件的字节流中包含的信息符合当前JVM的要求，并且不会危害JVM自身的安全。
如果验证到输入的字节流不符合Class文件格式的约束，JVM就会抛出一个java.lang.VertifyError异常或其子类异常。
1.文件格式验证。
第一段要验证字节流是否符合
魔数
主、次版本号
常量池是否有不支持的类型
指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量
Class文件中各个部分及文件本身是否有被删除的或附加的其他信息
……
这阶段的验证是基于二进制字节流进行的，只有通过了这个阶段的验证，字节流才会进入内存的方法区中进行存储。
so…..后面的3个阶段的验证都是基于方法区的存储结构进行的，不会再直接操作字节流。
2.元数据验证
第二阶段是对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求。
这个类是否具有父类（除java.lang.Object类外，所有的类都应有父类）；
这个类的父类是否继承了不允许继承的类（被final修饰的类）；
如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法；
类中的字段、方法是否与父类产生了矛盾（e.g.覆盖了父类的final字段，或者出现不符合规则的方法重载等）
……..
第二阶段主要是对类的元数据信息进行语义校验，保证不存在不符合Java语言规范的元数据信息。
3.字节码验证
第三阶段是整个验证过程中最复杂的一个阶段，主要目的是通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。
在第二阶段对元数据信息中的数据类型做完校验后，这个阶段将对类的方法体进行校验分析，保证被校验类的方法在运行时不会做出危害JVM安全的事件。
e.g.
保证任意时刻操作数栈的数据类型与指定代码序列都能配合工作;
保证跳转至零不会跳转到方法体以外的字节码指令上；
保证方法体中的类型转换时有效的。
……..
如果一个方法体没有通过了字节码验证，那么肯定是有问题；如果通过了，也不能说明其一定就是安全的。
5.符号引用验证
最后一个阶段的校验发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在连接的第三个阶段——解析阶段中发生。
符号引用验证可以看做是是对类自身以外（常量池中的各种符号引用）的信息进行匹配性校验
符号引用通过字符串描述的全限定名是否能找到对应的类
在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段
符号引用中的类、字段、方法的访问性（private,protected,public,default）是否可以被当前类访问
…….
符号引用验证的目的：
确保解析动作能正常执行，如果无法通过符号引用验证，那么将会抛出一个java.lang.IncompatibleClassChangeError异常的子类，如：
java.lang.IllegalAccessError、java.lang.NoSuchFieldError、java.lang.NoSuchMethodError等。
验证阶段很重要，但不是一定必要的（因为对程序运行期没有影响）。
如果所运行的代码（包括自己编写的及第三方包中的代码）都已经被反复使用和验证过，那么在实施阶段就可以考虑使用-Xverify:
none参数来关闭大部分的类验证措施，以缩短JVM类加载的时间。
1.3准备Preparation
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。
注意：
这时候进行内存分配的仅包括：
类变量（被static修饰的变量），不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Javaheap中。
这里说的初始值“通常情况”下是数据类型的零值。
e.g.
publicstaticintvalue=123;
1
那变量value在准备阶段过后的初始值是0，而不是123，因为这时候尚未开始执行任何Java方法，而把value赋值为123的putstatic执行时程序被编译后，存放于类构造器\（）方法之中，所以把value赋值为123的动作将在初始化阶段才会执行。
“特殊情况”：
如果类字段的字段属性中存在ConstantValue属性，那么准备阶段变量value就会被初始化为ConstantValue属性所指定的值，
publicstaticfinalintvalue=123;
1
编译时Javac将会把value生成ConstantValue属性，在准备阶段JVM就会根据ConstantValue的设置将value赋值为123.
1.4解析Resolution
解析阶段是JVM将常量池内的符号引用替换为直接引用的过程。
符号引用（SymbolicReferences）：
符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。
符号引用于JVM的内存布局无关，引用的目标并不一定已经加载到内存中。
各种虚拟机实现的内部布局可以各不相同，但是它们能接受的符号引用必须都是一致的，因为符号引用的字面量形式明确定义在JVM规范的Class文件格式中。
直接引用（DirectReferences）：
直接饮用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。
直接引用是和JVM实现的内存布局相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接饮用一般不会相同。
如果有了直接引用，那引用的目标必定已存在于内存中。
解析的时间并没有做规定，只要发生在xxxx（太多了，自己XX或者看书吧）指定执行之前就可以。
解析动作主要针对：
类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。
（太复杂，待深入…..日后再来补充）
1.5初始化Initialization
类初始化阶段是类加载的最后一步。
前面的加载阶段用户应用程序可以通过自定义类加载器参与之外，其余动作完全由JVM主导控制。
到了初始化阶段，才真正开始执行类中定义的Java程序代码（或者说字节码）
初始化阶段是执行类构造器\（）方法的过程。
特点：
\（）方法是由编译器自动收集类中所有的类变量的赋值动作和静态语句块（static{}）中的语句合并产生的，收集顺序由语句在源文件中出现的顺序决定的。
静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块中可以赋值，但是不能访问。
publicclassTest{
static{
i=0;//给变量赋值正常通过
System.out.println（i）;//这句编译器会提示“非法向前引用”
}
staticinti=1;
}
\（）方法与类的构造函数（或者说实例构造器\（）方法）不同，它不需要显式地调用父类构造器，JVM会保证在子类的\（）方法执行之前，父类的\（）已经执行完毕。
因此在JVM中第一个被执行的\（）一定是java.lang.Object。
由于父类的\（）方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作。
staticclassParent{
publicstaticintA=1;
static{
A=2;
}
}
staticclassSubextendsParent{
publicstaticintB=A;
}
publicstaticvoidmain（String[]args）{
System.out.println（Sub.B）;//字段B的值为2而不是1，因为优先父类的static语句块，而不是子类赋值操作。
}
\（）方法对类和接口来说并不是必须的。
若勒种没有static语句块，也没有对变量的赋值操作，编译器可以不为此类生成\（）方法。
接口中不能使用static语句块，但仍然有变量初始化的赋值操作，因此接口与类一样，也会生\（）方法。
但接口与类不同的是：
执行接口的\（）方法不需要先执行父接口\（）方法。
只有当父接口中定义的变量使用时，父接口才会初始化。
另外，接口的实现类在初始化时也一样不会执行接口的\（）方法。
JVM会保证一个类的\（）方法在多线程环境中被正确的加锁、同步，如果多线程同时去初始化一个类，那么只会有一个线程去执行这个类的\（）方法，其他线程都需要阻塞等待，直到活动线程执行\（）方法完毕。
2类加载器
JVM设计团队把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到JVM外部去实现，以便让应用程序自己决定如何去获取所需的类。
实现这个动作的代码模块称为“类加载器”。
2.1类与类加载器
类加载器虽然只用于实现类的加载动作。
但作用却不限于此。
对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性，每一个类加载器都拥有一个独立的类名称空间。
即：
比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class文件，被同一个虚拟机加载，只要加载它们的类加载器不同，这两个类就必定不相等。
ps：
此处的“相等”，包括代表类的Class对象的equals（）方法、isAssignableFrom（）方法、isInstance（）方法的返回结果，也包括使用instanceof关键字做对象的所属关系判定等情况。
packagemon.util;
importjava.io.IOException;
importjava.io.InputStream;
/**
*@authorDerek.Wu
*@Date2016年09月18日
*/
publicclassClassLoaderTest{
publicstaticvoidfun（）{
System.out.println（"mon.util.ClassLoaderTest.fun（）"）;
}
publicstaticvoidmain（String[]args）throwsException{
ClassLoadermyLoader=newClassLoader（）{
@Override
publicClass
>loadClass（Stringname）throwsClassNotFoundException{
try{
StringfileName=name.substring（name.lastIndexOf（"."）+1）+".class";
InputStreamis=getClass（）.getResourceAsStream（fileName）;
if（is==null）{
returnsuper.loadClass（name）;
}
byte[]b=newbyte[is.available（）];
is.read（b）;
returndefineClass（name,b,0,b.length）;
}catch（IOExceptione）{
thrownewClassNotFoundException（name）;
}
}
};
Objectobj1=myLoader.loadClass（"mon.util.ClassLoaderTest"）.newInstance（）;
System.out.println（obj1.getClass（））;//classmon.util.ClassLoaderTest
System.out.println（obj1instanceofmon.util.ClassLoaderTest）;//false
System.out.println（obj1instanceofjava.lang.Object）;//true
//obj1.fun（）;
Objectobj2=newObject（）;
System.out.println（obj2.getClass（））;//classjava.lang.Object
System.out.println（obj2instanceofObject）;//
//ClassLoaderTestobj3=myLoader.loadClass（"mon.util.ClassLoaderTest"）.newInstance（）;
ClassLoaderTestobj3=newClassLoaderTest（）;
System.out.println（obj3.getClass（））;//classmon.util.ClassLoaderTest
System.out.println（obj3instanceofmon.util.ClassLoaderTest）;//true
System.out.println（obj3instanceofjava.lang.Object）;//
obj3.fun（）;//ok
}
}
Output：
classmon.util.ClassLoaderTest
false
true
classjava.lang.Object
true
classmon.util.ClassLoaderTest
true
true
Somethinginteresting……还需要再深入（TODO）
2.2双亲委派模型
从Java虚拟机的角度来讲，只存在两种不同的类加载器：
启动类加载器（BootstrapClassLoader）,这个类加载器是用C++实现的，是JVM自身的一部分；
所有其它的类加载器，都是由Java语言实现的，独立于JVM外部，并且全部都继承自java.lang.ClassLoader
ps：
还可以划分的更细些。
启动类加载器（BootstrapClassLoader）：
这个类加载器负责将存放在\/lib目录中的，或者被-Xbootclasspath参数指定的路径中的，并且是虚拟机是别的（仅按照文件名识别，如rt.jar，名词不符合即使放在lib目录也不会被加载）类库加载到虚拟机内存中。
启动类加载器无法被Java程序直接引用，用户在编写自定义加载器时，如果需要把加载请求委派给引导类加载器（BootsstrapClassLoader），那直接使用null代替（见java.lang.Class.getClassLoader（）,ps:
深入理解JVM中说，此方法在java.lang.ClassLoader中，可是我只在java.lang.Class中找到，不知道是否是因为JDK版本的原因，我的JDK版本是1.8.0_91）即可。
/**
*Returnstheclassloaderfortheclass.Someimplementationsmayuse
*nulltorepresentthebootstrapclassloader.Thismethodwillreturn
*nullinsuchimplementationsifthisclasswasloadedbythebootstrap
*classloader.
*
*
Ifasecuritymanagerispresent,andthecaller'sclassloaderis
*notnullandthecaller'sclassloaderisnotthesameasoranancestorof
*theclassloaderfortheclasswhoseclassloaderisrequested,then
*thismethodcallsthesecuritymanager's{@codecheckPermission}
*methodwitha{@codeRuntimePermission（"getClassLoader"）}
*permissiontoensureit'soktoaccesstheclassloaderfortheclass.
*
*
Ifthisobject
*representsaprimitivetypeorvoid,nullisreturned.
*
*@returntheclassloaderthatloadedtheclassorinterface
*representedbythisobject.
*@throwsSecurityException
*ifasecuritymanagerexistsandits
*{@codecheckPermission}methoddenies
*accesstotheclassloaderfortheclass.
*@seejava.lang.ClassLoader
*@seeSecurityManager#checkPermission
*@seejava.lang.RuntimePermission
*/
@CallerSensitive
publicClassLoadergetClassLoader（）{
ClassLoadercl=getClassLoader0（）;
if（cl==null）
returnnull;
SecurityManagersm=System.getSecurityManager（）;
if（sm!
=null）{
ClassLoader.checkClassLoaderPermission（cl,Reflection.getCallerClass（））;
}
returncl;
}
扩展类加载器（ExtensionClassLoader）:
这个加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载\/lib/ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库。
开发者可直接使用。
应用程序类加载器（ApplicationClassLoader）：
这个类加载器由sun.misc.Launcher$AppClassLoader实现。
由于这个类加载器是ClassLoader中的getSystemClassLoader（）方法的返回值，所以一般也称为：
系统类加载器。
负责加载用户类路径（ClassPath）上所指定的类库，开发者可以直接使用这个类加载器。
如果应用程序没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
java.lang.ClassLoader.getSystemClassLoader（）如下：
/**
*Returnsthesystemclassloaderfordelegation.Thisisthedefault
*delegationparentfornewClassLoaderinstances,andis
*typicallytheclassloaderusedtostarttheapplication.
*
*
Thismethodisfirstinvokedearlyintheruntime'sstartup
*sequence,atwhichpointitcreatesthesystemclassloaderandsetsit
*asthecontextclassloaderoftheinvokingThread.
*
*
Thedefaultsystemclassloaderisanimplementation-dependent
*instanceofthisclass.
*
*
Ifthesystemproperty"java.system.class.loader"isdefined
*whenthismethodisfirstinvokedthenthevalueofthatpropertyis
*takentobethenameofaclassthatwillbereturnedasthesystem
*classloader.Theclassisloadedusingthedefaultsystemclassloader
*andmustdefineapublicconstructorthattakesasingleparameterof
*typeClassLoaderwhichisusedasthedelegationparent.An
*instanceisthencreatedusingthisconstructorwiththedefaultsystem
*classloaderastheparameter.Theresultingclassloaderisdefined
*tobethesystemclassloader.
*
*
Ifasecuritymanagerispresent,a
升级会员 