運用《深入理解Java虛擬機》書中知識解決實際問題

前言

以前看別人博客說看完《深入理解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）上所指定的類庫，開發者可以直接使用這個類加載器，如果程序中沒有自定義過自己的類加載器，一般情況下這個就是程序中默認的類加載器。