小目标之读懂JVM—类加载及执行子系统的案例与实战

这章案例比较多，代码方面不做展示，粗略介绍下几个案例的知识。

在Class文件格式和执行引擎这部分中，用户程序能直接影响的主要是字节码生成与类加载器两部分的功能。

案例一：tomcat下正统的类加载结构。web服务器一般有以上几个问题：1.部署在同一服务器下的Java类库需要可以实现相互隔离、独立使用，因为可能两个不同的应用程序会依赖同一个第三方类库的不同版本。2.部署在同一服务器下的Java类库又需要可以互相共享。因为如果类库不能共享，虚拟机的方法区会出现过度膨胀的危险。3.服务器使用类库应与应用程序类库互相独立。因为服务器要尽可能保证自身的安全不受部署的web应用程序影响。4.主流web服务器大多支持HotSwap功能，保证程序修改后无须重启。因此在部署web应用时，服务器一般会提供多个ClassPath路径存放第三方类库提供选择。Tomcat中，有3组目录(“/common”、“/server”，“/shared”)可以存放Java类库，再加上web应用程序自身目录“/WEB-INF/*”，一共4组。4组目录下的类库含义分别为/common中的类库可被Tomcat和所有的web应用程序共同使用，/server目录下的类库可被Tomcat使用，对所有的web应用程序不可见。/shared下的目录可被所有web应用程序使用，对Tomcat不可见。/WebApp/WEB-INF目录下的类库可被此web应用程序使用，对Tomcat和其他web应用程序不可见。为了支持这套目录结构，Tomcat自定义了多个类加载器，这些类加载器按照经典的双亲委派模型实现。Tomcat在应用程序类加载器(Application ClassLoader)下自定义了Common类加载器(CommonClassLoader)，在Common类加载器下又实现了Catalina类加载器(CatalinaClassLoader)和Shared类加载器(SharedClassLoader)，在Shared类加载器实现了WebApp类加载器(WebAppClassLoader)，在WebApp类加载器下又实现了Jsp类加载器(JasperLoader)，达成了基础类库共享，Web实例下的类库隔离，并且Jsp可被热替换的需求。

案例二：OSGI下灵活的类加载结构。OSGI(Open Service Gateway Initiative)是OSGI联盟指定的一个基于JAVA语言的动态模块化规范，现在是Java世界中事实上的模块化标准。OSGI中的每个模块(Bundle)与普通的Java类库区别不大。在OSGI中，Bundle之间的依赖关系从传统的上层模块依赖底层模块转变为平级模块之间的依赖。而且通过模块中的Export和Import实现了类库可见性更为精确的控制。而且基于OSGI的程序很可能可以实现模块集的热插拔功能。OSGI类加载java.*的类时根据概念模型可能的查找规则如下：以java.*开头的类，委派给父类加载器加载；否则，委派列表名单内的类，委派给父类加载器加载；否则Import列表中的类，委托给Export这个类的Bundle的类加载器加载；否则，查找是否在自己的Fragment Bundle中，如果是，则委派给Fragment Bundle的类加载器加载；否则，查找Dynamic Import列表的Bundle，委派给Bundle的类加载器加载；否则，类查找失败。

案例三是讲述了动态代理时字节码的生成，根据Class文件格式规范去拼装字节码。一般用户的程序代码是使用封装好的字节码类库。

本章还讲述了Retrotranslator这种Java逆向移植工具，可以将高版本的JDK编译出来的Class文件转变为可以在低版本JDK上部署的版本。

最后讲述了一个开发者自定义类加载器去执行校验某些类功能的场景，可以在服务器上校验和调试部分代码，这个功能可以实现，这部分范例不做展示。