Java 類加載器解析及常見類加載問題

原文 https://www.toutiao.com/article/6812564562244534787

java.lang.ClassLoader

每個類加載器本身也是個對象——一個繼承 java.lang.ClassLoader 的實例。每個類被其中一個實例加載。我們下面來看看 java.lang.ClassLoader 中的 API, 不太相關的部分已忽略。

package java.lang;

public abstract class ClassLoader {

  public Class loadClass(String name);
  protected Class defineClass(byte[] b);

  public URL getResource(String name);
  public Enumeration getResources(String name);
  
  public ClassLoader getParent()
}

loadClass: 目前 java.lang.ClassLoader 中最重要的方法是 loadClass 方法，它獲取要加載的類的全限定名返回 Class 對象。

defineClass: defineClass 方法用于具體化 JVM 的類。byte 數(shù)組參數(shù)是加載自磁盤或其他位置的類字節(jié)碼。

getResource 和 getResources: 返回資源路徑。loadClass 大致相當于 defineClass(getResource(name).getBytes())。

getParent: 返回父加載器。

Java 的懶惰特性影響了類加載器的工作方式——所有事情都應該在最后一刻完成。類只有在以某種方式被引用時才會被加載-通過調(diào)用構造函數(shù)、靜態(tài)方法或字段。看個例子：

類 A 實例化類 B:

public class A {
   public void doSomething() {
    B b = new B();
     b.doSomethingElse();
   }
 }

語句 B b = new B() 在語義上等同于 B b = A.class. getClassLoader().loadClass(“B”).newInstance() 。如我們所見，Java 中的每個對象都與其類 (A.class) 相關聯(lián)，并且每個類都與用于加載類的類加載器 (A.class.getClassLoader()) 相關聯(lián)。

當我們實例化類加載器時，我們可以將父類加載器指定為構造函數(shù)參數(shù)。如果未顯式指定父類加載器，則會將虛擬機的系統(tǒng)類加載器指定為默認父類。

類加載器層次結構

每當啟動新的 JVM 時，引導類加載器(bootstrap classloader)負責首先將關鍵 Java 類（來自 Java.lang 包）和其他運行時類加載到內(nèi)存中。引導類加載器是所有其他類加載器的父類。因此，它是唯一沒有父類的。

接下來是擴展類加載器(extension classloader)。引導類加載器(bootstrap classloader)作為父類，負責從 java.ext.dirs 路徑中保存的所有 .jar 文件加載類。

從開發(fā)人員的角度來看，第三個也是最重要的類加載器是系統(tǒng)類路徑類加載器(system classpath classloader)，它是擴展類加載器(extension classloader)的直接子類。它從由 CLASSPATH 環(huán)境變量 java.class.pat h系統(tǒng)屬性或 -classpath 命令行選項指定的目錄和 jar 文件加載類。

請注意，類加載器層次結構不是繼承層次結構，而是委托層次結構。大多數(shù)類加載器在搜索自己的類路徑之前將查找類和資源委托給其父類。如果父類加載器找不到類或資源，則類加載器只能嘗試在本地找到它們。實際上，類加載器只負責加載父級不可用的類；層次結構中較高的類加載器加載的類不能引用層次結構中較低的可用類。類加載器委托行為的動機是避免多次加載同一個類。

在 Java EE 中，查找的順序通常是相反的：類加載器可能在轉到父類之前嘗試在本地查找類。

Java EE 委托模型

下面是應用程序容器的類加載器層次結構的典型視圖：容器本身有一個類加載器，每個 EAR 模塊都有自己的類加載器，每個 WAR 都有自己的類加載器。Java Servlet 規(guī)范建議 web 模塊的類加載器在委托給其父類之前先在本地類加載器中查找——父類加載器只要求提供模塊中找不到的資源和類。

在某些應用程序容器中，遵循此建議，但在其他應用程序容器中，web 模塊的類加載器配置為遵循與其他類加載器相同的委托模型，因此建議參考您使用的應用程序容器的文檔。

顛倒本地查找和委托查找之間的順序的原因是，應用程序容器附帶了許多具有自己的發(fā)布周期的庫，這些庫可能不適用于應用程序開發(fā)人員。典型的例子是 log4j 庫——它的一個版本通常隨容器一起提供，不同的版本與應用程序捆綁在一起。

現(xiàn)在，讓我們來看看我們可能遇到的幾個常見的類加載問題，并提供可能的解決方案。

常見類加載問題

Java EE 委托模型會導致類加載的一些有趣的問題。NoClassDefFoundError、LinkageError、ClassNotFoundException、NoSuchMethodError、ClassCasteException等是開發(fā) Java EE 應用程序時遇到的非常常見的異常。我們可以對這些問題的根本原因做出各種假設，但重要的是要驗證它們。

NoClassDefFoundError

NoClassDefFoundError 是開發(fā) Java EE Java 應用程序時最常見的問題之一。

根本原因分析和解決過程的復雜性主要取決于 Java EE 中間件環(huán)境的大?。惶貏e是考慮到各種 Java EE 應用程序中存在大量的類加載器。

正如 Javadoc 條目所說，如果 Java 虛擬機或類加載器實例試圖在類的定義中加載，而找不到類的定義，則拋出 NoClassDefFoundError。這意味著，在編譯當前執(zhí)行的類時，搜索到的類定義存在，但在運行時找不到該定義。

這就是為什么你不能總是依賴你的 IDE 告訴你一切正常，代碼編譯應該正常工作。相反，這是一個運行時問題，IDE 在這里無法提供幫助。

讓我們看看下面的例子：

public class HelloServlet extends HttpServlet {
   protected void doGet(HttpServletRequest request,
                                    HttpServletResponse response)
                                    throws ServletException, IOException {
       PrintWriter out = response.getWriter();
       out.print(new Util().sayHello());
}

servlet HelloServlet 實例化了 Util 類的一個實例，該實例提供了要打印的消息。遺憾的是，當請求執(zhí)行時，我們可能會看到以下內(nèi)容：

java.lang.NoClassdefFoundError: Util
 HelloServlet:doGet(HelloServlet.java:17)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

我們?nèi)绾谓鉀Q這個問題？好吧，您可能要做的最明顯的操作是檢查丟失的 Util 類是否已實際包含在包中。

我們在這里可以使用的技巧之一是讓容器類加載器承認它從何處加載資源。為此，我們可以嘗試將 HelloServlet 的類加載器轉換為 URLClassLoader 并請求其類路徑。

public class HelloServlet extends HttpServlet {
   protected void doGet(HttpServletRequest request,
                                    HttpServletResponse response)
                                    throws ServletException, IOException {
       PrintWriter out = response.getWriter();
       out.print(Arrays.toString(
           ((URLClassLoader)HelloServlet.class.getClassLoader()).getURLs()));
}

結果很可能是這樣：

file:/Users/myuser/eclipse/workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/demo/WEB-INF/classes,
file:/Users/myuser/eclipse/workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/demo/WEB-INF/lib/demo-lib.jar

資源的路徑( file:/Users/myuser/eclipse/workspace/.metadata/)實際上顯示容器是從 Eclipse 啟動的，這是 IDE 解壓歸檔文件來進行部署的地方。現(xiàn)在我們可以檢查丟失的 Util 是否真的包含在 demo-lib.jar 中，或者它是否存在于擴展存檔的 WEB-INF/classes 目錄中。

因此，對于我們的特定示例，可能是這樣的情況：Util 類應該打包到 demo-lib.jar 中，但是我們沒有重新啟動構建過程，并且該類沒有包含在以前存在的包中，因此出現(xiàn)了錯誤。

URLClassLoader 技巧可能不適用于所有應用服務器。另一種方法是使用jconsole 實用程序附加到容器JVM進程，以檢查類路徑。例如，屏幕截圖（如下）演示了連接到 JBoss application server 進程的 jconsole 窗口，我們可以從運行時屬性中看到 ClassPath 屬性值。

NoSuchMethodError

在另一個具有相同示例的場景中，我們可能會遇到以下異常：

java.lang.NoSuchMethodError: Util.sayHello()Ljava/lang/String;
 HelloServlet:doGet(HelloServlet.java:17)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

NoSuchMethodError 代表另一個問題。在本例中，我們所引用的類存在，但加載的類版本不正確，因此找不到所需的方法。

要解決這個問題，我們首先必須了解類是從何處加載的。最簡單的方法是向 JVM 添加 '-verbose:class' 命令行參數(shù)，但是如果您可以快速更改代碼，那么您可以使用 getResource 搜索與 loadClass 相同的類路徑。

public class HelloServlet extends HttpServlet {
   protected void doGet(HttpServletRequest request,
                                    HttpServletResponse response)
                                    throws ServletException, IOException {
       PrintWriter out = response.getWriter();
    out.print(HelloServlet.class.getClassLoader().getResource(
           Util.class.getName.replace(‘.’, ‘/’) + “.class”));  

}

假設，上述示例的請求執(zhí)行結果如下.

file:/Users/myuser/eclipse/workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/demo/WEB-INF/lib/demo-lib.jar!/Util.class

現(xiàn)在我們需要驗證關于類的錯誤版本的假設。我們可以使用javap實用程序來反編譯類，然后我們可以看到所需的方法是否實際存在。

$ javap -private Util
Compiled from “Util.java”
public class Util extends java.lang.Object {
   public Util();
}

如您所見，Util 類的反編譯版本中沒有sayHello方法?？赡埽覀冊?demo-lib.jar 中打包了 Util 類的初始版本，但是在添加了新的 sayHello 方法之后，我們沒有重新構建這個包。

在處理 Java EE 應用程序時，錯誤類問題 NoClassDefFoundError 和 NoSuchMethodError 的變體是非常典型的，這是 Java 開發(fā)人員理解這些錯誤的本質(zhì)以有效解決問題所必需的技能。

這些問題有很多變體：AbstractMethodError、ClassCastException、IllegalAccessError——基本上，當我們認為應用程序使用類的一個版本，但實際上它使用了其他版本，或者類的加載方式與需要的不同時，這些問題都會遇到。

ClassCastException

這里我們只演示 ClassCastException 例子。我們將以使用工廠修改初始示例，以便提供提供問候消息的類的實現(xiàn)。這看起來很做作，但這是很常見的模式。

public class HelloServlet extends HttpServlet {
   protected void doGet(HttpServletRequest request, 
                                    HttpServletResponse response) 
                                    throws ServletException, IOException {
       PrintWriter out = response.getWriter();
    out.print(((Util)Factory.getUtil()).sayHello());
}

class Factory {
     public static Object getUtil() {
          return new Util();
     }
}

請求的可能結果是：

java.lang.ClassCastException: Util cannot be cast to Util
    HelloServlet:doGet(HelloServlet.java:18)
    javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
    javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

這意味著 HelloServlet 和 Factory 類在不同的上下文中操作。我們必須弄清楚這些類是如何加載的。讓我們使用 -verbose:class 并找出如何加載與HelloServlet 和 Factory 類相關的 Util 類。

[Loaded Util from file:/Users/ekabanov/Applications/ apache-tomcat-6.0.20/lib/cl-shared-jar.jar] 
[Loaded Util from file:/Users/ekabanov/Documents/workspace-javazone/.metadata/.plugins/org.eclipse.wst. server.core/tmp0/wtpwebapps/cl-demo/WEB-INF/lib/cl-demo- jar.jar]

因此，Util類由不同的類加載器從兩個不同的位置加載。一個在web應用程序類加載器中，另一個在應用程序容器類加載器中。它們是不兼容的，不能相互轉換。

但它們?yōu)槭裁床幌嗳菽?？原來Java中的每個類都是由其完全限定名唯一標識的。但在1997年發(fā)表的一篇論文揭露了由此引起的一個廣泛的安全問題，即沙盒應用程序（例如：applet）可以定義任何類，包括 java.lang.String，并在沙盒外注入自己的代碼。

解決方案是通過完全限定名和類加載器的組合來標識類！這意味著從類加載器 A 加載的 Util 類和從類加載器 B 加載的 Util 類在 JVM 中是不同的類，不能將一個類轉換為另一個類！

這個問題的根源是 web 類加載器的反向行為。如果 web 類加載器的行為與其他類加載器相同，那么 Util 類將從應用程序容器類加載器加載一次，并且不會拋出類 CastException。

LinkageError

讓我們從前面的示例中稍微修改一下 Factory 類，這樣 getUtil 方法現(xiàn)在返回的是 Util 類型而不是 Object：

class Factory {
     public static Util getUtil() {
          return new Util();
     }
}

現(xiàn)在，執(zhí)行的結果是 LinkageError:

ClassCastException: java.lang.LinkageError: loader constraint violation: when resolving method Factory.getUtil()LUtil;
<…> HelloServlet:doGet(HelloServlet.java:18)
javax.servlet.http.HttpServlet.service(HttpServlet.java:617) javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

根本問題與 ClassCastException 相同——唯一的區(qū)別是我們不強制轉換對象，而是加載程序約束導致Linkage錯誤。

在處理類加載器時，一個非常重要的原則是認識到類加載器的行為常常會破壞您的直觀理解，因此驗證您的假設非常重要。例如，在 LinkageError 的情況下，查看代碼或構建過程將阻礙而不是幫助您。關鍵是查看類的確切加載位置，它們是如何到達那里的，以及如何防止將來發(fā)生這種情況。

多個類加載器中存在相同類的一個常見原因是，同一個庫的不同版本捆綁在不同的位置，例如應用服務器和 web 應用程序。這通常發(fā)生在像 log4j 或 hibernate 這樣的實際標準庫中。在這種情況下，解決方案要么是將庫與 web 應用程序分開，要么是非常小心地避免使用父類加載器中的類。

IllegalAccessError

其實，不僅類由其全限定名和類加載器標識，而且該規(guī)則也適用于包。為了演示這一點，我們將 Factory.getUtil 方法的訪問修飾符更改為默認值：

class Factory {
     static Object getUtil() {
          return new Util();
     }
}

假設 HelloServlet 和 Factory 都位于同一個（默認）包中，因此 getUtil 在 HelloServlet 類中可見。不幸的是，如果我們試圖在運行時訪問它，我們將看到 IllegalAccessError 異常。

java.lang.IllegalAccessError: tried to access method Factory.getUtil()Ljava/lang/Object;
HelloServlet:doGet(HelloServlet.java:18)
javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

盡管訪問修飾符對于應用程序的編譯是正確的，但是在運行時，這些類是從不同的類加載器加載的，應用程序無法運行。這是由于與類一樣，包也由它們的完全限定名和類加載器來標識，出于同樣的安全原因。

ClassCastException、LinkageError 和 IllegalAccessError 根據(jù)實現(xiàn)有點不同，但根本原因是相同的類被不同的類加載器加載。

Java 類加載器備忘單

No class found

Variants

• ClassNotFoundException
• NoClassDefFoundError

Helpful

• IDE class lookup (Ctrl+Shift+T in Eclipse)
• find *.jar -exec jar -tf '{}'; | grep MyClass
• URLClassLoader.getUrls() Container specific logs

Wrong class found

Variants

• IncompatibleClassChangeError AbstractMethodError NoSuch(Method|Field)Error
• ClassCastException, IllegalAccessError

Helpful

• -verbose:class
• ClassLoader.getResource() javap -private MyClass

More than one class found

• LinkageError (class loading constraints violated)
• ClassCastException, IllegalAccessError

Helpful

• -verbose:class
• ClassLoader.getResource()