类加载及执行子系统的案例与实战

在Class文件格式与执行引擎这部分里，用户的程序能直接影响的内容并不太多，Class文件以何种格式存储，类型核实加载、如何连接，以及虚拟机如何执行字节码指令等都是由虚拟机直接控制的行为，用户程序无法对其进行改变。能通过程序进行操作的，主要是字节码生成与类加载器这两部分的功能。

Tomcat:正统的类加载器架构

一个功能健全的Web服务器，都要解决如下几个问题

1.       部署在同一个服务器上的两个web应用程序所使用的Java类库可以实现相互隔离。不能要求一个类库在一个服务器中只有一份

2.       部署在同一个服务器上的两个web应用程序所使用的Java类库可以互相共享

3.       服务器需要尽可能地保证自身的安全不受部署的web应用程序影响，服务器本身也有类库依赖的问题，基于安全考虑，服务器所使用的类库应该与应用程序类库相互独立

4.       支持JSP应用的web服务器，十有八九需要支持HotSwap功能，JSP文件由于其纯文本存储的特性，被运行是容易修改，因此主流的web服务器都会支持JSP生成类的热替换。

由于存在上述问题，部署web应用时，单独一个ClassPath就无法满足需求，各种Web服务器都提供了好几个ClassPah路径供用户存放第三方类库。放置在不同路径中的类库，具备不同访问范围和服务对象，通常，每个目录都会有一个相应的自定义类加载器去加载放置在里面的Java类库

OSGI:灵活的类加载器架构

Java程序社区中流传这这么一个观点：“学习JEE规范，去看JBoss源码；学习类加载器，就去看OSGi源码”。OSGi是OSGi联盟指定的一个基于Java语言的动态模块化规范，这个规范最初由Sun、IBM、爱立信等公司联合发起，现在已经成为Java世界中“事实上”的模块化标准，OSGi在Java程序中最著名的应用案例就是Eclipse IDE。除了更精确的模块划分和可见性控制外，另外一个重要理由是，基于OSGi的程序很可能可以实现模块级的热插拔功能，当程序升级更新或调试除错时，可以只停用、重新安装然后启动程序的其中一部分，这对企业程序开发来说非常有诱惑力。

字节码生成技术与动态代理的实现

字节码生成并不是什么高深的技术，也不必先去想诸如Javassist、CGLib和ASM之类的字节码类库，因为JDK里面的javac命令就是字节码技术的“老祖宗”，并且javac也是一个由Java语言写成的程序。要深入了解字节码生成，阅读javac的源码是个很好的途径。在Java里面除了javac和字节码类库外，使用到的字节码生成的例子还有很多，如web服务器中的JSP编译器，编译时织入的AOP框架，还有很常用的动态代理技术，甚至在使用反射的时候虚拟机都有可能绘制运行时生成字节码来提高执行速度。

动态代理中所谓的“动态”，是针对使用Java代码实际编写了代理类的“静态”代理而言的，它的优势不在于省去了编写代理类那一点工作量，而是实现了可以在原始类和接口还未知的时候，就确定代理类的代理行为，当代理类与原始类脱离直接联系后，就可以很灵活地重用于不同的应用场景之中。

Retrotranslator:跨越JDK版本

一般来说，以“做项目”为主的软件公司比较容易更新技术。但是当公司发展壮大，技术有所积累，逐渐成为以“做产品”为主的软件公司后，自主选择技术的权利就会丧失掉，因为之前所积累的代码和技术都是用真金白银砸出来的，一个稳健的团队也不会随意地变底层的技术。然而飞速发展的程序设计领域，新技术总是日新月异层出不穷，偏偏这些技术又如鲜花之于蜜蜂、美酒之于醉汉一样，对程序员们有着难以抗拒的吸引力。

一种名为“Java逆向移植”的工具应运而生，Retrotranslator是这类工具中最出色的一个

JDK的每次升级中新增的功能大致可以分为四类：

1.       在编译器层面所做的改进

2.       对Java API的代码增强

3.       需要在字节码中进行支持的改动

4.       虚拟机内部的改进

转载请注明：学时网 » 深入理解java虚拟机（七）