問題描述

最近在升級Tomcat，我們有兩個絕對相同的伺服器（硬體和作業系統）。兩者都執行Jdk_1.8.0_191，一臺安裝了 tomcat_7.x，一臺安裝了 tomcat_8.5.60。

啟動和VM引數以及特定於應用程式的設定完全相同。唯一的區別是IP地址，當然還有主機名。

下面情況都是相同war包相同Tomcat情況下：

Tomcat7載入Jar包原理

Tomcat自己實現了自己的類載入器，用於載入自己本地專案中jar包中的所有class檔案，所以在相同的類載入器下，

如果有相同路徑名和類名那麼載入順序就是根據jar包的順序來決定的。誰的jar包先進來，那麼就先載入哪個類。

但是為什麼在Tomcat7所有環境都能執行正常，而在Tomcat8中就不行了呢？ 於是就查看了Tomcat7的原始碼在Context載入專案中的jar包時

Tomcat7載入jar部分，在WebappLoader.setRepositories()方法中，粘貼出其中重要程式碼。

 // Looking up directory /WEB-INF/lib in the context
    NamingEnumeration<NameClassPair> enumeration = null
 
;
    try {
        //這一句是獲得jar包的路徑
        enumeration = libDir.list("");
    } catch (NamingException e) {
        IOException ioe = new IOException(sm.getString(
                "webappLoader.namingFailure", libPath));
        ioe.initCause(e);
        throw ioe;
    }

list是獲得了應用中WEB-INF下lib下所有jar包的路徑。我們跟蹤進去發現FileDirContext

Arrays.sort(names);             // Sort alphabetically

我們可以發現在Tomcat7中對獲得所有jar包作了一個排序的動作。對jar包進行了首字母a-z進行了排序。

而我們所期望載入的那個jar包首字母正好在錯誤jar包的前面。

Tomcat8載入Jar包原理

上面我們知道了為什麼在所有專案中Tomcat7能啟動起來的原因了，是因為Tomcat7做了排序的動作，那麼在Tomcat8載入Jar包時，又是怎麼做的呢？

Tomcat9在載入原始碼的時候是通過StandardRoot.processWebInfLib()方法進行載入的

    protected void processWebInfLib() throws LifecycleException {
        WebResource[] possibleJars = listResources("/WEB-INF/lib", false);
        for (WebResource possibleJar : possibleJars) {
            if (possibleJar.isFile() && possibleJar.getName().endsWith(".jar")) {
                createWebResourceSet(ResourceSetType.CLASSES_JAR,
                        "/WEB-INF/classes", possibleJar.getURL(), "/");
            }
        }
    }

在這我們可以看到Tomcat沒有對取出來的Jar作任何動作，僅僅是File file = new File()這樣遍歷出來了。

那麼為什麼相同的Tomcat8相同的War包在Windos能啟動起來，但是在Linux中都啟動不起來呢？

經過試驗發現Java的獲取資料夾下面的所有檔案是跟作業系統的檔案系統有關係的，相同的資料夾內容，在Windows中取出來，輸出名字你會發現輸出是經過a-z排序過的，

但是在Linux中你可以根據命令ll -fi就可以輸出自然順序，你會發現沒有什麼規律可言。

解決

到這裡上面描述的所有問題我們都能解釋通了，接下來就該如何解決了。

1. 修改Tomcat9的原始碼，在獲取所有Jar包的時候，也對它進行排序
2. 解決掉有衝突的檔案，使用統一的版本。以下命令可以找到重複的jar包引用：

mvn dependency:tree -Dverbose -Dincludes=io.netty

第一種解決辦法只能解決一時問題，即專案能正常啟動起來，但是一旦隨後涉及到了相關類的修改，那麼衝突類的哪個類呢？那麼這個問題肯定是一個定時炸彈。

第二種方案是找到有衝突的檔案，然後找出不用的那個給刪除掉，但是發現刪除一個又會蹦出其他的，刪除了好幾個以後發現由於買的專案程式碼不規範，

所以這種現象特別多，如果單純靠手工篩選的話極其麻煩。