一、ClassLoader

sun.misc.Launcher類是java的入口，在啟動(dòng)java應(yīng)用的時(shí)候會(huì)首先創(chuàng)建Launcher類，創(chuàng)建Launcher類的時(shí)候回準(zhǔn)備應(yīng)用程序運(yùn)行中需要的類加載器。

Launcher作為JAVA應(yīng)用的入口，根據(jù)雙親委派模型，Laucher是由JVM創(chuàng)建的，它類加載器應(yīng)該是BootStrapClassLoader， 這是一個(gè)C++編寫的類加載器，是java應(yīng)用體系中最頂層的類加載器，負(fù)責(zé)加載JVM需要的一些類庫(kù)(<JAVA_HOME>/lib)?？梢酝ㄟ^(guò)一個(gè)簡(jiǎn)單的代碼驗(yàn)證一下我們的想法。

public class App {
    public static void main(String[] args) {
        ClassLoader classLoader = Launcher.class.getClassLoader();
    }
}

這里的classLoader是null，說(shuō)明Launcher確實(shí)是BootstrapClassLoader加載的，那么我們就會(huì)非常好奇，ExtClassLoader是什么時(shí)候創(chuàng)建的呢？翻看一下Launcher的構(gòu)造器的代碼。

    public Launcher() {
        sun.misc.Launcher.ExtClassLoader extClassLoader;
        try {
            extClassLoader = sun.misc.Launcher.ExtClassLoader.getExtClassLoader();
        } catch (IOException var10) {
            throw new InternalError("Could not create extension class loader", var10);
        }
        try {
            this.loader = sun.misc.Launcher.AppClassLoader.getAppClassLoader(extClassLoader);
        } catch (IOException var9) {
            throw new InternalError("Could not create application class loader", var9);
        }
        Thread.currentThread().setContextClassLoader(this.loader);
    }

Launcher在創(chuàng)建的時(shí)候，第一件事情就是獲取ExtClassLoader, ExtClassLoader在JVM中是一個(gè)單例， 創(chuàng)建過(guò)程也是通過(guò)獲取環(huán)境變量來(lái)獲取ext加載的目錄，生成一個(gè)ExtClassLoader，ExtClassLoader是URLClassLoader的子類。

       public static Launcher.ExtClassLoader getExtClassLoader() throws IOException {
            if (instance == null) {
                Class clazz = Launcher.ExtClassLoader.class;
                synchronized(Launcher.ExtClassLoader.class) {
                    if (instance == null) {
                        instance = createExtClassLoader();
                    }
                }
            }
            return instance;
        }

在獲取ExtClassLoader之后，以此作為父類加載器創(chuàng)建一個(gè) sun.misc.Launcher.AppClassLoader, AppClassLoader的加載路徑是java.class.path標(biāo)記的路徑，相同的，AppClassLoader也是URLClassLoader的子類。最終會(huì)將當(dāng)前線程的上下文類加載器設(shè)置為AppClassLoader。 通過(guò)上述分析，當(dāng)我們需要獲取當(dāng)前應(yīng)用程序的AppClassLoader或者ExtClassLoader的時(shí)候，可以直接使用Launcher來(lái)訪問(wèn)。

public class App {
    public static void main(String[] args) {
        ClassLoader appClassLoader = Launcher.getLauncher().getClassLoader();
        ClassLoader extClassLoader = appClassLoader.getParent();
    }
}

二、Thread上下文ClassLoader的思考

java程序并不是一個(gè)單獨(dú)的可執(zhí)行文件，而是由一組.class文件組成。在應(yīng)用程序啟動(dòng)的時(shí)候，并不是所有的類都會(huì)被加載，一個(gè)類被加載的時(shí)候會(huì)使用引用這個(gè)類的那個(gè)類的加載器來(lái)加載，也就是xxx.class.getClassLoader()。但是在日常使用的時(shí)候，還有一種是通過(guò)Thread的上限文獲取類加載器。

在java中為什么需要上下文類加載器呢，這個(gè)就是一個(gè)非常有意思的問(wèn)題。 我們都知道java類加載的雙親委派模型，在加載一個(gè)類的時(shí)候，會(huì)優(yōu)先委派給父類加載器，這樣保證不會(huì)出現(xiàn)類被重復(fù)加載，也保證了java一些基礎(chǔ)類可以穩(wěn)定的存在，不會(huì)被用戶自定義類頂替掉。

雙親委派模型并不是完美的，在一些場(chǎng)景下會(huì)出現(xiàn)一些比較難解決的問(wèn)題，舉個(gè)例子，在使用SPI的時(shí)候，ServiceLoader是通過(guò)BootStrap類加載器加載的，在執(zhí)行到加載用戶編寫的擴(kuò)展類的時(shí)候，如果使用當(dāng)前類的類加載器，是肯定無(wú)法加載到用戶編寫的類的，這個(gè)時(shí)候就無(wú)法繼續(xù)執(zhí)行了，所以這個(gè)時(shí)候就需要使用Thread的上下文類加載器，查看源碼的時(shí)候我們就發(fā)現(xiàn)，在用戶不主動(dòng)傳遞ClassLoader的時(shí)候，會(huì)獲取當(dāng)前上下文類加載器，這樣應(yīng)用程序才能正常的執(zhí)行。

    public static <S> ServiceLoader<S> load(Class<S> service) {
        ClassLoader cl = Thread.currentThread().getContextClassLoader();
        return ServiceLoader.load(service, cl);
    }

到此這篇關(guān)于JAVA中的Launcher類解析的文章就介紹到這了,更多相關(guān)JAVA的Launcher內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論