最近遇到一個問題： 環境中的JSP頁面在被修改以後沒有在瀏覽器中表現出來， 呈現出的仍然是舊版的樣子。

這個事情比較奇怪，但凡有初級web 開發經驗的人都瞭解，在web容器是tomcat的開發環境中修改jsp頁面後無需重啟tomcat，僅僅重新整理就可以在瀏覽器中看到效果，這已經是一個人盡皆知的事情了，那這個么蛾子是怎麼飛出來的？

本著生活問度娘，技術求谷哥的精神，遂google之，原理還是挺有意思的：

1. JSP怎麼工作

這個不多說了，跟我們問題關鍵的一點就是JSP使用時會被容器編譯成java的編譯後文件：.class檔案，而後使用的都是這個.class檔案。這個檔案的路徑在tomcat中是：

%catalina_home%\work\Catalina\localhost\<context-name>\org... 

這裡就有一個問題了，既然JSP需要被編譯成.class檔案才能使用（區別於解釋性的指令碼語言），那麼要實現“僅僅重新整理就能生效”的目的必然要求有人去編譯它，這個忙人是誰呢：tomcat ？

2. Tomcat 對JSP的預編譯機制

確實是Tomcat， 它的基本預編譯規則是：當接到一個對某JSP 頁面的請求時，檢查該JSP頁面與之前由該JSP頁面編譯出的.class檔案的時間戳，如果JSP頁面較新，那麼重新編譯，並覆蓋老的.class檔案，否則仍使用之前的.class檔案，並不進行再次編譯。

事情說得這，遇到的問題已經找到原因了，是時間戳引發的問題。

本著除惡務盡的原則，繼續研究了下，發現：

a. “僅僅重新整理就能生效” 只有在tomcat 的development 模式下才能生效，在生產模式下是無法生效的。Tomcat預設使用development模式，可以再檔案：Tomcat\conf\web.xml中把developmen t的值改為false來切換到生產模式。

b. 生產模式不檢查JSP頁面的時間戳，來進行recompile，所以JSP檔案被修改後只有通過重啟tomcat才能生效。這樣做的原因是每次去check時間戳會耗費較多的效能，所以建議在產品出廠時都設定為product模式。

c. 在生產模式下可以通過配置一個引數：checkInterval 來驅使tomcat 沒過一段時間去check JSP頁面的時間戳進行recompile， 雖有一定的延遲性但是也能達到“僅僅重新整理就能生效”， 但如果這個interval比較小，那仍對效能有拖累。這種情形有個特點有別於之前： 這種recompile被稱之為：“background compile”, 意識是說並不阻塞請求，只是觸發recompile，在recompile完成之前仍然使用舊版本，在完成之後才使用新版本

d. Development 模式中，對JSP頁面的check頻率也可以通過一個引數進行調節：modificationTestInterval。 比如說modificationTestInterval = 10s, 即是說在對某個JSP頁面進行時間戳檢查後的10s內，即便再有對該JSP頁面的請求也不進行時間戳檢查，當然也不會觸發recompile。如果modificationTestInterval = 0，那麼每次都會檢查時間戳。這個引數的預設值是4s。

e.  還有一種情形無法recompile： 一個JSP頁面作為子頁面被另外一個JSP頁面include， 如果子頁面發生了改變但是父頁面沒有，不會recompile（已經在tomcat7 中修改）

最後還有一個問題，自動編譯完成以後，tomcat是如何自動載入這些.class呢，好在這是另外一個問題了。