Analysis of class offload, hot swap, and Tomcat's thermal deployment

a class of hot replacements

The important method in ClassLoader

LoadClass
ClassLoader.loadClass(...)Is the entry point of the ClassLoader. When a class does not indicate what loader to load, the JVM defaults to loading the class with the Appclassloader loader, and the entry of the method called is LoadClass (...). If a class is loaded with a custom ClassLoader, then the JVM will call this custom Classloader.loadclass (...). method to load some other class files that are referenced within the class. Overloading this method, can implement the way of custom loading class, abandon the parent delegation mechanism, but even if not adopt the parent delegation mechanism, such as the related class in the Java.lang package or can not customize a class with the same name instead, mainly because the JVM parses, validates the class, it will make relevant judgments.

DefineClass
System comes with the ClassLoader, the default loader is Appclassloader,classloader load a class, the final call is DefineClass (...) method, you are wondering if you can call DefineClass (...) repeatedly. method to load the same class (or modify it), and finally find that the call is repeated with a related error:

java.lang.LinkageError attempted duplicate class definition

So if a class is loaded by a ClassLoader instance, it can no longer be loaded by this ClassLoader instance (the load here refers to the call of the Defileclass (...). Reload the bytecode, parse, and validate. )。 and the system default Appclassloader loader, they will cache the loaded class, reload, and then directly fetch the cache. With respect to unloading, you can only recreate a classloader and then load the class file that has already been loaded.

Two class uninstall

Class can also be unload in Java. The class and meta information in the JVM is stored in the PermGen space area. If you load a lot of class files, you may cause the PermGen space area to overflow. Cause: Java.lang.OutOfMemoryErrorPermGen space. For some classes we may only need to use one time, it is no longer necessary, or we can modify the class file, we need to reload Newclass, then Oldclass is no longer needed. So how can the JVM unload class?

The class in the JVM can be reclaimed by GC only if the following three conditions are met, that is, the class is unloaded (unload):

• All instances of this class have been GC.
• The ClassLoader instance that loads the class has already been GC.
• The Java.lang.Class object for this class is not referenced anywhere.

The timing of the GC is not controllable, so the same is true of our unloading of class.

1, a type loaded by the startup ClassLoader is not likely to be unloaded during the entire run (JvmAndJlsSpecification).2, types that are loaded by the system ClassLoader and the standard extension classloader are unlikely to be unloaded during the run, because instances of the system classloader or standard extension classes are generally accessed directly or indirectly throughout the run, reachingunreachableclassloader instance or Span class= "Typ" >class ( java.lang. class) instances are also present in the heap and are also subject to garbage collection rules. 3, The type loaded by the developer-defined ClassLoader instance can only be unloaded in a very simple context, and is generally done by forcing the garbage collection of the virtual machine to be invoked. In a scenario that can be expected to be slightly more complicated (especially many times, When a user develops a custom class loader instance with a cached policy to improve system performance, the loaded type is almost less likely to be unloaded during runtime (at least the unloaded time is indeterminate).         

Combined with the above three points, an already loaded type is less likely to be unloaded at least the time of the uninstallation is indeterminate. At the same time, we can see that developers should not make any assumptions about the type unloading of virtual machines when developing code to implement specific functions in the system.

three the loading and unloading of classes in Tomcat

Tomcat is not so hot-loaded as it is more accurate than hot-deployment. Because for an application where the class file has been modified, Tomcat uninstalls the app (Context) and reloads the app, which is the key to customizing the ClassLoader application. Here is an article that is a good introduction to the application of Tomcat in ClassLoader.

When Tomcat starts, the ClassLoader loads the process:

1 when Tomcat starts, it uses the system classloader that is appclassloader to load {catalina.home}/bin the jar package inside, that is, Tomcat launches the related jar package. 2 Tomcat Launcher Class bootstrap has 3 ClassLoader properties, Catalinaloader, Commonloader, Sharedloader Default in Tomcat7 they initialize to the same Standardclassloader instance. The specific can also be {catalina.home}/bin/bootstrap.jar configured in the Catalina.properites in the package. 3 Standardclassloader Load {catalina.home}/lib All of the following Tomcat-used jar packages. 41 context containers, representing an app app. Context–>webapploader–>webclassloader. and Thread.contextclassloader=webclassloader. The JSP files, class classes, Lib/*.jar packages in the application are Webclassloader loaded.

When the JSP file is modified, the Tomcat update step:

1 but when accessing 1.jsp, 1.jsp packaging class Jspservletwrapper will compare the latest modification time of 1.jsp files and the last modification time to determine whether 1.jsp has been modified. 2 1.jsp if modified, then jspservletwrapper clears the relevant reference, including the 1.jsp compiled servlet instance and the Jasperloader instance that loads the servlet. 3 re-create a Jasperloader instance, reload the modified 1.jsp, and regenerate a servlet instance. 4 returns the modified 1.JSP content to the user.

When the class file under the app is modified, the Tomcat update step:

1 The context container will have specialized threading to monitor the changes of the classes under the app. 2 If a class is found to have been modified. Then call Context.reload (). Clear a series of related references and resources. 3 then innovate create a Webclassloader instance to reload the class required under the app.

In a certain scale of application, if the file changes several times, restart many times, java.lang.OutOfMemoryErrorPermGen space This error occurs very frequently. The main reason is that each reboot reloads a large number of classes, exceeding the size of the PermGen space setting. Two conditions can cause permgen space overflow. The GC (garbage Collection) does not clean up the PermGen space during the main program run time (the non-controllable line of the GC), and the class that the Webclassloader loads before the restart has a reference elsewhere.

Analysis of class offload, hot swap, and Tomcat's thermal deployment