Custom classloader for hot deployment of core Java application logic modules

Http://waterdh.iteye.com/blog/520399

This article mainly discusses the feasibility of hot deployment of partial modules in Java applications based on the characteristics of classloader and problems encountered in the actual product environment.

We know that some Web applications provide the ability to automatically detect and load webapps, but most of the time, it is equivalent to restarting webapps, and data stored in the memory will also be lost, it cannot flexibly meet the needs. Although the osgi framework also provides hot module deployment, the application is limited to the osgi framework for hot deployment, which sometimes outweighs the loss. Therefore, we want to customize classloader based on actual needs and flexibly specify which classes are reloaded and which classes are not needed.

Let's get down to the truth and implement our practices. Here we will briefly introduce the classloader mechanism of Java:

We can see that the classloader hierarchy in the virtual machine is loaded by the classloader of the outermost layer to the class specified by the fully qualified name. If the load fails, it is delegated to the parent classloader of the classloader, to root classloader.

 

Java code  

1. Protected synchronized class <?> Loadclass (string name, Boolean resolve)
2. Throws classnotfoundexception
3. {
4. // First, check if the class has already been loaded
5. Class C = findloadedclass (name );
6. If (C = NULL ){
7. Try {
8. If (parent! = NULL ){
9. C = parent. loadclass (name, false );
10. } Else {
11. C = findbootstrapclass0 (name );
12. }
13. } Catch (classnotfoundexception e ){
14. // If still not found, then invoke findclass in order
15. // To find the class.
16. C = findclass (name );
17. }
18. }
19. If (RESOLVE ){
20. Resolveclass (C );
21. }
22. Return C;
23. }

 

Here, our custom classloader can load classes under the specified package by reloading the loadclass method, and all the other classes are loaded by the parent classloader. The defineclass method of classloader is used here, so that our classloader can load class files at any specified position.

 

 

Java code  

1. Public class myclassloader extends classloader {
2. Public static concurrenthashmap <string, class <?> Classes = new concurrenthashmap <string, class <?> ();
4. Public static mqclassloader instance = new myclassloader ();
5. // Construct a custom classloader and specify the parent classloader
6. Public myclassloader (){
7. Super (thread. currentthread (). getcontextclassloader ());
8. }
10. Public class <?> Load (string name, byte [] data, Boolean resolve ){
11. Class <?> Klass = defineclass (name, Data, 0, Data. Length );
12. If (RESOLVE)
13. Resolveclass (Klass );
14. Classes. Put (name, Klass );
15. Return Klass;
16. }
18. Public class <?> Loadclass (string name, Boolean resolve) throws classnotfoundexception {
19. Object value = classes. Get (name); // check the cache
20. If (value! = NULL & value! = Invalid ){
21. Class <?> Klass = (class <?>) Value;
22. If (RESOLVE)
23. Resolveclass (Klass );
24. Return Klass;
26. } Else {// The cache does not exist
27. Byte [] DATA = read (findclassfile (name); // read class files
28. If (Data = NULL)
29. Return super. loadclass (name, resolve); // submit it to the parent classloader to load the class file
30. Else {
31. Try {
32. Lock. Lock ();
33. Object cc = classes. Get (name); // check the cache
34. If (CC! = NULL ){
35. Return (class <?>) CC;
36. } Else
37. Return instance. Load (name, Data, resolve); // load your own class file
38. } Finally {
39. Lock. Unlock ();
40. }
41. }
42. }
43. }
44. }

 

The code above describes the loading logic of the custom classloader. findclassfile () is the class file method that you need to find the class file from where you define it.

The defineclass method can be flexibly used for Distributed Dynamic computing. hadoop mapreduce should use this method to ensure the transmission and operation of processing classes between Server clusters.

 

Java code  

1. /**
2. * Reinitialize to implement the class specified by the overload.
3. */
4. Public static void reset (){
5. Instance = new myclassloader ();
6. Classes. Clear ();
7. }

In fact, each reset will generate a new classloader instance, which will be recycled only after all the classes loaded by this instance are recycled. Here we will release all the resets, no memory overflow problem has been found after testing.

 

Call the methods of these classes:

 

Java code  

1. Public static void invoke (string method, object [] OBJ, class <?> [] Parametertypes ){
2. Try {
3. Object CLS = myclassloader. instance. loadclass ("class full qualified name", true). newinstance ();
4. Cls. getclass (). getmethod (method, parametertypes). Invoke (CLS, OBJ );
5. } Catch (exception e ){
6. Logger. Error ("reloadable error" + method, e );
7. }
8. }

It can only be called through reflection. Due to the security mechanism of classloader, classes loaded by the parent classloader and classes loaded by the sub-classloader cannot be converted to each other.

It should be emphasized that all variables after the overloaded class is reinitialized, so some important data variables must be managed by the parent classloader.

This method has some disadvantages. The core logic is combined to separate the variables, which affects the structure of the application.

At present, this method should be used in a message service, mainly to avoid restarting the service due to some minor changes. Restarting the message service is very troublesome for large systems, it's hard to say whether it's worth it. Let's take a deeper look at java.

Http://www.iteye.com/topic/1123646

Http://www.iteye.com/topic/711162