Java Hot Update

First, the solution

1) custom class loader.

The first thing to understand is that class is not just the same as the class name, but also the classloader to load it. The JVM internally stipulates that a ClassLoader cannot repeat the definition of a class, that is, to redefine a class, you must use a completely new classloader.

The condition of the JVM's internal class being unloaded and its harsh, even no explicit method can be called directly, only when loading the class loader instance of the type is unreachable state, that is, there is no instance, class can be unloaded. (Starting the ClassLoader instance is always reachable state, the type loaded by the startup ClassLoader may never be uninstalled)

<span style= "White-space:pre" ></span>public class<?> loadclass (String name, Boolean resolve) throws ClassNotFoundException {class<?> clazz = null;//First checks whether the requested type has been loaded into the namespace by this class loader, and if it has already been loaded, return directly; if (Name.startswith ("Com.wafer") | | name.contains ("Service")) {if (resolve) {resolveclass (clazz);//link specified Java class}//if CL The Moeloader hcl = new Moeloader (URL), clazz = Customload (name, HCL); return (clazz);} If the package name of the class is "java." Start, then there is the system default loader load try {//Get the system default load Clclassloader system = Classloader.getsystemclassloader (); clazz = System.loadclass ( name); Load the name of the class if (clazz! = null) {if (resolve) resolveclass (clazz); return (clazz);}} catch (ClassNotFoundException e) {//Ignore}return Customload (name, this);}

The core of this example is to cache the class that you have loaded, and when it needs to be loaded again, if there is a change, it can be a new classloader, so that it will take effect immediately.

Jrbel is a hot-update scenario that is implemented by adding javaagent in the startup parameters, the instrumentation technology provided by the JVM's underlying, to change the way the object is generated.

2) JVMTI Virtual Machine tool interface

JPDA is an abbreviation for the Java Platform debug architecture. With the API provided by JPDA, developers can easily and flexibly build Java debugging applications. The JPDA consists of three parts: the Java Virtual Machine tool Interface (JVMTI), the Java Debug Line Protocol (JDWP), and the Java Debugging Interface (JDI). Reference resources (http://www.ibm.com/developerworks/cn/views/java/libraryview.jsp?search_by= deep +java+ debug System)

<span style= "White-space:pre" ></span>List<Connector> connectors = Bootstrap.virtualmachinemanager (). Allconnectors (); Socketattachingconnector sac = null;for (Connector connector:connectors) {if (Connector instanceof Socketattachingconne ctor) {sac = (socketattachingconnector) connector;}} if (sac! = null) {map<string, connector.argument> defaultarguments = sac.defaultarguments (); Connector.argument Hostarg = defaultarguments.get ("hostname"); Connector.argument Portarg = Defaultarguments.get ("port"), Hostarg.setvalue ("localhost");p ortarg.setvalue ("8787"); Virtualmachine vm = Sac.attach (defaultarguments); list<referencetype> rtList = Vm.classesbyname ("Com.wafer.demo.jdi.Foo"); Referencetype RT = Rtlist.get (0); Map<referencetype, byte[]> newbytecodemap = new Hashmap<referencetype, byte[]> (1);//Get bytecode for a specific class, send to Virtual machine byte [] Newbytecode = Gennewbytecodeusingjavassist (), Newbytecodemap.put (RT, Newbytecode), if (Vm.canredefineclasses ()) { Vm.redefineclasses (NewbytecODEMAP);}} 

This is how Eclipse's thermal update is implemented, and Eclipse adds-agentlib:jdwp=transport=dt_socket,suspend=y,address=localhost in the JVM parameters when you start with debug : 63597, when a code change is detected, the changed bytecode is sent to the app via JDWP.

Btrace can send bytecode to the application, monitor the intercepted class, and implement it in the same way as JVMTI. Connect to the app using Virtualmachine.attach (PID).

Java Hot Update