读《深入理解Java虚拟机》解决实际问题及总结JDK和JVM整体架构

前言

以前看别人博客说看完《深入理解Java虚拟机》这本书并没有让自己的编程水平提高多少，不过却大大提高了自己的装逼水平。其实，我倒不这么认为，至少在我看完一遍这本书后，有一种醍醐灌顶的感觉，很多模糊的知识和概念也变得清晰起来。今天，也是偶然的机会能够运用书中所学的知识解决实际问题，在这里，与大家分享一下，如有不正确的地方，还请指正。

问题描述

预生产环境突然出现了一个运行时异常，异常信息如下(Error异常)：

java.lang.NoClassDefFoundError: javax/servlet/ServletOutputStream at com.soa.xxx.ProductTransForm.transProduct(ProductTransForm.java:10) ...... Caused by: java.lang.ClassNotFoundException: javax.servlet.ServletOutputStream at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355)

报异常的代码如下(根据真实项目场景模拟代码)：

public class ProductTransForm { public ProductRespVo transProduct(ProductVo productVo) { ProductRespVo productRespVo = new ProductRespVo(); productRespVo.setProId(productVo.getProId()); productRespVo.setName(productVo.getName()); // TODO:注意下面这行代码，出问题的代码 productRespVo.setImage(FtpUtil.getFtpPath() + File.separator + productVo.getImage()); return productRespVo; } }

import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; public class FtpUtil { public static String getFtpPath() { return "The path of Ftp"; } public static void downloadFile(HttpServletRequest req, HttpServletResponse resp) { // 下载代码逻辑 } }

问题出在静态方法调用：FtpUtil.getFtpPath()，初看之下，并没有什么问题，静态方法getFtpPath()只是简单地返回一个地址字符串。

原因分析

经过各种尝试、调试以及重新打包等都没有能解决问题。这时候，突然想到《深入理解Java虚拟机》中有关Java类的初始化机制中讲到过类的初始化时机，因为FtpUtil类的getFtpPath()方法为静态方法，而调用一个类的静态方法会触发其初始化，带着这个设想，我写下了以下一行代码：

FtpUtil ftpUtil = new FtpUtil();

启动运行，果然重现了错误。既然原因是出在FtpUtil类的初始化上，那么从FtpUtil这个类着手分析，异常信息显示找不到ServletOutputStream类的定义，而在引入的包"javax.servlet.http.HttpServletResponse"的父接口也确实找到了对ServletOutputStream类的引用，但奇怪的是该类所在的包:servlet-api.jar是有引入的，否则也不能正常导入"javax.servlet.http.HttpServletResponse"包，于是猜测可能是jar包冲突，查看工程，发现工程中确实存在多个不同版本的servlet-api.jar(历史原因)：

因此猜测是servlet jar包冲突导致的。

问题解决

定位了原因之后，首先想到的就是《深入理解Java虚拟机》书中讲到过的类的加载机制和双亲委派模型：

“如果一个类加载器收到类收到了类加载请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，只有当父类加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需要的类）时，子加载器才会尝试自己去加载。”。从上图可以看到，由于启动类加载器和扩展类加载器的搜索范围内都没有servlet-api.jar包，所以无法加载ServletOutputStream类，因此，应用程序类加载器会尝试自己加载类ServletOutputStream，而ClassPath范围内存在多个不同版本的servlet-api.jar包，所以出现包冲突。

基于以上分析，我将一个servlet-api.jar包拷贝到JRE/lib/ext路径下，这样，扩展类加载器能够加载拷贝jar包中的ServletOutputStream类，应用程序加载器就不会再去加载ServletOutputStream类，也就不会冲突了。经过重启程序验证，果然没有再抛异常了。

从上图也可以看出，为什么我们不能够自己定义一些与JDK类名、路径完全一样的类来覆盖JDK的类（如String），因为这些类在rt.jar中，由启动类加载器加载，我们自己定义的同名同路径类根本没有加载的机会，也就不可能覆盖JDK的类了。记得有一场面试，面试官问道：我们有一个项目需要在不同的JDK版本运行，如果保证jar的兼容不冲突？想来也是想考这方面的知识吧。

补充：

一、类的初始化时机

虚拟机规范严格规定了有且只有5种情况必须立即对类进行初始化：

1. 遇到new、getstatic、putstatic或invokestatic这4个字节码指令时，如果类没有经过初始化，则需要触发其初始化；
2. 使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有初始化，则需要触发其初始化；
3. 当初始化一个类时，如果发现它的父类没有进行过初始化，则需要先触发其父类的初始化；
4. 当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类；
5. 当使用JDK1.7的动态语言支持时，如果一个java.lang.invokke.MethodHandle实例最后解析的结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。

二、类加载器

1、启动类加载器（Bootstrap ClassLoader）

负责将存放在<JAVA_HOME>\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的（仅按照文件名识别，如rt.jar，名字不符合的类库即使放到lib目录中也不会被加载）类库加载到虚拟机内存中。

2、扩展类加载器（Extension ClassLoader）

负责加载<JAVA_HOME>\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。

3、应用程序类加载器（Application ClassLoader）

负责加载用户类路径（ClassPath）上所指定的类库，开发者可以直接使用这个类加载器，如果程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

三、JVM整体架构

四、JDK体系结构