类的生命周期

我们用编译器写的代码是.java文件，有一门课叫编译原理，.java文件经过编辑生成.class文件，类加载，指的是从.class文件如何加载到内存并被JVM识别的过程。

类加载的过程一般分为5步，各步一般有序进行，但会有交叉重合 加载、验证、准备、链接、初始化

加载： 将类的.class文件中的二进制数据读入到内存中，将其放在运行时数据区的方法区内，然后在堆区创建一个java.lang.Class对象，用来封装类在方法区内的数据结构。 类的加载的最终产品是位于堆区中的Class对象，Class对象封装了类在方法区内的数据结构，并且向Java程序员提供了访问方法区内的数据结构的接口。 类加载器不需要等到类使用时再去加载，但也会预先加载部分类，如果在预先加载的过程中遇到了.class文件缺失或存在错误，类加载器必须在程序首次动使用该类时才报告错误。 加载阶段，JVM做了三件事情 1).通过一个类的全限定名称来获取定义此类的二进制字节流。 2).将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。 3).在java堆中生成一个代表这个类的java.lang.Class对象，作为方法区这些数据的访问入口。

验证： 确保Class文件中的字节流包含的信息符合当前虚拟机的要求，而且不会危害虚拟机自身的安全。 1）文件格式的验证：验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理，该验证的主要目的是保证输入的字节流能正确地解析并存储于方法区之内。经过该阶段的验证后，字节流才会进入内存的方法区中进行存储，后面的三个验证都是基于方法区的存储结构进行的。 2）元数据验证：对类的元数据信息进行语义校验（其实就是对类中的各数据类型进行语法校验），保证不存在不符合Java语法规范的元数据信息。 3）字节码验证：该阶段验证的主要工作是进行数据流和控制流分析，对类的方法体进行校验分析，以保证被校验的类的方法在运行时不会做出危害虚拟机安全的行为。 4）符号引用验证：这是最后一个阶段的验证，它发生在虚拟机将符号引用转化为直接引用的时候（解析阶段中发生该转化，后面会有讲解），主要是对类自身以外的信息（常量池中的各种符号引用）进行匹配性的校验。

准备： 正式为类变量分配内存并设置类变量(static变量)初始值的阶段，这些内存都将在方法区中进行分配。 1）这时候进行内存分配的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在Java堆中。 2）这里所设置的初始值通常情况下是数据类型默认的零值（如0、0L、null、false等），而不是被在Java代码中被显式地赋予的值。

解析： 虚拟机将常量池内的符号引用替换为直接引用的过程。 符号引用（Symbolic Reference）： 符号引用以一组符号来描述所引用的目标，符号引用可以是任何形式的字面量，符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经在内存中。 直接引用（Direct Reference）： 可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。 同一个符号引用在不同的虚拟机实例上翻译出来的直接引用一般都不相同，如果有了直接引用，那引用的目标必定已经在内存中存在。

初始化： 初始化阶段是类加载过程的最后一步。初始化，为类的静态变量赋予正确的初始值。 前面的类加载过程中，除了加载（Loading）阶段用户应用程序可以通过自定义类加载器参与之外，其余动作完全由虚拟机主导和控制。 到了初始化阶段，才真正开始执行类中定义的Java程序代码。 ①声明类变量时指定初始值 ②使用静态代码块为类变量指定初始值 1)、假如这个类还没有被加载和连接，则程序先加载并连接该类 2)、假如该类的直接父类还没有被初始化，则先初始化其直接父类 3)、假如类中有初始化语句，则系统依次执行这些初始化语句 4）、类构造器方法与类的构造函数不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的类构造器方法执行之前，父类的类构造器方法已经执行完毕。 5）、类构造器方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的，编译器收集的顺序由语句在源文件中出现的顺序所决定。 6）、虚拟机会保证一个类的类构造器方法在多线程环境中被正确地加锁和同步。如果有多个线程去同时初始化一个类，那么只会有一个线程去执行这个类的类构造器方法，其它线程都需要阻塞等待，直到活动线程执行类构造器方法完毕。如果在一个类的类构造器方法中有耗时很长的操作，那么就可能造成多个进程阻塞。

结束生命周期： 1). 执行了System.exit()方法 2). 程序正常执行结束 3). 程序在执行过程中遇到了异常或错误而异常

触发类初始化的条件： 1、创建类的实例，也就是new的方式 2、访问某个类或接口的静态变量，或者对该静态变量赋值 3、调用类的静态方法 4、反射（如Class.forName(“com.shengsiyuan.Test”)） 5、初始化某个类的子类，则其父类也会被初始化 6、Java虚拟机启动时被标明为启动类的类（Java Test），直接使用java.exe命令来运行某个主类 注意一下： 1、子类调用父类的静态变量，子类不会被初始化。只有父类被初始化。。对于静态字段，只有直接定义这个字段的类才会被初始化. 2、通过数组定义来引用类，不会触发类的初始化 3、 访问类的常量，不会初始化类

1.类从顶至底的顺序初始化，所以声明在顶部的字段的早于底部的字段初始化 2.超类早于子类和衍生类的初始化 3.如果类的初始化是由于访问静态域而触发，那么只有声明静态域的类才被初始化，而不会触发超类的初始化或者子类的 4.初始化即使静态域被子类或子接口或者它的实现类所引用。 5.接口初始化不会导致父接口的初始化。 6.静态域的初始化是在类的静态初始化期间，非静态域的初始化时在类的实例创建期间。这意味这静态域初始化在非静态域之前。 7.非静态域通过构造器初始化，子类在做任何初始化之前构造器会隐含地调用父类的构造器，他保证了非静态或实例变量（父类）初始化早于子类

如果类还没有被加载： 1、先执行父类的静态代码块和静态变量初始化，并且静态代码块和静态变量的执行顺序只跟代码中出现的顺序有关。 2、执行子类的静态代码块和静态变量初始化。 3、执行父类的实例变量初始化 4、执行父类的构造函数 5、执行子类的实例变量初始化 6、执行子类的构造函数 如果类已经被加载： 则静态代码块和静态变量就不用重复执行，再创建类对象时，只执行与实例相关的变量初始化和构造方法。 https://blog.csdn.net/mrzhoug/article/details/51581994

什么是类加载器？ JVM设计者把类加载阶段中的“通过’类全名’来获取定义此类的二进制字节流”这个动作放到Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需要的类。实现这个动作的代码模块称为“类加载器”。 对于任何一个类，需要由加载这个类的类加载器和这个类确定唯一性，也就是说，两个类来源于同一个Class文件，并且被同一个类加载器加载，这两个类才相等。

双亲委派模型： 类加载器对虚拟机来说，只有两种： 启动类加载器（Bootstrap ClassLoader），该类加载器使用C++语言实现，属于虚拟机自身的一部分。 其它类加载器： 由Java语言实现，独立于JVM外部，并且全部继承自抽象类java.lang.ClassLoader。

1. bootstraploader： bootstrap加载器，是c++编写的，在java虚拟机启动后初始化，用于加载%java_home%/jre/lib及%java_home%/jre/classes指定的类。如果名称不符合的类库即使放在lib目录中也不会被加载。该类加载器无法被Java程序直接引用。 2.ExtClassLoader 是由java代码编写的，由bootstraploader加载并在加载时将其父加载器设置为bootstraClassloader。主要用于加载%JAVA_HOME%/jre/ext路径下的所有classes目录一级java.ext.dirs系统变量指定的路径中的类库。 3.AppClassloader: 是由java代码编写的，由ExtClassLoader进行加载并将其父加载器设置为ExtClassLoader。classloader的getSystemClassLoader方法获得的就是该加载器。该加载器主要用于加载classpath指定路径下的jar或者class类。这也是java程序默认的类加载器。

双亲委派模型的工作过程为： 如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的加载器都是如此， 因此所有的类加载请求都会传给顶层的启动类加载器，只有当父加载器反馈自己无法完成该加载请求（该加载器的搜索范围中没有找到对应的类）时，子加载器才会尝试自己去加载。

为什么使用双亲委派模型？ https://www.javatt.com/p/65425 上级类加载器加载的类在所有子级类加载器中是共享的。 保证同一个类无论是什么加载器来加载，在JVM中都只会是一个类，保证类结构不出现混乱的情况。 在java虚拟机中，已classloader加类的全限定名来作为类在JVM中的唯一标识。 双亲委派模型保证了classloader之间的交互性，上级类加载器加载的类在所有子级类加载器中是共享的。

自定义类加载器？ 继承java.lang.ClassLoader 类，并且重写其findClass()方法即可。 JDK1.2之后，双亲委派模式已经被引入到类加载体系中，自定义类加载器时不需要在自己写双亲委派的逻辑，因此不鼓励重写loadClass方法，而推荐重写findClass方法。

双亲委派模式很好地解决了各个类加载器的基础类统一问题，越基础的类由越上层的类加载器进行加载，但是这个基础类统一有一个不足，当基础类想要调用回下层的用户代码时无法委派子类加载器进行类加载。 为了解决这个问题JDK引入了ThreadContext线程上下文，通过线程上下文的setContextClassLoader方法可以设置线程上下文类加载器。

只要加载它的类加载器不相同，那么这两个类必定不相等(这里的相等包括代表类的Class对象的equals()方法、isAssignableFrom()方法、isInstance()方法和instanceof关键字的结果)

双亲委派模式的好处？ 采用双亲委派模式的是好处是Java类随着它的类加载器一起具备了一种带有优先级的层次关系，通过这种层级关可以避免类的重复加载，当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次。 其次是考虑到安全因素，java核心api中定义类型不会被随意替换。 假设通过网络传递一个名为java.lang.Integer的类，通过双亲委托模式传递到启动类加载器，而启动类加载器在核心Java API发现这个名字的类，发现该类已被加载，并不会重新加载网络传递的过来的java.lang.Integer，而直接返回已加载过的Integer.class，这样便可以防止核心API库被随意篡改。

ClassLoader 隔离：一个运行程序中有没有可能同时存在两个包名和类名完全一致的类。 如果这两个”类”不是由一个 ClassLoader 加载，是无法将一个类的示例强转为另外一个类的，这就是 ClassLoader 隔离

面试题：能不能自己写个类叫java.lang.System？ 答案：通常不可以，但可以采取另类方法达到这个需求。 解释：为了不让我们写System类，类加载采用委托机制，这样可以保证爸爸们优先，爸爸们能找到的类，儿子就没有机会加载。而System类是Bootstrap加载器加载的，就算自己重写，也总是使用Java系统提供的System，自己写的System类根本没有机会得到加载。 但是，我们可以自己定义一个类加载器来达到这个目的，为了避免双亲委托机制，这个类加载器也必须是特殊的。由于系统自带的三个类加载器都加载特定目录下的类，如果我们自己的类加载器放在一个特殊的目录，那么系统的加载器就无法加载，也就是最终还是由我们自己的加载器加载。

为什么修改代码需要重启进程？ jvm类加载机制方式主要有一下三种： 全盘负责：当一个加载器加载某个class时，该class依赖的其它class也由该加载器去加载，除非制定 双亲委托：先让父类加载器去尝试加载 缓存机制：缓存机制保证所有加载过的class都会被缓存，当程序使用某个class时，需要先在内存中查询，如果查询不到，才会读取该类对应的二级制数据，转化为class对象，放进内存中。 这也是为什么修改class文件必须重启jvm的原因。 OSGI（代码热部署） 近年来的热码替换，模块热部署等应用要求不用重启java虚拟机就可以实现代码模块的即插即用，催生了OSGi技术，在OSGi中类加载器体系被发展为网状结构。OSGi也没有完全遵循双亲委派模型。

java agent 探针技术，实现不重启应用做到热部署代码 https://blog.csdn.net/catoop/article/details/51034778

Class.forName()和ClassLoader.loadClass()区别？ Class.forName()：将类的.class文件加载到jvm中之外，还会对类进行解释，执行类中的static块； ClassLoader.loadClass()：只干一件事情，就是将.class文件加载到jvm中，不会执行static中的内容,只有在newInstance才会去执行static块。

变量的加载顺序： https://www.cnblogs.com/chanshuyi/p/the_java_class_load_mechamism.html

启动类加载器bootstrap、扩展类ext加载器、系统类加载器的关系是什么？ https://cloud.tencent.com/developer/article/1674553 类加载器之间的关系是委派关系，ClassLoader提供了一个URLClassLoader实现类，该类是系统类加载器和扩展类加载器的父类。 ExtClassLoader和AppClassLoader都是Launcher的静态内部类，继承自URLClassLoader，URLClassLoader继承自SecureClassLoader，SecureClassLoader继承自ClassLoader，ClassLoader是抽象类 URLClassLoader支持从jar包和文件夹获取class，加载时首先去classloader里判断是否由启动类加载器加载过。

URLClassLoader可以加载任意路径下的类(ClassLoader只能加载classpath下面的类)。 https://blueblue233.github.io/blog/e65bc81c/ 如果你未接触URLClassLoader，那么要实现动态加载类都是使用用Class.forName()这个方法，但是这个方法只能创建程序中已经引用的类，如果我们需要动态加载程序外的类，Class.forName()是不够的，这个时候就是需要使用URLClassLoader的时候。

https://blog.csdn.net/Hsuxu/article/details/9323731 一个ClassLoader子类有且只有一个父类加载器，多个ClassLoader子类的父类加载器可以是同一个 类加载器可以分为两类：一是引导类装载器（c++实现，非ClassLoader的实例，用于加载java类库中的类）； 二是自定义类装载器（即所有继承了java.lang.ClassLoader的类加载器，它们本身是由引导类装载器装载进jvm的）. 在现在的JRE中，已经自带了一些自定义类加载器，常见且有名的有：扩展类装载器（其父类加载器为引导类加载器，用于加载jre的lib/ext目录中的类），系统类加载器（其父类加载器为扩展类加载器，用于加载classpath中的类）

不同的装载器装载同一个类后，他们的对象不能赋值给对方的引用

如何打破双亲委托机制？ https://cloud.tencent.com/developer/article/1706850 打破就是指把本来需要向父类加载器传递的对象由当前加载器首先去尝试加载，只需要重写其loadClass方法，实现逻辑为立即加载这个路径

java默认的线程上下文类加载器是 系统类加载器(AppClassLoader)。

弱引用和虚引用的区别是什么？ https://blog.csdn.net/m0_37962779/article/details/78279721 弱引用在对象被回收之前还可能通过finialize方法抢救一下，虚引用无法被抢救，因为虚引用无法得到被引用对象

URLClassLoader加载出来的class对象、new出来的对象、classLoader对象置为null，调用system.gc()强制回收，能回收吗？ https://blog.csdn.net/m0_37962779/article/details/78279721

用java写一个内存泄漏程序？ https://www.jianshu.com/p/c68a6ffc62a0