Tomcat中jsp热部署实现原理

    我们知道在开发工程的时候jsp文件是即修改即生效的，由于比较好奇就研究了一下tomcat对于jsp热部署的实现原理，总结沉淀一下吧。

    Tomcat  jsp热部署的实现原理大体是这样的，每个JSP页面从上次访问到下次访问总是有默认几秒的缓存时间的，也就说并不是严格的即修改即生效，tocmat7默认是有4秒的缓存延迟的。

    这个默认的缓存延迟是在类EmbeddedServletOptions的private intmodificationTestInterval = 4;这个属性定义的。

    如果过了4秒缓存时间即失效，这个时候tomcat就会读取jsp的modified时间戳和work目录下编译好的class文件的modified的时间戳作对比。

    如果相等则class文件没有过期，则不会重新编译jsp文件，如果过期了则重新将jsp编译成java，并进一步编译成class。同时调用JasperLoader来重新加载这个有jsp编译好的class文件。下面具体分析一下这个过程：

大体的类通信时序图是这样的：

其中上文说的时间戳的校验逻辑主要封装在JDTCompiler的isOutDated方法里面，这个方法的主要源代码如下：

    其中第一个红框就是涉及到的N秒缓存逻辑，如果缓存没有失效，则不会重新加载，这个ctxt.getOptions()获取到的其实是EmbeddedServletOptions类，这个类默认定义的时间间隔是：

    在实验的时候我比较好奇就收到把这个值改为了40，果然jsp并没有及时生效，而是过了40秒之后才生效。

    第二个红框检测的是获取work目录下的class文件的对象。

    第三个红框就是比较class文件的时间戳和JSP文件的时间戳，如果不相等则重新编译加载（上面时序图的流程）。这个就是jsp的热部署流程！