The implementation of Tomcat's thermal deployment principle: When Tomcat starts, it will start a thread every once in a while to determine whether the class that is loaded in the application has a political change (changes in the total number of classes, class changes), and if it changes, it will stop the application's startup thread, clear the reference, and set the WebappClassLoader that loaded the app to null, and then create a new WebappClassLoader to reload the app. The sequence diagram of a series of stops after a hot deployment in Tomcat discovers a class reform is as follows:
The sequence diagram above only the key flow of the steps to draw out, there are some details of the processing has not been completely painted, this part of the code inheritance structure is relatively complex, debug the above process, various jumps. First, explain the timing diagram above, which starts with the Webapploader backgroundprocess () method, and Backgroundprocess () is one of the threads in the thread that started with Tomcat. Is the portal to the Tomcat Hot deployment code. One of the most critical two steps. is the Stopinternal () method of Webapploader and the Stop () method of WebappClassLoader. In the Stopinternal () of Webapploader
protected void throws lifecycleexception {... // Throw away our current class loader null;}
In ((Lifecycle) classLoader). Stop (); The ClassLoader is an example of WebappClassLoader. This is called the Stop () method of WebappClassLoader. As follows:
Public voidStop ()throwslifecycleexception {//clearing references should be do before setting started to//false, due to possible side effectsclearreferences (); Started=false; intLength =files.length; for(inti = 0; i < length; i++) {Files[i]=NULL; } length=jarfiles.length; for(inti = 0; i < length; i++) { Try { if(Jarfiles[i]! =NULL) {jarfiles[i].close (); } } Catch(IOException e) {//Ignore} Jarfiles[i]=NULL; } notfoundresources.clear (); Resourceentries.clear (); Resources=NULL; Repositories=NULL; Repositoryurls=NULL; Files=NULL; Jarfiles=NULL; Jarrealfiles=NULL; Jarpath=NULL; Jarnames=NULL; Lastmodifieddates=NULL; Paths=NULL; Hasexternalrepositories=false; Parent=NULL; Permissionlist.clear (); Loaderpc.clear (); if(Loaderdir! =NULL) {deletedir (loaderdir); } }
You can see that the stop () method does a lot of cleanup work for references. where the Clearreferences ()
protected voidclearreferences () {//de-register Any remaining JDBC driversClearreferencesjdbc ();//Stop Any threads the Web application startedclearreferencesthreads ();//Check for leaks triggered by threadlocals loaded by this class loaderCheckthreadlocalsforleaks ();//Clear RMI Targets loaded by this class loaderclearreferencesrmitargets ();//Null out any static or final fields from loaded classes,//As a workaround for apparent garbage collection bugs if(clearreferencesstatic) {clearreferencesstaticfinal (); } //Clear the introspectionutils cache.introspectionutils.clear ();//Clear the ClassLoader reference in Common-logging if(clearreferenceslogfactoryrelease) {org.apache.juli.logging.LogFactory.release ( This); } //Clear The resource bundle cache//This shouldn ' t is necessary, the cache uses weak references but//it has caused leaks. Oddly, using the leak detection code in//Standard host allows the class loader to be GC ' d. This have been seen//On Sun and not IBM JREs. Maybe a bug in Sun ' s GC impl?clearreferencesresourcebundles ();//Clear The ClassLoader reference in the VM ' s bean introspectorjava.beans.Introspector.flushCaches (); }
Work has also been done to clear the application thread. Finally, ClassLoader = null is executed in WebappClassLoader's Stopinternal () method; The instance of this classloader is not referenced. Finally, call the Startinternal () method in Webapploader, create a new WebappClassLoader instance, and start reloading the app. The hot deployment process to this tomcat is complete.
Tomcat source Interpretation (1) –tomcat Thermal Deployment Implementation principle