引言： Tomcat是目前開發中使用非常廣泛的Web伺服器，其提供了很多優秀和簡便易用的功能。我們這裡的血案就是由於在部署過程中，不慎而引發的....

1. 問題的出現

    在我們的系統後臺每日定義會觸發一些任務操作，進行一些資料的處理和更新，從上線到現在已經正常運行了將近3個多月了。忽然某一天，發現其資料不對，大量的資料都是被執行了2次某個定時任務A造成的。 查詢日誌，的確是執行了2次。但是之前為什麼是正常的呢？詭異詭異....

    環境： Tomcat 6.0.x

2.  血案的發生

   由於在生產系統中，資料出現了問題，這個是一個非常嚴重的事情。於是首先把這個定時任務A先停掉，清理資料。由於資料量比較大，所以就有了焦頭爛額的幾天修正系統資料的過程。

3.  問題分析

    3.1  任務A本身有問題嗎？

          之前都是正常執行的， 只在最近幾天才發生問題。而且基於日誌分析，其資料操作是正確的，問題是操作了2遍。

    3.2  任務A實現分析

          首先懷疑其實現的程式碼上是否有問題？ 經過分析其是基於Quartz來實現定時任務的，Quartz是老牌的定時框架，不會出現問題。 是否是我們自己使用的方式問題，並只在特定情況下才會出現問題呢？ 經過程式碼的排查分析，沒有問題。

     3.3  程式碼變更記錄分析

         是否是某個同事無意之前做的什麼修改造成的呢？ 經過針對程式碼變更記錄和上線記錄的分析，排除這個可能。

4.  系統日誌分析

     在排除了這個任務A自身問題之後，將目光轉移到了環境本身。  部署環境是Tomcat6.  下載了Tomcat日誌檔案進行分析，逐漸找到了某些蛛絲馬跡，從而剝絲抽繭般的發現了問題的原因。

     在系統日誌中，發現了若干在應用部署過程中的錯誤資訊，這個引起了我的懷疑。是否是由於在部署中的錯誤造成的呢？

     經過排查，確定是部署不慎造成的，而且是由於Tomcat本身的Reloadable特性造成的問題。

 5.  問題場景的還原

     1.  某位同事由於在修改某個問題，只修改了某幾個Class檔案，故其將編譯後的class檔案在伺服器上直接進行了替換。

      2.   由於Tomcat本身設定了Reloadable的屬性，故Tomcat在檢測到class檔案發生變化之後，對WebApp的應用進行了重新載入：先解除安裝，再重新載入。

      3.   在解除安裝的過程中，程式出錯，解除安裝失敗，原來的應用沒有解除安裝成功，保留在Tomcat的快取之中。

     

     4.   雖然解除安裝失敗，Tomcat繼續載入新的WebApp應用。這裡請注意： 新載入的WebApp應用在專案名稱之後加了一個2，比如原來的專案名稱是AAA, 新的專案名稱就是AAA2。 重新定義了一個專案名稱哦，我當時就知道，這裡就是問題所在。

     

  此時，二次載入的Web應用，也由於某些原因失敗了。

    

5.  運維的同事，注意到了這些錯誤資訊，由於重新啟動了Tomcat，這次Tomcat正常啟動了

     第一個Web應用正常啟動了

     

    第二個Web應用也正常啟動了，參看日誌。

    

6.  於是在我們的Tomcat中就出現了兩個一模一樣的Web應用，換句話說，就是出現了兩個一模一樣的定時任務。 這個就是為什麼定時任務會被執行2次的原因。

7. 解決以及應對

      7.1 不允許動態的在生產系統中，替換class檔案

     7.2  在系統部署和上線過程中，需要進行日誌分析，日誌可以告訴我們一切的技術細節和內容。

     7.3  將Tomcat的Reloadable設定置為false

          <Context path="/helloApp" docBase="helloApp" debug="0" reloadable="false"/>  

8.  reloadable引數說明

     Context>代表了執行在<Host>上的單個Web應用，一個<Host>可以有多個<Context>元素，每個Web應用必須有唯一的URL路徑，這個URL路徑在<Context>中的屬性path中設定。      

    <Context path="/helloApp" docBase="helloApp" debug="0" reloadable="true"/>  

<Context>元素的屬性:
path:指定訪問該Web應用的URL入口。
docBase:指定Web應用的檔案路徑，可以給定絕對路徑，也可以給定相對於<Host>的appBase屬性的相對路徑，如果Web應用採用開放目錄結構，則指定Web應用的根目錄，如果Web應用是個war檔案，則指定war檔案的路徑。
reloadable:如果這個屬性設為true，tomcat伺服器在執行狀態下會監視在WEB-INF/classes和WEB-INF/lib目錄下class檔案的改動，如果監測到有class檔案被更新的，伺服器會自動重新載入Web應用。
在開發階段將reloadable屬性設為true，有助於除錯servlet和其它的class檔案，但這樣用加重伺服器執行負荷，建議在Web應用的發存階段將reloadable設為false。

9.  總結

     由於一個微小的變化引發的問題，在這之前一直正常。由於動態替代class，引發自動部署；部署失敗，導致出現了2個相同的部署包。再次重啟，然後2個快取包都正常啟動。 其本質原因是Tomcat在解除安裝應用的過程中，如果出現異常，則無法繼續刪除快取；在重新載入的時候，無法清空已有的快取，這個才是問題的根源。

    我們姑且把這個問題，作為Tomcat的一個bug吧，只在特定情況下才會出現的問題。