Task execution method and system based on dynamic class loading

Abstract

The invention provides a task execution method and system based on dynamic class loading, and belongs to the technical field of computers.The task execution method comprises the steps that a basic platform class loader is created, and a connector index is constructed in the basic platform class loader; respectively creating a task class loader group, a strategy class loader group and a connector class loader group, wherein each group enables each loaded JAR packet to generate an independently isolated class loader; after the task and strategy class loader receives the class loading request, the class loading request is transmitted to the basic platform class loader according to the delegation of the parent delegation mechanism; according to a class loading request, a connector class loader corresponding to a class requested to be loaded is positioned through a connector index, and after a class object is created according to the class requested to be loaded, the class object is returned to a strategy class loader and a task class loader according to a delegation path. According to the method, the running resources of the Java virtual machine are deployed in advance, and the class loader is used for pre-allocating the resources, so that the starting time during task execution is shortened.

Description

Technical Field

[0001] This application relates to the field of computer technology, and particularly to a task execution method and system based on dynamic class loading. Background Art

[0002] In Java, a custom class loader can be used to achieve dynamic loading and unloading of JAR (Java ARchive) packages in a running Java program without restarting. However, for garbage collection (Garbage Collection, abbreviated as GC, which is a mechanism for automatically managing memory in programming languages such as Java. Its main task is to identify and recycle memory spaces that are no longer used by the program to avoid memory leaks and effectively utilize memory resources), it is necessary to ensure that there are no references to the object instances, class objects, and class loaders of the class. That is, if an update to a JAR package needs to be loaded, all related class loaders need to be destroyed together. Generally, there is a tree-like relationship among class loaders. When a class needs to load its dependent classes, the class loader first searches upward through the parent delegation mechanism, and at this time, only a class name can be obtained.

[0003] The class loader is a mechanism provided by Java. However, due to the complexity of enterprise-level applications, it will cause problems such as the inability to release memory occupation during frequent content updates and finally memory overflow. Summary of the Invention

[0004] In view of this, the purpose of the embodiments of the present invention is to provide a task execution method and system based on dynamic class loading to solve the above problems.

[0005] To achieve the above purpose, in the first aspect, the embodiments of the present invention provide a task execution method based on dynamic class loading, and the method includes the following steps: Create a basic platform class loader, and build a connector index and a reference index in the basic platform class loader; the connector index is used to store the mapping relationship between classes and connectors, and the reference index is used to retrieve the class loader that uses the classes in the connector according to the connector name Create a task class loader group, and the task class loader group generates independent and isolated task class loaders for each loaded JAR package; Create a policy class loader group, and the policy class loader group generates independent and isolated policy class loaders for each loaded JAR package; Create a connector class loader group, and the connector class loader group generates independent and isolated connector class loaders for each loaded JAR package; After the task class loader and the policy class loader receive a class loading request, they pass the class loading request to the basic platform class loader according to the parent delegation mechanism; The basic platform class loader locates, through the connector index, a connector class loader corresponding to the class to be loaded according to the class loading request; After the connector class loader creates a class object according to the class to be loaded, it returns the class object to the basic platform class loader. After the basic platform class loader establishes a corresponding reference index, it returns the class object to the policy class loader and the task class loader through the basic platform class loader.

[0006] In a second aspect, an embodiment of the present invention provides a task execution system based on dynamic class loading. The system includes: A class loader creation module, configured to create a basic platform class loader, and build a connector index and a reference index in the basic platform. The connector index is used to store the mapping relationship between classes and connectors, and the reference index is used to retrieve, according to the connector name, the class loader that uses the classes in the connector; A task loader, configured to create a task class loader group. The task class loader group generates independent and isolated task class loaders for each loaded JAR package; A policy loader, configured to create a policy class loader group. The policy class loader group generates independent and isolated policy class loaders for each loaded JAR package; A connector loader, configured to create a connector class loader group. The connector class loader group generates independent and isolated connector class loaders for each loaded JAR package; A transfer module, configured to, after the task class loader and the policy class loader receive a class loading request, pass the class loading request to the basic platform class loader according to the parent delegation mechanism; A location module, configured for the basic platform class loader to locate, through the connector index, a connector class loader corresponding to the class to be loaded according to the class loading request; A class object creation and return module, configured for the connector class loader to create a class object according to the class to be loaded and then return the class object to the basic platform class loader. After the basic platform class loader establishes a corresponding reference index, it returns the class object to the policy class loader and the task class loader.

[0007] The above technical solution has the following beneficial effects: By pre-deploying the running resources of the Java virtual machine and using class loaders for pre-allocation of resources, the present invention reduces the startup time during task execution.

[0008] The present invention sets up a connector loader to encapsulate relevant resources of the connection pool, and realizes a set of connector reloading mechanisms by constructing a connector index and a reference index. When it is necessary to update or reload a certain JAR package, the old class loader can be located through the connector index and the reference index. Since the class loader holds references to the classes it loads, destroying the class loader, including the class loader object, the class definition object, and the instances of the class, when there are no references to all three, the memory occupied by these classes can be recycled by the garbage collection mechanism of the Java virtual machine, thereby releasing memory. Then, a new class loader is used to load the updated JAR package to achieve dynamic update. This mechanism enables the system to update functional modules without restarting, improving the flexibility and availability of the system.

[0009] With the support of the dynamic routing strategy in the present invention, the work that was originally put into production at night and queued for verification can be verified in parallel during the day, improving efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the following drawings are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0011] Figure 1 is a flowchart of a task execution method based on dynamic class loading according to an embodiment of the present invention; Figure 2 is an architecture diagram of a task execution method based on dynamic class loading according to an embodiment of the present invention; Figure 3 is an implementation flowchart of a task class loader calling a connector class according to an embodiment of the present invention; Figure 4 is a flowchart of a connector reloading mechanism according to an embodiment of the present invention; Figure 5 is a functional block diagram of a task execution system based on dynamic class loading according to an embodiment of the present invention; Figure 6 is a functional block diagram of an electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0012] Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although some embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. On the contrary, these embodiments are provided to more thoroughly and completely understand the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are only for exemplary purposes and are not used to limit the protection scope of the present disclosure.

[0013] It should be understood that the various steps described in the method embodiments of the present disclosure can be executed in different orders and / or in parallel. In addition, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present disclosure is not limited in this regard.

[0014] As used herein, the term "including" and its variations are open-ended, that is, "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". The relevant definitions of other terms will be given in the following description.

[0015] It should be noted that the concepts such as "first" and "second" mentioned in the present disclosure are only used to distinguish different devices, modules or units, and are not used to limit the order or interdependence of the functions performed by these devices, modules or units.

[0016] It should be noted that the modifications of "one" and "multiple" mentioned in the present disclosure are illustrative rather than restrictive. Those skilled in the art should understand that unless otherwise clearly specified in the context, it should be understood as "one or more". Embodiment 1

[0017] Figure 1 is a flowchart of a task execution method based on dynamic class loading according to an embodiment of the present invention. As Figure 1 shown, the method includes the following steps: Step S11, create a basic platform class loader, and build a connector index and a reference index in the basic platform class loader. The connector index is used to store the mapping relationship between classes and connectors, and the reference index is used to retrieve the class loader that uses the classes in the connector according to the connector name.

[0018] Create a base platform class loader, also known as a subclass loader, from the application container class loader ("app") predefined by the JVM (Java Virtual Machine), and use it for the base platform of the custom class loading and management mechanism in this embodiment. In Java, the application class loader (also known as the system class loader) is one of the class loaders predefined by the JVM and is responsible for loading classes under the application class path (classpath); in this embodiment, a custom subclass loader, that is, the base platform class loader, is created based on the application class loader, so as to extend the function of class loading, and can implement custom class loading logic, load classes at specific locations, etc. By inheriting the application class loader, its existing functions can be reused while adding its own characteristics.

[0019] Step 12, create a task class loader group, and the task class loader group generates independent and isolated task class loaders for each loaded JAR package.

[0020] In this embodiment, the task loader creates and manages the task class loaders of the task class loader group, and the task class loader group is used to load Java classes that define the tasks or functions to be executed. These tasks or functions can be specific business logics, such as data processing, calculation tasks, etc. For example, in a data processing system, there are different task classes for operations such as data cleaning, transformation, and analysis. Similarly, independent class loaders are generated for each JAR package within the task class loader group to ensure class loading isolation between different task JAR packages.

[0021] Step S13, create a policy class loader group, and the policy class loader generates independent and isolated policy class loaders for each loaded JAR package.

[0022] In this embodiment, the policy loader creates and manages the policy class loaders of the policy class loader group, and the policy class loader group is responsible for loading Java classes that parse and execute the routing rules of tasks after a message arrives. These rules are used to determine how to route task requests to appropriate task classes. When a message arrives at the system, these classes are responsible for parsing the message and executing the corresponding routing rules to decide where the message should be routed for subsequent processing. For example, in a message queue system, messages are routed to different processing queues or services according to information such as the type and source of the message. Independent and isolated class loaders are generated for each corresponding JAR package within the policy class loader group. This indicates that the class loading environments in each JAR package are independent of each other, and the same-named classes in different JAR packages will not interfere with each other. This isolation is beneficial to avoiding class conflicts and can implement gray release with dynamically callable routing policies.

[0023] Specifically, gray release is a software release strategy, also known as canary release. It allows new features or new versions of code to be gradually introduced into the production environment. First, the new features or new versions of code are released to a small number of users or traffic for testing, observing their running conditions and performance. If everything is normal, the scope is gradually expanded until all users or traffic are covered. This can reduce the risks brought by new features or new versions and promptly discover and solve potential problems.

[0024] The routing strategy for dynamic calls is one of the technical means to achieve gray release. In the system, when various types of requests (such as remote procedure calls RPC, Restful API requests, message queue consumption, etc.) arrive at the platform, the system needs to determine which specific service instance or execution logic to route these requests to according to certain rules. This rule is the routing strategy, and it is dynamic and can be adjusted according to different conditions and requirements.

[0025] After the request arrives at the platform, the system will analyze the call parameters of the request. These parameters can contain various information, such as user ID, request time, request source, business type, etc. According to these parameters, the system will execute the corresponding policy routing. For example: Route by user ID. For the gray release of some new features, it can be selected to route the requests of a part of user IDs to the new service instance or execution logic, while the requests of other user IDs are still routed to the old service instance or execution logic. For example, select users with user IDs ending in even numbers as gray users and route their requests to the new version of the service. It is possible to route according to the request time. For example, within a certain time period (such as a specific time period every day), route all requests to the new service instance for testing. Route according to the request source (such as different client types, different network environments, etc.). For example, only route requests from a specific client version to the new service. During the process of policy routing, specific traffic requests can be specially processed through coding. Specifically, for requests that meet specific conditions, let them execute the business logic (functions) in a specific task class. For example, developers will define multiple task classes, and each task class contains different business logics. For example, there is an old version task class OldTask and a new version task class NewTask, and they both implement the same interface or inherit the same parent class. In the code of the routing strategy, conditional judgments will be made according to the call parameters of the request. If the request meets specific conditions, the business logic in the new version task class NewTask will be called; if it does not meet the conditions, the business logic in the old version task class OldTask will be called.

[0026] In this embodiment, through a dynamically called routing policy, combined with request parameters for policy routing, and by encoding to process specific traffic requests, gray release can be achieved, enabling the gradual promotion of new functions or new versions within a controllable range.

[0027] Step S14: Create a connector class loader group, and the connector class loader group generates independent and isolated connector class loaders for each loaded JAR package.

[0028] In this embodiment, the connector class loaders of the connector class loader group are created and managed by the connector loader. The connector class loader group is used to load Java classes related to connection pools for calling third-party middleware (such as databases, caches, third-party interfaces, etc.) during task and policy execution. The connection pool is used to manage connections with third-party middleware, improving the performance and resource utilization rate of the system. For example, when using JDBC (Java Database Connectivity) to connect to a database, the connection pool can reuse database connections, reducing the overhead of frequently creating and destroying connections. The connector class loader group generates independent class loaders for each JAR package containing a connection pool implementation, ensuring isolation between different third-party middleware connection pools and avoiding mutual influence.

[0029] In this embodiment, different connection pool classes loaded by the connector class loader group can independently manage connections with third-party middleware, avoiding resource competition between different tasks or policies. When the task class loader group and the policy class loader group use these connection pools, they will not affect each other, ensuring the concurrent performance and resource utilization rate of the system.

[0030] Step S15: When the task class loader and the policy class loader receive a class loading request, they pass the class loading request to the basic platform class loader according to the parent delegation mechanism.

[0031] Specifically, the parent delegation mechanism is the core rule of Java class loading. When a class loader receives a class loading request, it first does not attempt to load the class itself, but delegates the request to its parent class loader. This process is passed up continuously until the top-level bootstrap class loader is reached. Then, starting from the bootstrap class loader, each class loader attempts to load the class in turn. If any parent class loader fails to load the class, the request is returned to the child class loader, and the child class loader continues to attempt until the class is successfully loaded or all class loaders have attempted and failed.

[0032] Step S16: The basic platform class loader locates the connector class loader corresponding to the class to be loaded according to the class loading request through the connector index.

[0033] When the parent delegation mechanism enters the class loading method of the basic platform class loader, the basic platform class loader will first detect whether the class is included in the connector index. The connector index is a data structure that records the mapping relationship between classes and connectors, that is, which classes belong to which connector. If the class is included in the connector index, it means that this class is related to a certain connector. The basic platform class loader will find the corresponding connector class loader through the connector loader. The connector class loader is a class loader that is specifically responsible for loading classes related to a specific connector. After finding the corresponding connector class loader, the connector class loader will perform the class loading operation. If it is the first time to load this class, the connector class loader will create an object of this class and cache it in its own internal. After that, if the same class is requested to be loaded again, the connector class loader will directly read the object of this class from the cache without having to recreate it.

[0034] Step S17, after the connector class loader creates a class object according to the class requested to be loaded, it returns the class object to the basic platform class loader. After the basic platform class loader establishes the corresponding reference index, it returns the class object to the policy class loader and the task class loader.

[0035] As an example, assume that a task class needs to load a class named com.example.DBConnector. After passing through a series of class loaders, the class loading request reaches the base platform class loader. The base platform class loader checks the connector index and finds that the com.example.DBConnector class is in the connector index, indicating that this class is related to the database connector. Through the connector loader, the base platform class loader finds the connector class loader responsible for loading classes related to the database connector. If it is the first time to load the com.example.DBConnector class, the connector class loader will create an object of this class and cache it; if it is not the first time to load, the class object will be directly read from the cache. The connector class loader returns the com.example.DBConnector class object to the task class loader along the delegation path, and the task class can use this class object to perform database connection operations. In this embodiment, for classes related to the connector, they are loaded and cached by a dedicated connector class loader, avoiding repeated loading and improving the efficiency of class loading. Different connector class loaders can independently manage their own class loading and caching, achieving isolation between different connector-related classes and avoiding class conflicts. Through the connector index, it is possible to flexibly control which classes are loaded by the connector class loader and which classes continue to follow the traditional parent delegation mechanism, improving the flexibility and manageability of class loading. In addition, after receiving the class object returned by the connector class loader, the base platform class loader will establish a corresponding reference index so that when reloading the JAR package later, it can quickly locate the policy class loader and the task class loader.

[0036] In the embodiment of the present invention, a policy class loader group (used to write routing rules for tasks parsed and executed after a Java class execution message arrives), a task class loader group (used to define tasks or functions to be executed), and a connector class loader group (used to provide a connection pool for a third-party middleware such as a database, cache, third-party interface, etc. when tasks and policies are executed) are defined. The functions of the three class loader groups are different, and their internal management is carried out through their respective managers (for example, policy loader, task loader, and connector loader). Under each group, an independent and isolated class loader will be generated for the JAR package to be loaded, so that when reloading the JAR package, the old class loader can be destroyed to release memory. Since each class loader group generates an independent class loader for the JAR package to be loaded, these class loaders are isolated from each other. The same-named classes loaded by different class loaders will be regarded as different classes, which can avoid class conflicts between different JAR packages. For example, if an old version of a certain third-party library is used in one JAR package and a new version of this library is used in another JAR package, independent class loaders can ensure that they each use their own version of the library without version conflict problems.

[0037] The JAR package of the connector contains definitions of various classes. When the JAR package is loaded, the definitions of these classes are converted into class objects, and many class object instances are created based on these classes to complete specific business functions. When the JAR package is reloaded, the old class objects and class object instances are no longer needed because there is a new version of the same class in the new JAR package, or the structure and functions have changed. If these old objects are not released, they will continuously occupy memory, leading to memory leaks, and ultimately exhausting system resources and affecting the normal operation of the program. The class loader is responsible for loading the bytecode of the class into the JVM and creating the corresponding class object. When the JAR package of the connector is reloaded, the connector class loader object originally used to load this JAR package is no longer needed. Because the new JAR package needs to be loaded by a new class loader to ensure that the latest class definitions are loaded. Moreover, the old connector class loader object holds references to the old class objects and other related resources. If not released, these resources cannot be recycled. That is, if other policy class loaders, task class loaders, or their instances reference the classes created by the connector (i.e., the classes in the JAR package), when the JAR package of the connector is reloaded, these references also need to be processed. Because these references will cause the old class objects and related resources to not be recycled by the garbage collector. Even if the classes in the JAR package of the connector are updated, these old references still point to the old class objects, resulting in inconsistent states or errors. Therefore, to solve this problem and ensure the correct release of memory and the normal operation of the system, this embodiment proposes the concept of a connector to encapsulate the related resources of the connection pool, and through constructing a connector index and a reference index, a set of mechanisms for reloading the connector is implemented; the policy, task class loaders, and their instances that reference the classes created by the connector need to be processed accordingly, releasing the memory space they occupy, or updating their references to point to the new class objects. For example, when a certain JAR package needs to be updated or reloaded, the old class loader that can be destroyed can be located through the connector index and the reference index. Since the class loader holds references to the classes it loads, destroying the class loader, which includes the class loader object, the class definition object, and the instances of the class, when there are no references to all three, the memory occupied by these classes can be recycled by the garbage collection mechanism of the Java virtual machine, thereby releasing memory. Then, the updated JAR package is loaded using a new class loader to achieve dynamic update. This mechanism enables the system to update functional modules without restarting, improving the flexibility and usability of the system.

[0038] In some embodiments, the basic platform class loader locates the connector class loader corresponding to the class to be loaded through the connector index according to the class loading request. Specifically, when the basic platform class loader receives a class loading request, it checks the connector index, finds the connector class loader corresponding to the class to be loaded according to the connector index, and instructs the corresponding connector class loader to create a class object according to the class to be loaded. If the corresponding class loader is not found in the connector index, it is delegated to the parent class loader according to the parent delegation mechanism, and the parent class loader creates a class object according to the class loading request.

[0039] Specifically, when the class request received by the basic platform class loader is to establish a connection with a third-party middleware, the basic platform class loader checks the connector index, finds the connector class loader corresponding to the class to be loaded according to the connector index, and instructs the corresponding connector class loader to create a class object according to the class to be loaded.

[0040] If the class is not included in the connector index, the basic platform class loader will continue to delegate the class loading request upward to its parent class loader according to the traditional parent delegation mechanism until a suitable class loader is found or all class loaders have tried and failed.

[0041] In this embodiment, the hash dictionary index forest is a data structure composed of multiple hash dictionaries, similar to a collection of multiple hash tables. Each hash table can store data according to different rules or classifications. The connector index uses the data structure of the Java hash dictionary index forest to retrieve connectors according to class names. It records the connector to which each class belongs, facilitating quick location of the corresponding connector during class loading.

[0042] In some embodiments, the reference index uses the connector name as the key and the set of policy class loaders and task class loaders that use the classes in the connector as the value, and is used to retrieve the policy class loaders and task class loaders that use the classes in the connector according to the connector name during JAR package reloading.

[0043] In this way, the basic platform class loader can quickly determine the relevant set of class loaders with the help of the reference index, uniformly process class loading requests, avoid repeated searching and loading operations, and improve the efficiency of class loading.

[0044] In this embodiment, the reference index records a set of policy class loaders and task class loaders that use classes in a specific connector. The basic platform class loader can quickly determine the relevant class loader set with the help of the reference index, uniformly process class loading requests, and avoid duplicate operations. When a class loader loads a class related to a specific connector, the class loader needs to be recorded under the corresponding connector name in the reference index. In this way, the reference index can reflect in real time which class loaders use the classes of which connectors. When the basic platform class loader receives a class loading request, it first checks the connector index to determine whether the class to be loaded belongs to a certain connector. If it belongs to a certain connector, the class loader set that uses this connector can be obtained from the reference index through the connector name. After obtaining the relevant class loader set, the basic platform class loader can uniformly process the requests of these class loaders. For example, only one class loader is allowed to load the class, and then the loading result is shared with other class loaders, avoiding duplicate search and loading operations for each class loader.

[0045] In this embodiment, by creating a subclass loader from the application class loader as the basic platform and using two indexing mechanisms, namely the reference index and the connector index, the relationship between class loading and connectors can be better managed. The reference index can track which class loaders use the classes of a specific connector, and the connector index can quickly find the corresponding connector according to the class name, thereby improving the maintainability and performance of the system.

[0046] In some embodiments, as Figure 4 shown, the method further includes: when reloading the JAR package, the connector loader creates a new connector class loader to load the new JAR package and sends a creation notice to the basic platform class loader.

[0047] In software development, especially in some highly dynamic systems, there will be a need to reload the JAR package of the connector. For example, when the function of the connector needs to be updated, a vulnerability needs to be fixed, or it needs to adapt to new environmental changes, its corresponding JAR package will be reloaded to achieve functional upgrades or adjustments. In this embodiment, when the JAR package related to the connector needs to be updated or reloaded, the original connector class loader is not directly reused, but a new connector class loader is created. Because the class loader caches the class when loading the class, if the old class loader is reused, the class in the new JAR package cannot be correctly loaded, resulting in the program still using the old version of the class. Creating a new connector class loader can ensure that the latest class definition is loaded from the new JAR package. When the JAR package of the connector is reloaded or updated, the system needs a way to inform other related components so that they can make corresponding adjustments. The method adopted in this embodiment is to send a notification to the basic platform class loader. The basic platform class loader is usually in a relatively core position in the entire class loading system. It can serve as a JAR "hub" to pass the information of the connector reload to other parts that need to know.

[0048] After receiving the creation notification, the basic platform class loader re-merges the connector index to establish a new mapping relationship between the class and the connector, and traverses the reference index according to the connector name to find all policy class loaders and task class loaders that use the connector-related classes.

[0049] When the new connector class loader loads the new JAR package, the mapping relationship between the class and the connector changes. The basic platform class loader needs to re-merge the connector index to update these mapping relationships to ensure that the connector to which the class belongs can be accurately found in the subsequent class loading process.

[0050] Specifically, during the loading process of the new connector JAR package, the base platform class loader will record the connector to which each newly loaded class belongs. For example, for a newly loaded database driver class, record the database connector to which it belongs. Add the mapping relationship between the new class and the connector to the connector index. If the class name already exists in the index, but the corresponding connector has changed, update the mapping relationship. If some classes no longer exist in the new JAR package, or the connector to which they belong has changed, the old mapping relationship needs to be removed from the connector index.

[0051] After the basic platform class loader updates the connector index, it will trigger a reference index to quickly locate which class loaders are related to the reloaded connector. For example, there are multiple different class loaders that rely on certain functions or classes provided by this connector when loading their respective classes. Then these class loaders will be recorded in this set. After obtaining the set of class loaders that reference this connector, the system will traverse this set. For each element in the set, that is, each class loader, perform the operation of reconstructing and loading. That is, these class loaders in the set need to be re-initialized and configured so that they can correctly load the classes related to the reloaded connector. For example, re-read the class definitions in the connector JAR package, re-establish the association relationships between classes, re-allocate memory space, etc., to ensure that these class loaders can use the latest version of the connector, so as to ensure that the functions of the entire system can run normally and can adapt to the changes brought about by the connector reload.

[0052] The task loader reconstructs the task class loader that uses the classes related to the connector to load the classes related to the connector; the policy loader reconstructs the policy class loader that uses the classes related to the connector to load the classes related to the connector.

[0053] Since the JAR package of the connector has been reloaded and the classes in it have changed. To ensure that the task classes and policy classes can use the latest connector classes, the policy / task loader needs to reload the relevant classes. This can ensure that the execution of tasks and policies is compatible with the new connector version and avoid errors caused by inconsistent class versions.

[0054] Suppose there are multiple tasks and policies in a system, and they all rely on a database connector. When the JAR package of the database connector needs to be updated, a new connector class loader will be created to load the new JAR package. The basic platform class loader will re-merge the connector index forest and update the mapping relationship between classes and connectors. Then, by looking up the reference index, it is found which task class loaders and policy class loaders use this database connector. Finally, these task class loaders and policy class loaders will reload the relevant classes to adapt to the new database connector version.

[0055] Specifically, when the JAR package of the connector starts to be reloaded, it will trigger the basic platform class loader to update the reference index and the connector index. The basic platform class loader will first traverse the reference index and the connector index and remove all records related to the old connector. This can be achieved by searching for records with the old connector name as the key and deleting them, as well as deleting all class name mapping records pointing to the old connector. The basic platform class loader loads the new connector JAR package through the new connector class loader. During the loading process, the new class loading information will be recorded. After the loading is completed, the basic platform class loader will update the reference index and the connector index according to the new class loading situation. Add the new reference relationships and the mapping relationships between classes and connectors to the corresponding indexes.

[0056] By releasing these related objects in the embodiments of the present invention, memory can be effectively reclaimed, memory leaks and potential program errors can be avoided, so that the system can run in a clean and stable state after the JAR package of the connector is reloaded, and use the classes and functions in the new JAR package to complete the corresponding tasks.

[0057] In some embodiments, the method may further include: After the policy class loader and the task class loader obtain the class object, obtain the class loader name that created the class object from the class object, and determine whether the class object is created by the connector class loader according to the class loader name; If the class object is created by the connector class loader, the task class loader and the policy class loader register the reference index of this class with the basic platform class loader, and record the relevant information of the loaded class in the reference index of the basic platform class loader.

[0058] Specifically, when the policy class loader and the task class loader receive the class object passed back by the parent class loader, they can obtain the name of the class loader that created this class object in a certain way (such as the relevant methods or attributes of the class object). Based on the class loader name, determine the source of the class. If it is found that the class is created by the connector class loader, it means that this class is related to a certain connector. The connector class loader is usually responsible for loading classes related to connections with external resources (such as databases, message queues, etc.). If it is determined that the class is created by the connector class loader, the task class loader and the policy class loader need to register the reference index of this class with the basic platform class loader, that is, the task class loader or the policy class loader records the relevant information of the classes they load into the reference index of the basic platform class loader. Through this registration operation, the basic platform class loader can clearly understand which class loader loaded each class and information such as the dependency relationships between these classes. When the connector changes (such as reloading a JAR package), the basic platform class loader can quickly locate the affected classes and the corresponding class loaders according to the reference index, and then take corresponding handling measures, such as reloading the relevant classes, to ensure the normal operation of the system.

[0059] As Figure 2 shown, in some embodiments, the method further includes: setting a common task class loader between the basic platform class loader and the task class loader for uniformly managing and loading classes in the common JAR packages.

[0060] In this embodiment, task classes depend on some common JAR packages. To avoid each task class loader from repeatedly loading the classes in these common JAR packages, a common task class loader is added between the basic platform class loader and the task class loader. However, the common task class loader itself does not create any classes. It is just an index of the relationship between JAR packages and classes, maintaining a mapping (map) with the class name as the key and the URL path of the class in the JAR package as the value, and following hierarchical overlay (that is, the newly introduced class mapping will overwrite the old one). It knows which classes exist in which JAR packages. For classes in the JAR packages involved by the task class loader (including the common part), the common task class loader will project these classes to the class loader of a single task that initiates the parent delegation source for creation. In this way, each task has its own independent class instance, and even if these classes come from common JAR packages, isolation between tasks can be achieved to avoid interference with each other.

[0061] For classes in non-task JAR packages, that is, those classes that do not fall within the jurisdiction of the task class loader, the common task class loader follows the parent delegation mechanism and passes the class loading request up to the parent class loader to complete the creation of the class. This can ensure that the loading of Java core classes and other non-task-related classes follows the standard Java class loading process, ensuring the stability and security of the system.

[0062] In this embodiment, isolation is achieved by setting the common task class loader to project classes in the JAR packages of the task class loader (including the common one) into the class loader of a single task for creation; for classes in non-task JAR packages, class creation is achieved by upward parent delegation. This can centrally manage the loading of common classes and improve resource utilization efficiency.

[0063] In some embodiments, the classes in the common JAR packages are uniformly managed and loaded, specifically including: When the task class loader receives a class loading request, it forwards the class loading request to the common task class loader.

[0064] Specifically, when the task class loader receives a class loading request, it first forwards the request to the common task class loader. This is because the common task class loader is responsible for managing the common resources involved in the task class loader, including the class tasks in the common JAR packages. After receiving the class loading request, the common task class loader determines whether the requested class is from a task JAR package or a non-task JAR package through the index of the JAR package and class relationship it maintains.

[0065] If the requested class belongs to a task JAR package, the common task class loader projects the class loading request into the corresponding single-task class loader.

[0066] In this embodiment, when a certain task needs to load a class, the task class loader will first ask the common task class loader. The common task class loader determines whether this class belongs to the JAR packages involved in the task class loader (including the common part) according to the index it maintains. If so, the common task class loader will "project" the class loading request of this class into the task class loader corresponding to this task, and let this task class loader actually create an instance of this class. This projection operation ensures that each task has its own independent class loading environment. Even if multiple tasks use classes in the same common JAR package, the classes loaded by the class loaders of each task are isolated from each other, and different tasks will not affect each other.

[0067] For example, assume there are two tasks: Task A and Task B, both of which depend on the common common.jar and their respective specific taskA.jar and taskB.jar. When Task A needs to load the com.example.CommonClass class in common.jar: The class loader of Task A asks the common task class loader. The common task class loader knows from the index that com.example.CommonClass belongs to the common JAR package and is related to Task A. The common task class loader "projects" the class loading request for this class to the class loader of Task A. The class loader of Task A is responsible for loading and creating an instance of com.example.CommonClass. Similarly, when Task B needs to load the com.example.CommonClass class, another independent instance of this class will be created through the class loader of Task B, isolated from the instance in Task A.

[0068] The embodiments of the present invention can isolate the class loading between different tasks, avoid class conflicts and interference, and improve the stability and maintainability of the system. The classes in the common JAR package do not need to be repeatedly loaded in each task class loader, saving memory and system resources.

[0069] If the class requested to be loaded belongs to a non-task JAR package, the common task class loader passes the class loading request upward to the basic platform class loader through the parent delegation mechanism.

[0070] In this embodiment, when the task class loader encounters a class in a non-task JAR package, it needs to pass the loading request upward. The common task class loader is an intermediate node in this transfer process. It will continue to hand the request upward to its parent class loader according to the parent delegation mechanism, ensuring that the class loading process follows the established hierarchical structure.

[0071] Setting up the common task class loader in this embodiment is beneficial to maintaining the consistency of the entire system class loading. As an intermediate layer, it standardizes the transfer path of the class loading request, so that no matter which task class loader initiates the loading request for a class in a non-task JAR package, it will go through a unified process and path, avoiding chaos in class loading.

[0072] In this embodiment, the common task class loader can clearly distinguish which classes belong to the task JAR packages and which classes belong to non-task JAR packages. When encountering classes in non-task JAR packages, it can accurately direct the loading request to the parent delegation process; for classes in task JAR packages, it will project the classes into a single-task class loader for creation in the manner mentioned above. This discrimination ability enables the system to adopt different loading strategies according to the different sources of classes. The common task class loader can perform preliminary screening and processing on class loading requests. Before passing the loading request of non-task JAR package classes upward, it can perform some necessary checks or caching operations to improve the efficiency of class loading. For example, it can check whether the same non-task class has been loaded by other task class loaders. If so, relevant information can be directly reused to avoid repeated searching and loading processes.

[0073] In the scenario of dynamically loading and updating JAR packages, the common task class loader can better manage class loading changes. When a new non-task JAR package is added or an existing non-task JAR package is updated in the system, the common task class loader can promptly detect these changes and correctly load the new classes or updated classes during the parent delegation process. It can serve as a unified management node to coordinate the loading and use of non-task JAR package classes by different task class loaders.

[0074] Through the design of this embodiment of the present invention, the isolation between task classes is achieved, the classes in the common JAR packages are effectively shared, and the correct loading of non-task classes is ensured at the same time. The characteristics of the Java class loading mechanism are fully utilized, improving the flexibility and maintainability of the system.

[0075] In some embodiments, the method may further include: the task loader generates a corresponding task class loader for each task for class recycling scheduling, allowing each task to run in its own independent class loading environment.

[0076] Specifically, Java uses the parent delegation mechanism to load classes. Under this mechanism, class loaders form a tree structure, and each class loader has a parent class loader. When a class loader receives a class loading request, it first delegates the request to its parent class loader and tries to load the class layer by layer from the topmost bootstrap class loader. If the parent class loader fails to load, the current class loader will then try to load it by itself.

[0077] In Java, the uniqueness of a class is jointly determined by the fully qualified name of the class (the class name including the package name) and the class loader that loads it. That is to say, even if the fully qualified names of two classes are the same, but if they are loaded by different class loaders, then the Java Virtual Machine (JVM) will regard them as different classes. This is because different class loaders have their own independent naming spaces, and the classes in each naming space are isolated from each other.

[0078] In this embodiment, the task class loader generates a child class loader for each task, so that the classes of each task will be loaded in their own independent class loader naming spaces. The class loaders of different tasks are independent of each other, and the classes they load will not affect each other. For example, suppose there are two tasks, and each task has a class named com.example.MyClass. Since each task has its own independent child class loader, these two com.example.MyClass classes will be loaded by different class loaders respectively. Although the class names are the same, because the class loaders that load them are different, the JVM will regard them as different classes.

[0079] Since different tasks depend on different versions of the same library. In this embodiment, by using different class loaders to load these tasks, each task can use the version of the library it needs, avoiding the version conflict problem. For example, task A depends on library-1.0.jar, and task B depends on library-2.0.jar. Using different class loaders can ensure that each task uses its own library version. Moreover, each task has its own class loader. When the task ends, the class loader corresponding to the task can be destroyed. Since the class loader holds a reference to the classes it loads, after destroying the class loader, the memory occupied by these classes can be recycled by the garbage collection mechanism of the JVM, realizing the recycling and scheduling of classes and improving the memory usage efficiency.

[0080] In some embodiments, the method may further include: if all parent class loaders are unable to load the requested class, the class loading request will be returned to the branch connector class loader, and the branch connector class loader will search for the requested class in the responsible class path.

[0081] In this embodiment, a branch means that the connector class loader is not on the path of the parent delegation relative to the policy class loader and the task class loader. And the behavior of these class loaders can only follow the parent delegation, so the branch is invisible to them. At this time, the basic platform class loader is needed as an intermediary to transfer the loaded connector class object and wrap it, so that from the perspective of the policy class loader or the task class loader, it is regarded as a class loaded by the basic platform class loader.

[0082] To enable those skilled in the art to better understand the technical solutions provided by the embodiments of this application, the following provides a detailed description of a task execution method based on dynamic class loading provided by the embodiments of this application. Attached Figure 3 is the implementation process of the task class loader of the embodiment of the present invention calling the connector class, as Figure 3 shown, which includes the following steps: S1, class loading method: The task class loader delegates the class to be loaded to the common task class loader through the parent delegation mechanism; S2, class loading method: The common task class loader retrieves whether the class to be loaded is in the dictionary of common classes (task JAR). If so, it projects it into the task class loader of the class to be loaded and calls the class creation method; if not, it delegates the class to be loaded to the basic platform class loader through the parent delegation mechanism; S3, class loading method: The basic platform class loader checks whether the class to be loaded is in the connector index. If so, it locates the specified connector class loader through the connector loader and executes S4; if not, it delegates the class to be loaded to the JVM class loader (i.e., the parent class loader) through the parent delegation mechanism to execute S5; S4, class loading method: After the connector class loader calls the class creation method, it returns the class object to the task class loader along the original path and executes S6; S5, class loading method: The JVM class loader fails to find the class, returns to the original leaf node class, and then loads it in this task class loader; S6, The task class loader registers the reference index of this class with the basic platform class loader.

[0083] In this embodiment, in the runtime environment where the task class loader calls the connector, the connector group is managed by the unified environment class in the mode of static class and singleton storage, that is, any class in the entire mechanism can call the three managers: the connector loader, the policy loader, and the task loader, so as to achieve the penetration of the entire system. The connector dependency is introduced during task development, but the connector-related classes will not be packaged during release and packaging.

[0084] A static class in Java refers to a class that contains static members (static variables, static methods). The main feature of a static class is that its members can be directly accessed without creating an instance of the class. Here, a static class is used to manage the connector group, which indicates that the relevant management methods and data can be conveniently called throughout the application without creating a new management class instance at each place where the connector needs to be used, thus improving the convenience and unity of the code.

[0085] Singleton storage means that the singleton pattern ensures that a class has only one instance and provides a global access point. By managing the connector group through the singleton storage pattern, it can be guaranteed that there is only one unified connector group management instance throughout the application lifecycle. This avoids inconsistent operations on the connector group by multiple instances and ensures the consistency and stability of the connector group status. For example, in a multi-threaded environment, without the singleton pattern, different threads create different connector group management instances, resulting in chaos in the use and management of connectors. The singleton pattern can ensure that all threads access the same connector group management instance, thus achieving unified management of connectors.

[0086] During the development stage, tasks need to rely on connectors to interact with third-party middleware (such as databases, caches, third-party interfaces, etc.). Developers introduce the dependency of the connector in the project, enabling the development environment to find and use the classes and functions related to the connector. In this way, developers can call the methods of the connector during development and write business logic for interacting with third-party middleware. For example, when developing a database operation task, by introducing the dependency of the database connector, the API provided by the connector can be used for database connection, query, insertion, etc.

[0087] During the release and packaging stage, the classes related to the connector are not packaged into the final release package. This is because connectors are usually related to specific operating environments, and different operating environments require different versions of connectors. If the classes related to the connector are packaged, compatibility issues will occur in different environments. Moreover, the connector class library is often relatively large, and not packaging it can reduce the volume of the release package and improve the deployment efficiency. At runtime, the connector group is managed through the unified environment class mentioned above, and the classes related to the connector are dynamically loaded in the operating environment. For example, when deploying multiple applications on a cloud platform, each application requires a different version of the database connector. Through dynamic loading, the appropriate connector version can be loaded according to the actual needs of each application, without the need to include all connector versions in the release package.

[0088] Under normal mechanisms, Java class loading first delegates to the parent class loader. When an exception occurs that the parent class loader cannot find the class, the class is then loaded by the current class loader. Therefore, generally only for the class loaders on one chain, the class loader at the leaf node can load all classes. Because the class loader at the leaf node is at the end of the class loader chain, it can not only load classes within its own scope, but also, through the parent delegation mechanism, let its parent class loader attempt to load classes in other scopes. Therefore, the class loader at the leaf node can cover the loading scopes of all class loaders and thus can load all classes; while in the embodiments of the present invention, there is a branch chain connector class loader. To enable the final invoker policy and task class loader to load classes created by the connector class loader, it is necessary to return it in the basic platform class loader.

[0089] For the task common class loader, it does not directly create classes itself. It only caches the common class names and the binary data of classes. When a class needs to be loaded, it projects them to the task class loader that requests to load the class to complete the creation. Therefore, for the JAR packages in the task common class loader, the classes it contains will create copies in multiple task class loaders.

[0090] When the parent delegation mechanism enters the class loading method of the basic platform class loader, it will first detect whether the class is included in the connector index. If the class is not included, it will continue to perform parent delegation upward; if the class is included in the connector index, it will find the corresponding connector class loader through the connector loader, create or read the class object in the cache (the class object is cached in the connector class loader after the first creation) in it, and return it back to the task class loader along the delegation path. Embodiment 2

[0091] As Figure 5 shown, the embodiments of the present invention further provide a task execution system based on dynamic class loading. The system includes: A basic platform class loader creation module, used to create a basic platform class loader and construct a connector index and a reference index in the basic platform class loader. The connector index is used to store the mapping relationship between classes and connectors, and the reference index is used to retrieve the class loaders that use the classes in the connectors according to the connector names; A task loader, used to create a task class loader group. The task class loader group generates independent and isolated task class loaders for each loaded JAR package; A policy loader, used to create a policy class loader group. The policy class loader group generates independent and isolated policy class loaders for each loaded JAR package; A connector loader, used to create a connector class loader group. The connector class loader group generates independent and isolated connector class loaders for each loaded JAR package; A transfer module, configured to, after the task class loader and the policy class loader receive a class loading request, transfer the class loading request to the basic platform class loader according to the parent delegation mechanism; A location module, configured to enable the basic platform class loader to locate, through a connector index, a connector class loader corresponding to the class to be loaded according to the class loading request; A class object creation and return module, configured to enable the connector class loader to create a class object according to the class to be loaded and then return the class object to the basic platform class loader, and the basic platform class loader establishes a reference index and then returns the class object to the policy class loader and the task class loader.

[0092] In some embodiments, the location module is specifically configured to: When the class request received by the basic platform class loader is to establish a connection with a third-party middleware, the basic platform class loader checks the connector index, finds a connector class loader corresponding to the class to be loaded according to the connector index, and instructs the corresponding connector class loader to create a class object according to the class to be loaded.

[0093] In some embodiments, the platform further includes: the location module is specifically configured to retrieve, according to the connector name, the policy class loader and the task class loader that use the classes in the connector when reloading the JAR package.

[0094] In some embodiments, the platform further includes: a common task class loader, arranged between the basic platform class loader and the task class loader, configured to uniformly manage and load the classes in the common JAR package. The common task class loader is specifically configured to: When the task class loader receives a class loading request, forward the class loading request to the common task class loader; After the common task class loader receives the class loading request, determine whether the class to be loaded comes from a task JAR package or a non-task JAR package; If the class to be loaded belongs to a task JAR package, the common task class loader projects the class loading request into the class loader of the corresponding single task; If the class to be loaded belongs to a non-task JAR package, the common task class loader transfers the class loading request upward to the basic platform class loader through the parent delegation mechanism.

[0095] In some embodiments, the platform further includes: a reload and update module, including: When updating a JAR package related to a connector, the connector loader creates a new connector class loader to load the updated JAR package, and sends a creation notice to the basic platform class loader; After the basic platform class loader receives the creation notice, it recombines the connector index to establish a new mapping relationship between classes and connectors, and traverses the reference index according to the changed connector name to find all policy class loaders and task class loaders that use the connector; The task loader reconstructs the task class loaders of classes related to the use of the connector to load classes related to the connector; The policy loader reconstructs the policy class loaders of classes related to the use of the connector to load classes related to the connector.

[0096] In some embodiments, the platform further includes: a registration module, configured to, after the policy class loader and the task class loader obtain class objects, obtain the class loader name for creating the class objects from the class objects, and determine whether the class objects are created by the connector class loader according to the class loader name; If the class objects are created by the connector class loader, the task class loader and the policy class loader register the reference index of their own classes with the basic platform class loader, and record the relevant information of the loaded classes in the reference index of the basic platform class loader.

[0097] In some embodiments, the platform further includes: a recycling scheduling sub-module, configured to generate a corresponding task class loader for each task by the task loader for class recycling scheduling, so that each task runs in its own independent class loading environment.

[0098] In some embodiments, the platform further includes: a branched-chain connector class loader. If all parent class loaders are unable to load the requested class, the class loading request will be returned to the branched-chain connector class loader, and the branched-chain connector class loader will search for the requested class in the responsible class path.

[0099] For specific details, please refer to the method embodiments.

[0100] By adding a loading / unloading mechanism for connectors in the embodiments of the present invention, the coupling between tasks (business logics), connectors (third-party calls), and routing policies is eliminated, and they can be dynamically published and combined, thereby reducing the complexity of function development and shortening the iteration cycle of the production environment.

[0101] At the same time, the dynamic gray-scale policy allows gray-scale verification of dozens of versions simultaneously in the production environment, solving the time-consuming problem that traditional version releases require queuing for verification one by one for different requirements.

[0102] Refer to Figure 6 , which shows a schematic structural diagram of a computer system 600 of an electronic device suitable for implementing the embodiments of the present invention. As Figure 6As shown, the computer system 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage section 608 into a random access memory (RAM) 603. In the RAM 603, various programs and data required for the operation of the computer system 600 are also stored. The CPU 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604. The CPU 601 is used to implement a task execution method based on dynamic class loading provided by the present invention.

[0103] The following components are connected to the I / O interface 605: an input section 606 including a keyboard, a mouse, etc.; an output section 607 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc. and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, a modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I / O interface 605 as required. A removable medium 611, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 610 as required so that a computer program read from it is installed into the storage section 608 as required.

[0104] The above specific embodiments do not constitute a limitation on the protection scope of the present invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention shall be included within the protection scope of the present invention.

Claims

1. A task execution method based on dynamic class loading, characterized in that: The method comprises the following steps: Create a basic platform class loader, and construct a connector index and a reference index in the basic platform class loader, wherein the connector index is used to store the mapping relationship between the class and the connector, and the reference index is used to retrieve the class loader that uses the class in the connector according to the connector name; Creating a task class loader group, wherein the task class loader group generates an independent and isolated task class loader for each loaded JAR package; Creating a policy class loader group, wherein the policy class loader group generates an independent and isolated policy class loader for each loaded JAR package; Creating a connector class loader group, wherein the connector class loader group generates an independent and isolated connector class loader for each loaded JAR package; When the task class loader and the policy class loader receive the class loading request, they pass the class loading request to the basic platform class loader according to the parent delegation mechanism; The basic platform class loader locates the connector class loader corresponding to the class requested to be loaded through the connector index according to the class loading request; The connector class loader creates a class object according to the class requested to be loaded and returns the class object to the basic platform class loader. The basic platform class loader establishes a corresponding reference index and then returns the class object to the policy class loader and the task class loader.

2. The method according to claim 1, characterized in that: The basic platform class loader locates the connector class loader corresponding to the class requested to be loaded through the connector index according to the class loading request, specifically including: When the basic platform class loader receives a class loading request, the basic platform class loader checks the connector index, finds the connector class loader corresponding to the class requested to be loaded according to the connector index, and instructs the corresponding connector class loader to create a class object according to the class requested to be loaded; If the corresponding connector class loader is not found in the connector index, the basic platform class loader delegates the class loading request to the parent class loader according to the parent delegation mechanism, and the parent class loader creates a class object according to the class loading request.

3. The method according to claim 2, characterized in that: The reference index uses the connector name as the key and the set of policy class loaders and task class loaders that use the classes in the connector as the value, and is used to retrieve all policy class loaders and task class loaders that use the classes in the connector according to the connector name when reloading the JAR package.

4. The method according to claim 3, characterized in that The method further comprises: When reloading the JAR package, a new connector class loader is created to load the new JAR package, and a creation notification is sent to the basic platform class loader; After receiving the creation notification, the basic platform class loader re-merges the connector index to establish a new mapping relationship between the class and the connector, and traverses the reference index according to the connector name to find all policy class loaders and task class loaders that use classes related to the connector; The task loader reconstructs the task class loader that uses the class associated with the connector to load the class associated with the connector; The policy loader reconstructs the policy class loader that uses the class associated with the connector to load the class associated with the connector.

5. The method according to claim 3, characterized in that: The method further comprises: After the policy class loader and the task class loader obtain the class object, obtain the class loader name that creates the class object from the class object, and determine whether the class object is created by the connector class loader according to the class loader name; If the class object is created by the connector class loader, the task class loader and the policy class loader register the reference index of the class with the base platform class loader, and record the relevant information of the loaded class into the reference index of the base platform class loader.

6. The method according to claim 1, characterized in that The method further comprises: setting a common task class loader between the basic platform class loader and the task class loader for uniformly managing and loading classes in a common JAR package.

7. The method according to claim 6, characterized in that The unified management and loading of classes in the public JAR package specifically include: When the task class loader receives a class loading request, forwarding the class loading request to the public task class loader; After receiving the class loading request, the public task class loader determines whether the class requested to be loaded is from a task JAR package or a non-task JAR package; If the class requested to be loaded belongs to the task JAR package, the common task class loader projects the class loading request to the class loader of the corresponding single task; If the class requested to be loaded belongs to a non-task JAR package, the common task class loader passes the class loading request upward to the basic platform class loader through a parent delegation mechanism.

8. The method according to claim 1, characterized in that The method further comprises: the task loader generates a corresponding task class loader for each task for class recycling scheduling, so that each task runs in its own independent class loading environment.

9. The method according to claim 1, characterized in that: The method further includes: if all parent class loaders cannot load the class requested to be loaded, returning the class loading request to the branching connector class loader, and the branching connector class loader searches for the class requested to be loaded under the responsible class path.

10. A task execution system based on dynamic class loading, characterized in that: The system comprises: A class loader creation module, used to create a basic platform class loader, and to construct a connector index and a reference index in the basic platform class loader, wherein the connector index is used to store the mapping relationship between classes and connectors, and the reference index is used to retrieve a class loader that uses a class in the connector according to the connector name; A task loader is used to create a task class loader group, which generates an independent and isolated task class loader for each loaded JAR package; A policy loader is used to create a policy class loader group, in which each loaded JAR package is generated into an independent and isolated policy class loader; A connector loader, used to create a connector class loader group, wherein the connector class loader group generates an independent and isolated connector class loader for each loaded JAR package; A transfer module, used for transferring the class loading request to the basic platform class loader according to a parent delegation mechanism after the task class loader and the policy class loader receive the class loading request; A positioning module, used for the basic platform class loader to locate the connector class loader corresponding to the class requested to be loaded through the connector index according to the class loading request; A class object creation and return module is used for the connector class loader to create a class object according to the class requested to be loaded and then return the class object to the basic platform class loader. The basic platform class loader establishes a corresponding reference index and then returns the class object to the policy class loader and the task class loader.

Images