类加载器、双亲委派、SPI
类加载器加载的类如何存储
- 1.Class是访问类型T定义的Java程序入口,在Java代码中，如果你想获取T的定义，如查看其方法定义，字段定义，首先要获取到对应的Class实例
- 2.ClassLoader实例本身对Java而言，也是一个分配在堆中的一个对象，它管理着自己在方法区的一个区域
元空间内部给各个类加载器划分了内存区域。另外还需要注意一点的是，方法区会有碎片化问题，方法区的垃圾回收通常被称为类的卸载。方法区回收之后是没有整理的
双亲委派机制
如果一个类加载器收到了加载某个类的请求，则该类加载器并不会去加载该类，而是把这个请求委派给父类加载器，每一个层次的类加载器都是如此，因此所有的类加载器请求最终都会传送到顶端的启动类加载器；只有当父类加载器在其搜索范围内无法找到所需的类，并将该结果反馈给子类加载器，子类加载器会尝试自己加载
如何打破双亲委派？为什么要打破双亲委派机制？
因为在某些情况下父类加载器需要委托子类加载器去加载class文件。受到加载范围的限制，父类加载器无法加载到需要的文件，以Driver接口为例，由于Driver接口定义在jdk当中的，而其实现由各个数据库的服务商来提供，比如mysql的就写了MySQL Connector，那么问题就来了，DriverManager(也由jdk提供)要加载各个实现了DriverManager接口的实现类，然后进行管理，但是DriverManager由启动类加载器加载，只能加载JAVA_HOME的lib目录下的文件，而其实现是由服务商提供的，由系统类加载器加载，这个时候就需要启动类加载器来委托子类来加载Driver实现，从而破坏了双亲委派机制。类似这样的情况就需要打破双亲委派。打破双亲委派的意思其实就是不委派、向下委派。
线程上下文类加载器
1.是什么?一种特殊的类加载器，可以通过Thread获取，基于此可实现逆向委托加载
2.为什么？为了解决双亲委派的缺陷而生
3.怎么做？如图所示
SPI机制
它是一种服务发现机制。它通过在ClassPath路径下的META-INF/services文件夹查找文件，自动加载文件里所定义的类。这一机制为很多框架扩展提供了可能，比如在Dubbo、JDBC中都使用到了SPI机制。Tomcat/Spring就是这样类似的机制
沙箱安全
比如定义了一个类名为String所在包为java.lang,因为这个类本身是属于jdk的，如果没有沙箱安全机制的话，这个类将会污染到我所有的String，但是由于沙箱安全机制，所以就委托顶层的bootstrap加载器查找这个类，如果没有的话就委托extension,extension没有就到appclassloader,但是由于String就是jdk的源代码，所在bootstrap哪里就加载到了，先找到先使用，所以就使用bootstrap里面的String后面的一概不能使用，这就保证了不被恶意代码污染
openjdk源码会有很多这样的判断AccessController.doPrivileged
反射的底层原理
涉及到的字节码指令
- forName
- getField
- getMethod
通过这些方法获取一个类的信息，那么它是怎么存储的呢？它会去方法区中进行查找，那么在HotSpot中它是通过Dictionary字典来存储这些信息的，底层数据结构是hashtable
key:类的全限定名+类加载器->index
value: Metadata:klass
反射时需要先找到InstsanceKlass对象然后才能找到InstanceMirrorKlass对象，因为JVM是没法找到堆中的Class对象的，JVM找到InstanceKlass，就可以直接拿到InstanceMirrorKlass