运用《深入理解Java虚拟机》书中知识解决实际问题

时间:2022-01-27 05:04:06

前言

以前看别人博客说看完《深入理解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(历史原因):

运用《深入理解Java虚拟机》书中知识解决实际问题

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

问题解决

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

运用《深入理解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)上所指定的类库,开发者可以直接使用这个类加载器,如果程序中没有自定义过自己的类加载器,一般情况下这个就是程序中默认的类加载器。