JVM入门（二）

jvm组成部分

类加载器的classLoader的角色

通过getClassLoader方法得到具体的类加载器，通过Car Class这个类模板来实例化不同的car实例。类加载器只负责从文件系统或者网络中加载class文件，至于它是否可以运行由Execution Engine决定。

类加载过程

加载（loading）

1.通过一个类的全限定名（绝对路径）获取定义此类的二进制字节流
2.将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
3.在内存中生成一个代表这个类的java.lang.class对象，作为方法区这个类的各种数据的访问入口

链接（linking）

链接包括三个阶段：
①：验证（Verify）
其目的在于确保class文件的字节流中包含信息符合当前虚拟机要求，保证被夹在类的正确性，不会因为人为恶意篡改class文件以致危害虚拟机安全，
②：准备（Prepare）
为类变量分配内存并且设置该类变量的默认初始值，int 默认为0，boolean默认为false等等，即所谓的零值。
这里不包含用final修饰的static变量，毕竟这种变量相当于是常量，它在编译时候就已经初始化完毕了，也不会为实例变量（对象）分配初始化。
③：解析（Resolve）
将常量池中的符号引用转换为直接引用的过程。
事实上，解析操作往往会伴随着jvm在执行完初始化之后再执行
符号引用就是一组符号来描述所引用的目标，符号引用的字面量形式明确定定义再《java虚拟机规范》的class文件格式中，直接引用就是直接指向目标的指针，相对偏移量或一个间接定位到目标的句柄。
解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等，对应常量池中的CONSTANT_CLASS_INFO、CONSTANT_Filedref_info、CONSTANT_Methodref_info等。
后面再字节码文件讲解时候会详细说

初始化

类初始化阶段是类加载过程的最后一步。在类加载过程中，除了在加载阶段可以通过自定义加载器参与之外，其余动作完全由虚拟机主导和控制，到了初始化阶段，才真正开始执行类中定义的Java程序代码（或者说是字节码）。

    虚拟机规范严格规定了有且只有5种情况必须立即对类进行初始化：

1.遇到new、getstatic、putstatic、invokestatic这4条字节码指令时，如果类尚未初始化，则需要先触发其初始化。即：使用new关键字实例化对象时，读取或设置一个类的静态字段时（final修饰、已在编译期把结果放入常量池的静态字段除外），调用一个类的静态方法的时候。
2.使用java.lang.reflect包的方法对类进行反射调用的时候，如果类尚未初始化，则需要先触发其初始化。
3.初始化一个类的时候，发现其父类尚未初始化，则需要先触发其父类的初始化。
4.当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的类），虚拟机会先初始化这个主类。
5.使用JDK1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类尚未初始化，则需要先触发其初始化。
这5种场景中的行为称为对一个类进行主动引用；除此之外所有引用类的方式都不会触发初始化，称为被动引用。
常量在编译阶段会存入调用类的常量池中，本质上没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。

问题：new一个对象的过程中发生了什么？
首先jvm会判断内存中有没有加载该类，如果加载了，那么直接使用已经加载的类，如果是首次加载就按照上面的方式进行类的加载。

类加载器

启动类加载器（引导类加载器，bootstrap classloader）

①：这个类加载是使用C/C++语言实现的，嵌套再JVM内部
②：它用来加载java的核心类库（JAVA_HOME/jre/lib/rt.jar、resources.jar或者sun.boot.class.path路径下的内容），用于提供JVM自身需要的类
③：没有上级加载器
④：加载扩展类和应用程序类加载器，并指定为他们的上级加载器
⑤：启动类加载器值加载包名为java、javax、sun等开头的类

再concurrentHashMap中，会获取当前类的类加载器，如果是启动类加载器那么就可以生成Unsafe实例，可以调用Unsafe方法，扩展类加载器和应用程序类加载器就无法生成unsafe实例，不能调用unsafe方法。

扩展类加载器（Extension ClassLoader）

①：java语言编写
②：上级加载器为启动类加载器
③：从java.ext.dirs系统属性所指定的目录中加载类库，或从jdk的安装目录的jre/lib/ext子目录下，也会自动由扩展类加载器加载。

应用程序类加载器(系统类加载器，AppClassLoader)

①：java语言编写
②：上级加载器为启动类加载器
③：负责加载环境变量classpath或者系统属性，java.class.path指定路径下的类库，一般来说，java应用类都是由它来完成

自定义类加载器

1.防止源码泄露
类加载器生成的字节码文件是很容易被其他人反编译获取到源码的，要想代码不被泄露，就得在类加载器中做加密处理。
下面是tomcat的使用自定义类加载器的原因，可以借来参考参考
a)、要保证部署在tomcat上的每个应用依赖的类库相互独立，不受影响。
b)、由于tomcat是采用java语言编写的，它自身也有类库依赖，为了安全考虑，tomcat使用的类库要与部署的应用的类库相互独立。
c)、有些类库tomcat与部署的应用可以共享，比如说servlet-api，使用maven编写web程序时，servlet-api的范围是provided，
表示打包时不打包这个依赖，因为我们都知道服务器已经有这个依赖了。
d)、部署的应用之间的类库可以共享。这听起来好像与第一点相互矛盾，但其实这很合理，类被类加载器加载到虚拟机后，
会生成代表该类的class对象存放在永久代区域，这时候如果有大量的应用使用spring来管理，如果spring类库不能共享，
那每个应用的spring类库都会被加载一次，将会是很大的资源浪费。

对类加载器的引用

JVM必须知道一个类型是有启动类加载器加载还是由用户类加载器（包括扩展类和应用程序类）加载的。**如果一个类型是由用户类加载器加载的，那么jvm会将这个类加载器的一个引用作为类型信息的一部分保存在方法区中。**当解析一个类型到另一个类型的引用的时候，JVM需要保证这两个类型的类加载器是相同的。

双亲委派机制

java虚拟机对class字节码文件采用按需加载的方式，也就是说当需要的使用该类的时候才会将它的class字节码文件加载到内存生成class对象，而且加载某个类的class字节码文件时，java虚拟机采用的是双亲委派机制，即把请求交由父类加载器（并非真正的父类，说上级加载器更合适）处理，它是一种任务委派模式。

实例：
在java.lang包下新建一个String类，如下：

附：静态代码块在类创建的时候就会运行，只会运行一次

运行Stringtest类后发现，静态代码块代码并没有执行，什么原因？
类加载器的问题。
虽然String类，是使用我们自定义的，但是加载它的类加载器还是启动类加载器，所以它加载的还是jdk中的String类，而非我们写的类。

如果我们自定义一个java.lang包，而且写一个类去运行，如上图，会出现什么情况？
如下，会爆出异常

由于它是java.lang包下的文件，所以可以知道它是被启动类加载器加载的，启动类加载器明显不会随意加载任何一个类，它只负责核心类的加载，所以jvm禁止用户以java.lang为包路径。
为了不让程序员随便起包名，项目组一般都会以项目或者公司的英文缩写为包名的部分，这样也避免了上图的异常

在jvm中表示两个class对象是否为同一个类存在两个必要条件：
1.类的完整类名必须一致，包括包名
2.加载这个类的classLoader必须相同
换句话说，在jvm中，即使这两个类对象（class对象）来源同一个Class文件，被同一个虚拟机加载，但只要加载他们的classLoader实例对象不同，那么这两个类对象也是不相等的。

问题：如果有人故意弄破坏，自定义一个java.lang.String的类，想让jdk中的String类失效，实际会发生什么，jvm是如何防止这种问题的？
如上所述，jvm会因为使用启动类加载器从而去加载jdk中的核心String类，而不会使用应用程序类加载器去加载用户自定义的类，所以自定义的String是失效的。