问题产生于思考Tomcat与JVM的关系，发现自己就是个孩子，对它们一无所知。
Tomcat是一个用Java语言写出来的应用程序，所以每运行一个Tomcat实例必将开启一个JVM进程。启动多个Tomcat将会产生多个JVM进程，每个JVM进程中可以部署运行多个Web应用程序，即可以存在多个类加载器（见下文）。经过对基本概念的重新梳理，简单表示如下图。
类加载器
public class LookForClassLoader {
public static void main(String[] args) {
ClassLoader currentLoader = Thread.currentThread().getContextClassLoader(); // 获取当前线程上下文的类加载器
System.out.println("current classLoader:" + currentLoader.getClass());
System.out.println("parent classLoader:" + currentLoader.getParent().getClass());
System.out.println("grandparent classLoader:" + currentLoader.getParent().getParent());
}
}
Output：
current classLoader:sun.misc.Launcher$AppClassLoader@18b4aac2当前AppClassLoader实例
parent classLoader:class sun.misc.Launcher\$ExtClassLoader@4554617c父类ExtClassLoader实例
grandparent classLoader:null祖类BootstrapClassLoader实例
祖类BootstrapClassLoader实例为null，是由C++所写直接嵌入在 JVM 内核中，在Java中无法获得它的句柄，所以直接返回null。除了Java默认提供的三个ClassLoader之外，用户可以根据需要定义自己的ClassLoader，这些自定义的ClassLoader都必须继承自java.lang.ClassLoader类，但是Bootstrap ClassLoader不继承自ClassLoader。当JVM启动后，Bootstrap ClassLoader也随着启动，负责加载完核心类库后，并构造Extension ClassLoader和App ClassLoader类加载器。
上图展示的类加载器之间的这种层次关系，称为类加载器的双亲委派模型。双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系一般不会以继承的关系来实现，而是使用组合/包含关系来复用父加载器的代码。
加载类：自顶向下
当一个ClassLoader实例需要加载某个类时，在它亲自搜索之前，会先把这个任务委托给它的父类加载器，这个过程是由上至下依次检查的，首先由最顶层的类加载器Bootstrap ClassLoader试图加载，如果没加载到，则把任务转交给Extension ClassLoader试图加载，如果也没加载到，则转交给App ClassLoader 进行加载，如果它也没有加载得到的话，则返回给委托的发起者，由它到指定的文件系统或网络等URL中加载该类。如果它们都没有加载到这个类时，则抛出ClassNotFoundException异常。否则将这个找到的类生成一个类的定义，并将它加载到内存当中，最后返回这个类在内存中的Class实例对象。
询问是否已加载类：自底向上
可以避免重复加载，当父亲已经加载了该类的时候，就没有必要子ClassLoader再加载一次。同时考虑到安全因素，我们试想一下，如果不使用这种委托模式，那我们就可以随时使用自定义的String来动态替代java核心api中定义的类型，这样会存在非常大的安全隐患，而双亲委托的方式，就可以避免这种情况，因为String已经在启动时就被引导类加载器（Bootstrcp ClassLoader）加载，所以用户自定义的ClassLoader永远也无法加载一个自己写的String，除非改变JDK中ClassLoader搜索类的默认算法。
JVM在判定两个class是否相同时，不仅要判断两个类名是否相同，而且要判断是否由同一个类加载器实例加载的。只有两者同时满足的情况下，JVM才认为这两个class是相同的。就算两个class是同一份class字节码，如果被两个不同的ClassLoader实例所加载，JVM也会认为它们是两个不同class。
BootStrap classLoader加载的类
System.out.println(System.getProperty("sun.boot.class.path")); // BootStrap classLoader加载的类
Output：
D:\Java\jdk1.8.0_74\jre\lib\resources.jar;// 资源包（图片、properties文件）
D:\Java\jdk1.8.0_74\jre\lib\rt.jar; // Bootstrap类，引导类（构成Java平台核心API的运行时类）
D:\Java\jdk1.8.0_74\jre\lib\sunrsasign.jar;
D:\Java\jdk1.8.0_74\jre\lib\jsse.jar;// Java 安全套接字扩展类库，用于实现加密的 Socket 连接
D:\Java\jdk1.8.0_74\jre\lib\jce.jar;// Java 加密扩展类库，含有很多非对称加密算法在里面，也是可扩展的
D:\Java\jdk1.8.0_74\jre\lib\charsets.jar; // Java 字符集，这个类库中包含 Java 所有支持字符集的字符
D:\Java\jdk1.8.0_74\jre\lib\jfr.jar;// Java飞行记录器 Flight Recorder，可以深入分析问题，使用参考
D:\Java\jdk1.8.0_74\jre\classes
java -verbose[:class|gc|jni]
-
java -verbose:class输出虚拟机装入的类的信息，显示的信息格式如下
[Opened D:\Java\jdk1.8.0_74\jre\lib\rt.jar]
[Loaded java.lang.Object from D:\Java\jdk1.8.0_74\jre\lib\rt.jar]
[Loaded java.io.Serializable from D:\Java\jdk1.8.0_74\jre\lib\rt.jar]
[Loaded java.lang.Comparable from D:\Java\jdk1.8.0_74\jre\lib\rt.jar]
[Loaded java.util.Arrays from D:\Java\jdk1.8.0_74\jre\lib\rt.jar]
[Loaded java.nio.charset.Charset$ExtendedProviderHolder from D:\Java\jdk1.8.0_74\jre\lib\rt.jar]
[Loaded java.nio.charset.Charset$ExtendedProviderHolder$1 from D:\Java\jdk1.8.0_74\jre\lib\rt.jar]
...
[Loaded java.lang.Class$MethodArray from D:\Java\jdk1.8.0_74\jre\lib\rt.jar]
[Loaded java.lang.Void from D:\Java\jdk1.8.0_74\jre\lib\rt.jar]
current classLoader:sun.misc.Launcher$AppClassLoader@18b4aac2
parent classLoader:sun.misc.Launcher$ExtClassLoader@4554617c
grandparent classLoader:null
[Loaded java.lang.Shutdown from D:\Java\jdk1.8.0_74\jre\lib\rt.jar]
[Loaded java.lang.Shutdown$Lock from D:\Java\jdk1.8.0_74\jre\lib\rt.jar]
-
java -verbose:gc监视虚拟机内存回收的情况，格式如输出所示
public static void showGCInfo(){
LookForClassLoader obj = new LookForClassLoader();
System.gc();
}
Output:
[GC (System.gc()) 2663K->672K(125952K), 0.0082196 secs]
[Full GC (System.gc()) 672K->569K(125952K), 0.0158595 secs]
箭头前后的数据672K和569K分别表示垃圾收集GC前后所有存活对象使用的内存容量，说明有672K-569K=103K的对象容量被回收，括号内的数据125952K为堆内存的总容量，收集所需要的时间是0.0158595 秒（这个时间在每次执行的时候会有所不同）
在VM的启动参数中加入-XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationStoppedTime，分别输出GC的简要信息，GC的详细信息、GC的时间信息及GC造成的应用暂停的时间。
-
java -verbose:jni输出native方法调用的情况，一般用于诊断jni调用错误信息，格式如下：
[Dynamic-linking native method java.lang.Object.registerNatives ... JNI]
[Registering JNI native method java.lang.Object.hashCode]
[Registering JNI native method java.lang.Object.wait]
[Registering JNI native method java.lang.Object.notify]
[Registering JNI native method java.lang.Object.notifyAll]
[Registering JNI native method java.lang.Object.clone]
[Dynamic-linking native method java.lang.System.registerNatives ... JNI]
[Registering JNI native method java.lang.System.currentTimeMillis]
[Registering JNI native method java.lang.System.nanoTime]
[Registering JNI native method java.lang.System.arraycopy]
[Dynamic-linking native method java.lang.Thread.registerNatives ... JNI]
[Registering JNI native method java.lang.Thread.start0]
[Registering JNI native method java.lang.Thread.stop0]
[Registering JNI native method java.lang.Thread.isAlive]
[Registering JNI native method java.lang.Thread.suspend0]
[Registering JNI native method java.lang.Thread.resume0]
...
“猫”的后续
JVM 的后续
参考博客：
https://www.cnblogs.com/jingmoxukong/p/8258837.html?utm_source=gold_browser_extension
https://my.oschina.net/zhengjian/blog/133836
https://www.cnblogs.com/z00377750/p/9167768.html
