Hot deployment and hot loading for Java

Hot deployment and hot load are actually two similar but different concepts one, hot deployment and hot load

When the app is running, upgrade the software without restarting it in two ways, hot deployment and hot load.

For Java applications, a hot deployment is the redeployment of the project while the server is running, and the hot load reloads the class at runtime to upgrade the app.

Second, the realization principle

The implementation principle of unloading relies on Java's class loading mechanism, which can be summed up as a background thread when the container is started, timed timestamp change of the detection class file, and reload the class if the timestamp of the class is changed.

Contrast reflection mechanism, reflection is to obtain the class information at run time, change the program behavior by the dynamic call, and unloading change the program behavior by reloading the class information at run time.

The principle of hot deployment is similar, but it is a direct reload of the entire application, which frees up memory, the specific heat load is more clean and thorough, but also more time-consuming.

III. application in Java 1. Production environment

Thermal deployment as a more flexible mechanism, in the actual production of the use of or have, but relatively few, unloading is basically no application. Analyzed as follows

• First, security

Unloading this method of directly modifying the JVM bytecode is difficult to monitor, different from SQL and other execution can record the log, the modification of direct bytecode is almost impossible to record the changes in code logic, the impact of the existing code behavior is difficult to control, for the more security-oriented applications, the greater the risk of hot load, It's like replacing an engine with a plane in flight.

• Ii. scenarios that apply

Most of the technology is tied to demand, and few scenarios require hot deployment.

1. Deploy frequently and start long-time applications
2. Apps that can't stop a service

In production, there are no applications that need to be deployed frequently, even agile, and faster is a once-a-week iteration, and with business partitioning and modular programming, the cost of deployment is completely negligible, and for existing applications, startup takes longer and is not too long to endure, if it's really that long, The more you should consider is how to split the module, distributed deployment.

For applications that cannot stop the service, such as distributed applications such as today's cloud computing platforms, which can be used in batches to meet demand, a similar thermal deployment scenario should be the solution that is put in the final consideration.

2. Development environment

In production, there will be no frequent deployment and start-up of long-time applications, but due to the rise of cloud computing, thermal deployment still has its applications. And the hot load is a little bit of fire, too dangerous. However, in the development and debug, the frequent launch of applications are everywhere, the hot load mechanism can greatly improve the development efficiency. These two mechanisms, in the development of another kind of salutation-developer mode.

For large projects: it is often time to start/stop waiting for a few minutes. The more wasted time is, for a class of methods in the debugging process, if modified multiple times, need to repeatedly start and stop the server, wasting more time.

Taking the current CRM project as an example, its start time is 5m, with a one-day debug restart 10 times, one months of work 20 days to calculate, the annual restart time of 25 people, if you can fully use the hot load, save the restart for nearly 1 months each year.

CRM Pool Startup time consuming

1.STRUTS2 Hot Load

Hot load in STRUTS2 is developer mode, in Struts.xml configuration

You can then debug the program without restarting the server after you change the Struts.xml file.

2. Use Tomcat hot load during development

Tomcat itself turns on hot deployment by default, but hot deployment is a direct reload of the entire application, which is much more time consuming than restarting the server, and what we need is a hot load, that is, which class is modified, which only reloads the class, which takes almost 0 of the time. For tomcat5.x and above, have supported a certain degree of heat load, but this way only for the code line level, that is, if the new deletion method, annotations, classes, or variables are invalid, can only restart, this is the way I am currently in the development of the company, can significantly reduce the number of restarts in debug, Improve development efficiency

1. Set the **context reloadable** value of the Tomcat Server.xml file to **false** or edit the Cancel Auto modules option in the Web reloading.

OR 2. Modify the server configuration in eclipse

This can be done after modifying the code, does not automatically restart the server, and only load the code, a new line of Java code ctrl+s after the page or call the interface directly to see the effect, no need to restart Tomcat.

3. Use Tomcat hot load in remote debug

Tomcat's hot-load mechanism not only allows the remote debugging of Tomcat, but also supports hot deployment via Eclipse Debug remote to remote tomcat, modifies the local code, and ctrl+s the interface after the page is flushed directly. You can discover that remote Tomcat has hot-loaded the local code.

4.jrebel Plug-in mode

Jrebel plug-ins can be more thorough hot load, not only the class, and even support the hot load of configuration files such as spring, but the company project development environment is complex, the current configuration in eclipse has not been successful, only using Tomcat's own hot load mechanism.

Summarize

In the actual production of hot deployment in the cloud computing a lot, but unloading not, and in the development, hot load can significantly improve productivity, strongly recommend the use of hot load mode, not only Tomcat, most other servlet containers also support this way, you can search for the relevant skills.

A detailed approach to Tomcat thermal deployment and hot load

In the project development process, I often want to change the java/jsp file, but do not want to start the server (the server from the new start time), want to directly get (debug) results. There are two ways to hot deploy and hot load:

1. Hot load: Set reloadable= "true" in the Server.xml context property

1	<Context docBase="xxx"path="/xxx"reloadable="true"/>

2. Hot deploy: Set autodeploy= "true" in the Server.xml-to context property

1	<Context docBase="xxx"path="/xxx"autoDeploy="true"/>

You can also:

1 Code copy Code Collection code

123456

"localhost" Code class= "Java plain" >appbase= "WebApps"        unpackwars= "true" autodeploy= "true" &NBSP;&NBSP;&NBSP;&NBSP;&NBSP;&NBSP; xmlvalidation= "false" xmlnamespaceaware= "false" > <context docbase= "xxx" path= "/xxx" />

3. Difference:

Gegas: The server will listen to the class file changes, including Web-inf/class,wen-inf/lib,web-inf/web.xml and other files, if changes occur, the local load, do not empty session, do not release memory. The development is used much, but consider the case of memory overflow.

Hot deployment: The entire project is newly deployed, including your new hit . War file. Clears the session and frees up memory. The project is packed with more time.

Modifications to the above configuration file can also be implemented through Eclipse settings

Project name for Eclipse right: Properties->tomcat->general->make this context as reloadable (reloadable= "true") do not select Project name for Eclipse right-click: Tomcat project->update Context Definition

Hot deployment and hot loading for Java