CN120085941B

CN120085941B - Task execution method and system based on dynamic class loading

Info

Publication number: CN120085941B
Application number: CN202510562330.8A
Authority: CN
Inventors: 李峰; 肖姝; 王虓
Original assignee: Beijing Yusys Technologies Group Co ltd
Current assignee: Beijing Yusys Technologies Group Co ltd
Priority date: 2025-04-30
Filing date: 2025-04-30
Publication date: 2025-08-19
Anticipated expiration: 2045-04-30
Also published as: CN120085941A

Abstract

The invention provides a task execution method and a task execution system based on dynamic class loading, which belong to the technical field of computers and comprise the steps of creating a basic platform class loader, constructing a connector index 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 generates an independent isolated class loader for each loaded JAR packet, when the task and strategy class loader receive a class loading request, delegating the class loading request according to a parent delegation mechanism to transmit the class loading request to the basic platform class loader, positioning the class loading request to the connector class loader corresponding to the class requested to be loaded through the connector index according to the class loading request, and returning the class object to the strategy class loader and the task class loader according to a delegation path after creating the class object according to the class requested to be loaded. The running resources of the Java virtual machine are deployed in advance, the class loader is used for pre-allocating the resources, and the starting time of executing the task is reduced.

Description

Task execution method and system based on dynamic class loading

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method and a system for executing a task based on dynamic class loading.

Background

The Java can realize the dynamic loading and unloading of the Java program to the JAR (Java ARchive) package without restarting through a custom class loader in Java. However, if garbage collection (Garbage Collection, GC for short) is to be performed, it is a mechanism for automatically managing memory in a programming language such as Java, and the main task is to identify and collect memory space that is no longer used by a program, so as to avoid memory leakage and effectively use memory resources, and there is no reference to object instances, class objects, and class loaders that need to satisfy the class. I.e. if an update of a JAR packet is to be loaded, all class loaders it relates to need to be destroyed together. In general, there is a tree relationship between class loaders, and when a class is to load its dependent class, the class loader searches first through the parent delegation mechanism to the upper level, where only one class name is obtained.

Class loaders are Java self-contained mechanisms, but due to the complexity of enterprise-level applications, the problem that memory occupation cannot be released and memory overflows eventually when content is frequently updated is caused.

Disclosure of Invention

Accordingly, an objective of the embodiments of the present invention is to provide a method and a system for executing tasks based on dynamic class loading, so as to solve the above-mentioned problems.

To achieve the above object, in a first aspect, an embodiment of the present invention provides a task execution method based on dynamic class loading, the method including the steps of:

creating a basic platform class loader, and constructing a connector index and a reference index in the basic platform class loader, wherein the connector index is used for storing the mapping relation between classes and connectors, and the reference index is used for retrieving class loaders using the classes in the connectors according to connector names

Creating a task class loader group, wherein the task class loader group generates an independent isolated task class loader from each loaded JAR packet;

Creating a policy class loader group, wherein the policy class loader group generates an independent isolated policy class loader for each loaded JAR packet;

Creating a connector class loader group, which generates an independent isolated connector class loader from each loaded JAR packet;

after the task class loader and the strategy class loader receive class loading requests, the class loading requests are transmitted to the basic platform class loader according to a parent delegation mechanism;

The basic platform class loader is positioned to a 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, returns the class object to a basic platform class loader, establishes a corresponding reference index by the basic platform class loader, and returns the class object to the strategy class loader and the task class loader through the basic platform class loader.

In a second aspect, an embodiment of the present invention provides a task execution system based on dynamic class loading, where the system includes:

The class loader creation module is used for creating a basic platform class loader, constructing a connector index and a reference index in the basic platform, wherein the connector index is used for storing the mapping relation between the class and the connector, and the reference index is used for searching the class loader using the class in the connector according to the connector name;

the task loader is used for creating a task class loader group, and the task class loader group generates an independent isolated task class loader from each loaded JAR packet;

The policy loader is used for creating a policy class loader group, and the policy class loader group generates an independent isolated policy class loader from each loaded JAR packet;

a connector loader for creating a connector class loader group that generates an independent isolated connector class loader for each loaded JAR packet;

the transfer module is 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 strategy class loader receive the class loading request;

the positioning module is used for positioning the basic platform class loader to a connector class loader corresponding to the class requested to be loaded through the connector index according to the class loading request;

the class object creation and return module is used for the connector class loader to return the class object to the basic platform class loader after creating the class object according to the class requested to be loaded, and the basic platform class loader returns the class object to the strategy class loader and the task class loader after establishing the corresponding reference index.

The technical scheme has the following beneficial effects:

according to the invention, the running resources of the Java virtual machine are deployed in advance, the class loader is used for pre-allocating the resources, and the starting time of executing the task is reduced.

The invention realizes a mechanism for reloading a set of connectors by arranging the connector loader to encapsulate related resources of a connection pool and constructing the connector index and the reference index, and can position the old class loader to destroy the old class loader through the connector index and the reference index when a certain JAR packet needs to be updated or reloaded. Because the class loader holds the references to the classes loaded by the class loader, the class loader is destroyed, and the class loader comprises class loader objects, class definition objects and class instances, when all three are not referenced, the memory occupied by the classes can be recovered by a garbage recovery mechanism of the Java virtual machine, so that the memory is released. The mechanism enables the system to update the functional module under the condition of no restarting, and improves the flexibility and usability of the system.

The invention enables the work of original night production and queuing verification to be verified in parallel in the daytime through supporting the dynamic routing strategy, thereby improving the efficiency.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described, it being obvious that the drawings in the following description are only some embodiments of the present invention, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a flow chart of a method of task execution based on dynamic class loading in accordance with an embodiment of the present invention;

FIG. 2 is a block diagram of a task execution method based on dynamic class loading according to an embodiment of the present invention;

FIG. 3 is a flow chart of an implementation of a task class loader invoking a connector class in accordance with an embodiment of the present invention;

FIG. 4 is a flow chart of a connector reload mechanism in accordance with an embodiment of the present invention;

FIG. 5 is a functional block diagram of a task execution system based on dynamic class loading in accordance with an embodiment of the present invention;

Fig. 6 is a functional block diagram of an electronic device according to an embodiment of the present invention.

Detailed Description

Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While certain embodiments of the present disclosure have been shown in the accompanying drawings, it is to be understood that the present disclosure may be embodied in various forms and should not be construed as limited to the embodiments set forth herein, but are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are for illustration purposes only and are not intended to limit the scope of the present disclosure.

It should be understood that the various steps recited in the method embodiments of the present disclosure may be performed in a different order and/or performed in parallel. Furthermore, method embodiments may include additional steps and/or omit performing the illustrated steps. The scope of the present disclosure is not limited in this respect.

The term "including" and variations thereof as used herein are intended to be open-ended, i.e., including, but not limited to. The term "based on" is based at least in part on. The term "one embodiment" means "at least one embodiment," another embodiment "means" at least one additional embodiment, "and" some embodiments "means" at least some embodiments. Related definitions of other terms will be given in the description below.

It should be noted that the terms "first," "second," and the like in this disclosure are merely used to distinguish between different devices, modules, or units and are not used to define an order or interdependence of functions performed by the devices, modules, or units.

It should be noted that references to "one", "a plurality" and "a plurality" in this disclosure are intended to be illustrative rather than limiting, and those of ordinary skill in the art will appreciate that "one or more" is intended to be understood as "one or more" unless the context clearly indicates otherwise.

Example 1

FIG. 1 is a flowchart of a task execution method based on dynamic class loading according to an embodiment of the present invention, as shown in FIG. 1, the method includes the following steps:

step S11, creating a basic platform class loader, and constructing a connector index and a reference index in the basic platform class loader, wherein the connector index is used for storing the mapping relation between the class and the connector, and the reference index is used for retrieving the class loader using the class in the connector according to the connector name.

A base platform class loader, also called a subclass loader, is created from an application container class loader ("app") predefined by the JVM (Java Virtual Machine ) and used for the base platform of the class loading and management mechanism defined by the present embodiment. In Java, an application class loader (also called a system class loader) is one of class loaders predefined by a JVM and is responsible for loading classes under an application class path (classpath), and the embodiment creates a custom subclass loader, namely a basic platform class loader, based on the application class loader so as to expand the class loading function, realize custom class loading logic, load classes at specific positions and the like. By inheriting the application class loader, it is possible to multiplex its existing functions while adding its own features.

Step 12, creating a task class loader group, wherein the task class loader group generates an independent isolated task class loader from each loaded JAR packet.

In this embodiment, a task class loader of a task class loader group is created and managed by a task loader, and the task class loader group is used to load Java classes defining tasks or functions to be executed. These tasks or functions may be specific business logic such as data processing, computing tasks, etc. For example, in a data processing system, there are different task classes for performing operations such as cleaning, converting, analyzing, etc. on data. Similarly, an independent class loader is generated for each JAR package in the task class loader group, so that class loading isolation among different task JAR packages is ensured.

Step S13, creating a policy class loader group, and generating an independent isolated policy class loader from each loaded JAR packet in the policy class loader.

In this embodiment, the policy loader creates and manages a policy class loader of a policy class loader group, which is responsible for loading Java classes that execute routing rules of the task after the arrival of the message. These rules are used to determine how to route task requests to the appropriate task classes, which are responsible for parsing the message and executing the corresponding routing rules when it arrives at the system, deciding 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 based on information such as the type, source, etc. of the message. An independent isolated class loader is generated for each corresponding JAR packet within the policy class loader group. This indicates that class loading environments in each JAR packet are independent of each other, and that like-named classes in different JAR packets do not interfere with each other. This isolation is advantageous in avoiding class collisions and the routing policy that can be dynamically invoked enables gray level distribution.

Specifically, gray level distribution is a software distribution strategy, also called canary distribution. The method allows the gradual introduction of codes with new functions or new versions in a production environment, and firstly, the codes with the new functions or the new versions are issued to a small part of users or traffic for testing, and the running condition and the performance of the users or traffic are observed. If everything is normal, the range is gradually expanded, and finally all users or traffic is covered. By doing so, the risk brought by the new function or the new version can be reduced, and the potential problem can be discovered and solved in time.

The dynamically called routing strategy is one of the technical means for realizing gray level release. In a system, when various types of requests (e.g., remote procedure call RPC, restful API requests, message queue consumption, etc.) arrive at the platform, the system needs to decide which specific service instance or execution logic to route these requests to based on certain rules. This rule is a routing policy and it is dynamic and can be adjusted to different conditions and requirements.

When the request arrives at the platform, the system analyzes the call parameters of the request. These parameters may contain various information such as user ID, request time, request source, service type, etc. Based on these parameters, the system will perform the corresponding policy routing. For example, routing by user ID, for gray scale release of certain new functions, it may be selected to route requests for a portion of user IDs to new service instances or execution logic, while requests for other user IDs are still routed to old service instances or execution logic. For example, users whose user IDs end in an even number are selected as greyscale users, and their requests are routed to the new version of the service. Routing may be based on the time of the request. For example, all requests are routed to a new service instance for testing during a certain period of time (e.g., a particular period of time per day). Routing is performed according to the source of the request (e.g., different client types, different network environments, etc.). For example, only requests from a particular client version are routed to the new service. In the process of policy routing, special treatment can be performed on specific traffic requests in a coding mode. Specifically, for requests meeting a specific condition, it is allowed to execute business logic (functions) in a specific task class. For example, a developer may define multiple task classes, each containing different business logic. For example, there is an old version of task class OldTask and a new version of task class NewTask, which all implement the same interface or inherit the same parent class. In the code of the routing policy, condition judgment is performed according to the calling parameters of the request. If the request meets a specific condition, the business logic in the new version task class NewTask is invoked, and if the request does not meet the condition, the business logic in the old version task class OldTask is invoked.

According to the embodiment, through dynamically called routing strategies, strategy routing is performed by combining request parameters, and specific flow requests are processed through encoding, gray level release can be achieved, and new functions or new versions are gradually popularized in a controllable range.

Step S14, creating a connector class loader group, wherein the connector class loader group generates an independent isolated connector class loader from each loaded JAR packet.

In this embodiment, the connector class loader of the connector class loader group is created and managed by the connector loader, and the connector class loader group is used to load Java classes related to a connection pool for a task, invoking a third party middleware (such as a database, a cache, a third party interface, etc.) when a policy is executed. The connection pool is used for managing the connection with the third party middleware, and improving the performance and the resource utilization rate of the system. For example, when a database is connected using JDBC (Java Database Connectivity, java database connection), the connection pool can multiplex the database connections, reducing the overhead of frequently creating and destroying connections. The connector class loader group generates independent class loaders for each JAR packet containing connection pool realization, so that the connection pools of different third-party middleware are isolated from each other, and the mutual influence is avoided.

In this embodiment, different connection pools loaded by the connector class loader group can independently manage connection with the third party middleware, so as to avoid resource competition between different tasks or policies. The task class loader group and the strategy class loader group can not influence each other when using the connection pools, and the concurrency performance and the resource utilization rate of the system are ensured.

And S15, after the task class loader and the strategy class loader receive the class loading request, transmitting the class loading request to the basic platform class loader according to the parent delegation mechanism.

Specifically, the parent delegation mechanism is the core rule of Java class loading. When a class loader receives a class load request, it will not first attempt to load the class itself, but instead delegate the request to its parent class loader, and this process will pass up until the top-most boot class loader is reached. Then, starting from the start of class loaders, each class loader in turn attempts to load the class. If any parent class loader cannot load the class, the request is returned to the child class loader, and the child class loader continues to try until the class is successfully loaded or all class loaders try to fail.

In step S16, the basic platform class loader is positioned to the connector class loader corresponding to the class requested to be loaded through the connector index according to the class loading request.

When the parent delegation mechanism enters a class loading method of the basic platform class loader, the basic platform class loader preferentially detects whether the class is contained in the connector index, the connector index is a data structure, the mapping relation between the class and the connector is recorded, namely, which class belongs to which connector, and if the class is contained in the connector index, the class is related to a certain connector. The base platform class loader will find the corresponding connector class loader through the connector loader. The connector class loader is a class loader specially responsible for loading classes related to specific connectors, and after the corresponding connector class loader is found, the connector class loader can perform class loading operation. If the class is loaded for the first time, the connector class loader creates the object of the class and caches it inside itself. Thereafter, if the same class is requested to be loaded again, the connector class loader will read the objects of the class directly from the cache without the need for re-creation.

And S17, the connector class loader creates a class object according to the class requested to be loaded, returns the class object to the basic platform class loader, and returns the class object to the strategy class loader and the task class loader after the basic platform class loader establishes a corresponding reference index.

As an illustration, assume that a task class needs to load a class named com. The class loading request passes through a series of class loaders and then reaches the base platform class loader. The base platform class loader examines the connector index and discovers that the com.example.dbconnector class is in the connector index, indicating that the class is related to a database connector. Through the connector loader, the base platform class loader finds the connector class loader that is responsible for loading the database connector-related class. If the com.sample.DBConnector class is loaded for the first time, the connector class loader creates the object of the class and caches the object, and if the object is not loaded for the first time, the object of the class is directly read from the cache. The connector class loader returns the com.example.dbconnector class object to the task class loader on the delegation path, which the task class can use to perform database connection operations. In this embodiment, for the class related to the connector, loading and buffering are performed by a special connector class loader, so that repeated loading is avoided, and class loading efficiency is improved. Different connector class loaders can independently manage class loading and caching of the connector class loaders, isolation among related classes of different connectors is achieved, and class conflicts are avoided. Through the connector index, which classes are loaded by the connector class loader can be flexibly controlled, and which classes continue to follow the traditional parent delegation mechanism, so that the flexibility and manageability of class loading are improved. In addition, after the base platform receives the class object returned by the connector class loader, the base platform establishes a corresponding reference index so as to quickly locate the policy class loading and task class loader when the JAR package is reloaded later.

The embodiment of the invention is characterized by defining a policy class loader group (used for writing a routing rule of a task which is performed by analyzing after a Java class execution message arrives), a task class loader group (used for defining a task or a function to be performed), and a connector class loader group (used for calling a third party middleware such as a database, a cache, a third party interface and the like when the task and the policy are performed). The three class loader groups each have different functions and are internally managed by their respective managers (e.g., policy loader, task loader, and connector loader), and each group generates an independent isolated class loader for the corresponding loaded JAR packet so as to destroy the old class loader to release memory when the JAR packet is reloaded, and each class loader group generates an independent class loader for the corresponding loaded JAR packet, and these class loaders are isolated from each other. The same name class loaded by different classes of loader can be regarded as different classes, so that the classes in different JAR packets can be prevented from collision. For example, one JAR package uses the old version of a third party library, and the other JAR package uses the new version of the library, so that independent class loaders can ensure that the JAR can use the own version of the library, and the problem of version conflict does not occur.

The JAR package of the connector contains various kinds of definitions, when the JAR package is loaded, the definitions of the classes are converted into class objects, and a plurality of class object instances are created according to the classes to complete specific business functions. When a JAR packet is reloaded, the old class object and class object instance are no longer needed because the new JAR packet has a new version of the same class or the structure and function has changed. If the old objects are not released, the old objects always occupy the memory, so that the memory leaks, and finally the system resources are exhausted, thereby 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 packet of the connector is reloaded, the connector class loader object originally used to load the JAR packet is no longer needed. Because the new JAR package needs to be loaded by a new class loader to ensure that the latest class definition is loaded. Moreover, the old connector class loader object holds references to the old class object and other related resources that would not be reclaimed without being released. I.e. if there are other policy class loaders, task class loaders or their instances that reference classes created by the connector (i.e. classes in the JAR package), i.e. when the JAR package of the connector is reloaded, these references also need to be processed. As these references may result in old class objects and related resources not being reclaimed by the garbage collector. Even if the class in the JAR package of the connector is updated, these old references still point to the old class objects, resulting in inconsistent states or errors. Therefore, in order to solve this problem and ensure the correct release of the memory and the normal operation of the system, the present embodiment proposes the concept of connectors to encapsulate the related resources of the connection pool, and implement a mechanism for reloading a set of connectors by constructing a connector index and a reference index, and it is necessary to process the policies, task class loaders and instances thereof referencing the connector creation class accordingly, release the memory space occupied by them, or update their references to point to new class objects. For example, when a particular JAR packet needs to be updated or reloaded, it may be located through the connector index and the reference index to the old class loader that may be destroyed. Because the class loader holds the references to the classes loaded by the class loader, the class loader is destroyed, and the class loader comprises class loader objects, class definition objects and instances of the classes, when all three are not referenced, the memory occupied by the classes can be recovered by a garbage recovery mechanism of the Java virtual machine, so that the memory is released. And then loading the updated JAR package by using a new class loader to realize dynamic updating. The mechanism enables the system to update the functional module without restarting, and improves the flexibility and usability of the system.

In some embodiments, a basic platform class loader is positioned to a connector class loader corresponding to a class requested to be loaded through a connector index according to a class loading request, and specifically comprises the steps of checking the connector index after the basic platform class loader receives the class loading request, finding the connector class loader corresponding to the class requested to be loaded according to the connector index, and indicating the corresponding connector class loader to create a class object according to the class requested to be loaded;

If no corresponding class loader is found in the connector index, the parent class loader is delegated according to a parent delegation mechanism, and class objects are created according to the class loading request through the parent class loader.

Specifically, when the class request received by the basic platform class loader is to establish connection with the third party middleware, the basic platform class loader checks the connector index, finds a 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 connector index does not contain a class, the base platform class loader continues to delegate class loading requests up to its parent class loader according to conventional parent delegation mechanisms until a suitable class loader is found or all class loaders attempt to fail.

In this embodiment, the hash dictionary index forest is a data structure composed of a plurality of hash dictionaries, similar to a set of a plurality of hash tables. Each hash table may store data according to different rules or classifications. The connector index uses a data structure of a Java hash dictionary index forest for retrieving connectors according to class names. The method records the connectors to which each class belongs, and is convenient to quickly locate the corresponding connectors when the class is loaded.

In some embodiments, the reference index is keyed with a connector name to set a set of policy class loaders and task class loaders that use the class in the connector to values for retrieving the policy class loader and task class loader that use the class in the connector according to the connector name when the JAR packet is reloaded.

By the method, the base platform class loader can quickly determine the related class loader set by means of the reference index, uniformly process class loading requests, avoid repeated searching and loading operations and improve class loading efficiency.

In this embodiment, the reference index records a set of policy class loaders and task class loaders that use classes in a particular connector. The basic platform class loader can quickly determine the related class loader set by means of the reference index, uniformly process class loading requests and avoid repeated operation. When a class loader loads a class associated with a particular connector, the class loader needs to be recorded under the corresponding connector name in the reference index. Thus, the reference index can reflect in real time which class loaders use which connector classes. When the basic platform class loader receives a class loading request, the connector index is first checked to determine whether the class requested to be loaded belongs to a certain connector. If a connector is owned, the class loader set using that connector can be obtained from the reference index by that connector name. After the collection of related class loaders is obtained, the base platform class loader can uniformly process the requests of the class loaders. For example, only one class loader is allowed to load the class, and then the loading result is shared to other class loaders, so that each class loader is prevented from repeatedly performing searching and loading operations.

The method and the device can better manage the relation between class loading and connectors by creating the sub class loader from the application class loader as a basic platform and using two indexing mechanisms of reference index and connector index. The reference index can track which class loaders use classes of a particular connector, and the connector index can quickly find the corresponding connector according to class names, thereby improving maintainability and performance of the system.

In some embodiments, as shown in FIG. 4, the method further comprises, when reloading the JAR package, the connector loader creating a new connector class loader to load the new JAR package and sending a creation notification to the base platform class loader.

In software development, particularly in some systems with high dynamics, there is a need to reload the JAR package of the connector. For example, when the function of the connector needs to be updated, repaired, or adapted to a new environment change, the corresponding JAR packet is reloaded to realize the upgrade or adjustment of the function. In this embodiment, when the connector-related JAR packet needs to be updated or reloaded, the original connector class loader is not directly multiplexed, but a new connector class loader is created. Because class loaders can cache classes when loading classes, if old class loaders are multiplexed, classes in new JAR packages cannot be loaded correctly, thus resulting in the class still used by programs in the old version. Creating a new connector class loader can ensure that the latest class definitions are loaded from the new JAR package. When the JAR packages of the connector are reloaded or updated, the system needs a way to inform other relevant components so that they can make the corresponding adjustments. The present embodiment employs a way to send notifications to the base platform class loader. The basic platform class loader is usually located at the comparison core in the whole class loading system, and can be used as a JAR 'hub' to transmit the information of connector reload to other parts needing to be known.

And after receiving the creation notification, the basic platform class loader reconfigures the connector index to establish a mapping relation between the new class and the connector, traverses the reference index according to the connector name, and searches all policy class loaders and task class loaders using the class related to the connector.

When the new connector class loader loads the new JAR package, the mapping relation between the class and the connector changes. The basic platform class loader needs to recombine the connector indexes to update the mapping relations, so that the connectors to which the classes belong can be accurately found in the subsequent class loading process.

Specifically, during the loading process of the new connector JAR packet, the base platform class loader records the connector to which each newly loaded class belongs. For example, for a newly loaded database driver class, the database connector to which it belongs is recorded. The new class-to-connector mapping is added to the connector index. If a class name already exists in the index, but the corresponding connector changes, the mapping is updated. If some classes no longer exist in the new JAR packet or the connector to which they belong changes, the old mapping needs to be removed from the connector index.

After the base platform class loader updates the connector index, a reference index is triggered to quickly locate which class loaders are associated with the reloaded connector. For example, there are a number of different class loaders that all rely on some of the functionality or classes provided by this connector when loading the respective class, and then all of these class loaders are recorded in this collection. After obtaining the set of class loaders that reference the connector, the system traverses the set. For each element in the collection, i.e., each class loader, its operations to reconstruct the load are performed. I.e. the class loaders in the collection need to be re-initialized and configured in order to be able to load the reloaded connector-related classes correctly. For example, the class definition in the connector JAR packet is read again, the association relation among the classes is built again, the memory space is allocated again, and the like, so that the class loaders can use the latest version of the connector, the function of the whole system can be ensured to normally operate, and the change caused by the reloading of the connector can be adapted.

The task loader reconstructs a task class loader using the connector-related class to load the connector-related class, and the policy loader reconstructs a policy class loader using the connector-related class to load the connector-related class.

The classes therein have changed as the JAR package of the connector is reloaded. In order to ensure that the task class and policy class can be used with the latest connector class, the policy/task loader needs to reload the relevant class. In this way, execution of tasks and policies can be ensured to be compatible with the new connector version, and errors caused by inconsistent class versions can be avoided.

Assume that there are multiple tasks and policies in a system, all of which rely on a database connector. When the JAR package of the database connector needs to be updated, a new connector class loader is created to load the new JAR package. The basic platform class loader can recombined the connector index forest and update the mapping relation between the class and the connector. Then, by looking up the reference index, it is found which task class loader and policy class loader use this database connector. Finally, these task class loader and policy class loader reload the relevant classes to accommodate the new database connector version.

Specifically, when the JAR packet of the connector starts to be reloaded, the update operation of the reference index and the connector index by the basic platform class loader is triggered. The base platform class loader first traverses the reference index and the connector index, removing all records associated with the old connector. This can be done by looking up and deleting records keyed by old connector names, and deleting all class name mapping records pointing to the old connectors. The base platform class loader loads the new connector JAR package through the new connector class loader. During the loading process, new class loading information is recorded. After loading is completed, the basic platform class loader updates the reference index and the connector index according to the new class loading condition. The new reference relationships and class-to-connector mappings are added to the corresponding index.

According to the embodiment of the invention, the memory can be effectively recovered by releasing the related objects, so that the memory leakage and potential program errors are avoided, the system can run in a clean and stable state after the connector JAR packet is overloaded, and the classes and functions in the new JAR packet are used for completing the corresponding tasks.

In some embodiments, the method may further comprise:

After the policy class loader and the task class loader acquire class objects, acquiring class loader names for creating the class objects from the class objects, and judging whether the class objects are created by the connector class loader according to the class loader names;

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 related information of the loaded class into the reference index of the base platform class loader.

Specifically, when the policy class loader and the task class loader receive class objects returned by the parent class loader, the name of the class loader that created this class object may be obtained in some manner (e.g., the associated method or attribute of the class object). And obtaining and judging the source of the class according to the name of the class loader. If the class is found to be created by a connector class loader, this class is described as being associated with a certain connector. The connector class loader is typically responsible for loading classes related to external resource (e.g., database, message queue, etc.) connections. If the class is determined to be created by the connector class loader, the task class loader and the policy class loader need to register the reference index of the class with the base platform class loader, i.e. the task class loader or the policy class loader records the related information of the class loaded by the task class loader or the policy class loader into the reference index of the base platform class loader. Through this registration operation, the base platform class loader can clearly understand which class loader each class is loaded by, and the information such as the dependency relationship existing between these classes. When the connector changes (for example, reloads JAR package), the basic platform class loader can quickly locate the affected class and the corresponding class loader according to the reference index, and further take corresponding processing measures, such as reloading the related class, so as to ensure the normal operation of the system.

As shown in FIG. 2, in some embodiments, the method further comprises providing a common task class loader between the base platform class loader and the task class loader for unified management and loading of classes in the common JAR package.

In this embodiment, the task class may rely on some common JAR packages, and in order to avoid that each task class loader repeatedly loads the classes in the common JAR packages, a common task class loader is added between the base platform class loader and the task class loader. However, the common task class loader does not create any classes itself, it is simply an index of the JAR package to class relationships, maintains a mapping (map) with class names as keys, class values at URL paths of JAR packages, and follows a hierarchical overlay (i.e., newly introduced class mappings will override old mappings), it knows which classes exist in which JAR packages, and for classes belonging to JAR packages referred to by the task class loader (including the common part), the common task class loader will project these classes into the class loader that initiates the single task of the parent delegation source. In this way, each task has its own independent class instance, and even if the classes come from a common JAR package, isolation between tasks can be realized, and mutual interference is avoided.

For classes of the non-task JAR package, namely those not belonging to the jurisdiction of the task class loader, the common task class loader can follow a parent delegation mechanism to transmit a class loading request to a parent class loader, and the parent class loader completes class creation. Thus, the loading of Java core classes and other non-task related classes can be ensured to follow the standard class loading flow of Java, and the stability and the security of the system are ensured.

The method and the device are used for realizing isolation by setting a common task class loader to project classes belonging to a task class loader (comprising common JAR package) into a class loader of a single task, and realizing class creation by parent delegation upwards for the classes of non-task JAR packages. Thus, the loading of the public class can be managed in a centralized way, and the resource utilization efficiency is improved.

In some embodiments, the unified management and loading of classes in a common JAR package specifically includes:

when the task class loader receives the class loading request, the class loading request is forwarded to the common task class loader.

Specifically, when a task class loader receives a class loading request, it will first forward the request to the common task class loader. This is because the common task class loader is responsible for managing the common resources involved by the task class loader, including class tasks in the common JAR packet, and after the common task class loader receives the class loading request, the common task class loader determines whether the class requested to be loaded is from the task JAR packet or the non-task JAR packet through the maintained index of the JAR packet and the class relationship.

If the class requested to be loaded belongs to the task JAR package, the common task class loader projects the loading request of the class into the class loader of the corresponding single task.

In this embodiment, when a task needs to load a class, the task class loader will first query the common task class loader. The common task class loader judges whether the class belongs to a JAR packet related by the task class loader (comprising a common part) according to the index maintained by the common task class loader. If so, the common task class loader will "throw" the loading request of the class into the task class loader corresponding to the task, and let the task class loader actually create the instance of the class. This projection operation ensures that each task has its own independent class loading environment. Even though multiple tasks use classes in the same common JAR package, the classes loaded by the class loader of each task are isolated from each other, and different tasks cannot influence each other.

For example, assume that there are two tasks, task A and task B, which both rely on a common. Jar and specific tasks A. Jar and task B. Jar, respectively. When task A needs to load the com.example.Commonclass class in the 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. The common task class loader "casts" the load request of this class to the class loader of task a. The class loader of task a is responsible for loading and creating instances of com. Likewise, when task B needs to load the com.example.Commonclass class, another independent instance of the class is created by the class loader of task B, isolated from the instance in task A.

The embodiment of the invention can isolate class loading among different tasks, avoid class conflict and interference and improve the stability and maintainability of the system. Classes in the common JAR package do not need to be repeatedly loaded in each task class loader, so that memory and system resources are saved.

If the class requested to be loaded belongs to a non-task JAR package, the common task class loader transmits the loading request of the class to the basic platform class loader through a parent delegation mechanism.

In this embodiment, when the task class loader encounters a class of a non-task JAR packet, the load request needs to be transferred upwards, and the common task class loader is an intermediate node in the transfer process. The method can continuously give the request upwards to the parent class loader according to the parent delegation mechanism, and ensures that the class loading process conforms to a given hierarchical structure.

The embodiment is beneficial to maintaining the consistency of the loading of the whole system class by setting the common task class loader. As a middle layer, the method standardizes the transmission path of class loading requests, so that no matter which task class loader initiates the loading request of the non-task JAR packet class, the class loading is prevented from being confused by the unified flow and path.

In this embodiment, the common task class loader can clearly distinguish which classes belong to task JAR packages and which classes belong to non-task JAR packages. When a class of non-task JAR packages is encountered, it can accurately direct load requests to the parent delegation flow, whereas for a class of task JAR packages it will be created by projecting the class into a single-task class loader in the manner previously mentioned. This discrimination capability enables the system to employ different loading strategies depending on the different sources of the class. The common task class loader may perform preliminary screening and processing of class loading requests. Before the loading request of the non-task JAR packet class is transferred upwards, the loading request can carry out necessary checking or caching operation, so that the class loading efficiency is improved. For example, it may check if other task class loaders have loaded the same non-task class, and if so, may directly multiplex the relevant information, avoiding repeated lookup and loading processes.

In the scenario of dynamic loading and updating of JAR packages, the common task class loader can better manage changes in class loading. When a non-task JAR package is newly added or updated in the system, the common task class loader can timely sense the changes and correctly load new classes or updated classes in the parent delegation process. The method can be used as a unified management node to coordinate the loading and the use of non-task JAR packet classes by different task class loaders.

By the design of the embodiment of the invention, the isolation between task classes is realized, the classes in the public JAR package are effectively shared, the correct loading of non-task classes is ensured, the characteristics of a Java class loading mechanism are fully utilized, and the flexibility and maintainability of the system are improved.

In some embodiments, the method may further include the task loader generating a corresponding task class loader for each task for class reclamation scheduling, allowing each task to run in its own independent class loading environment.

Specifically, java uses a parent delegation mechanism to load classes, under which class loaders form a tree structure, each class loader having a parent class loader. When a class loader receives a class loading request, it will first delegate the request to the parent class loader, attempting to load the class layer by layer, starting with the top-most boot class loader. If the parent class loader cannot load, the current class loader attempts to load by itself.

In Java, the uniqueness of a class is determined by the full-defined name of the class (class name containing the package name) and the class loader that loaded it. That is, even though the full nomination of two classes is the same, if they are loaded by different class loaders, then the Java Virtual Machine (JVM) will treat them as different classes. This is because different class loaders have separate namespaces, and the classes in each namespace are isolated from each other.

In this embodiment, the task class loader generates a sub-class loader for each task, so that the class of each task is loaded in a separate class loader namespace. The class loaders of different tasks are independent of each other, and the classes they load do not affect each other. For example, assume that there are two tasks, each with a class named com. Since each task has its own independent sub-class loader, the two com.sample.myclass classes will be loaded by different class loaders, respectively. Although class names are the same, the JVM will treat them as different classes because the class loaders that load them are different.

Since different tasks depend on different versions of the same library. By loading the tasks by using different class loaders, each task can use the library of the required version, and the problem of version conflict is avoided. For example, task A depends on library-1.0.jar, task B depends on library-2.0.jar, and using different class loaders can ensure that two tasks each use their own library version. Moreover, each task is provided with a class loader, and when the task is finished, the class loader corresponding to the task can be destroyed. Because the class loader holds the references to the classes loaded by the class loader, after destroying the class loader, the memory occupied by the classes can be recovered by a garbage recovery mechanism of the JVM, so that the recovery scheduling of the classes is realized, and the use efficiency of the memory is improved.

In some embodiments, the method may further include returning a class load request to the branched connector class loader if all parent class loaders cannot load the class requested to be loaded, the branched connector class loader looking up the class requested to be loaded under the responsible class path.

In this embodiment, the branching means that the connector class loader is not on the path of its parent delegation with respect to the policy class loader and the task class loader. While the behavior of these class loaders can only follow parent delegation, the branches are not visible to them. The base platform class loader is then required to mediate the loaded connector class object and wrap it so that it is considered a class loaded by the base platform class loader from the perspective of the policy class loader or the task class loader.

In order to enable those skilled in the art to better understand the technical solution provided by the embodiments of the present application, a task execution method based on dynamic class loading provided by the embodiments of the present application is described in detail below. Fig. 3 is a flow chart of the implementation of the task class loader calling the connector class according to the embodiment of the present application, as shown in fig. 3, including the following steps:

s1, a task class loader delegates the class requested to be loaded to a public task class loader through a parent delegation mechanism;

S2, the class loading method comprises the steps that a common task class loader retrieves whether the class requested to be loaded is in a dictionary (task JAR) of the common class, if so, the common task class loader projects the class to the task class loader applying for loading the class to call the class creation method, and if not, the class requested to be loaded is delegated to a basic platform class loader through a parent delegation mechanism;

S3, searching whether the class requested to be loaded is in the connector index by the basic platform class loader, if so, positioning the basic platform class loader to a designated connector class loader through the connector loader, and executing S4;

S4, the class loading method comprises the steps that after the class creation method is called by the connector class loader, the class object is returned to the task class loader according to the original path, and S6 is executed;

s5, the class loading method comprises the steps that a JVM class loader does not find a class, returns to an original leaf node class, and loads the class in the task class loader;

S6, the task class loader registers the reference index of the class with the basic platform class loader.

In this embodiment, in the runtime environment where the task class loader invokes the connector, the connector set is managed by a unified environment class through the static class and the mode stored in a single instance, that is, three managers, i.e., the connector loader, the policy loader, and the task loader, need to enable any one class in the whole mechanism to be invoked, so as to achieve the penetration of the whole system. Tasks introduce connector dependencies at development time, but do not pack connector related classes at release packaging time.

Static classes refer in Java to classes that contain static members (static variables, static methods). The main feature of static classes is that their members can be accessed directly without creating class instances. The use of static classes to manage the connector set herein suggests that the associated management methods and data can be conveniently invoked throughout the application without creating a new management class instance where connectors are needed, thereby improving code convenience and uniformity.

Single instance storage refers to a single instance schema that ensures that a class has only one instance and provides a global access point. By managing the connector set in a single instance storage mode, only one unified connector set management instance can be ensured in the whole life cycle of the application program. This avoids inconsistent operation of the connector set by multiple instances, ensuring consistency and stability of the connector set state. For example, in a multi-threaded environment, if there is no singleton mode, different threads create different connector set management instances, resulting in confusion in the use and management of connectors. The single-instance mode can ensure that all threads access the same connector group management instance, thereby realizing unified management of connectors.

In the development phase, tasks need to rely on connectors to enable interaction with third party middleware (e.g., databases, caches, third party interfaces, etc.). Developers, by introducing connector dependencies in projects, enable development environments to find and use connector-related classes and functions. In this way, a developer can call the method of the connector in the development process, and write business logic interacting with the third party middleware. For example, when a database operation task is developed, the dependency of the database connector is introduced, and the API provided by the connector can be used for performing operations such as database connection, query, insertion, etc.

In the release packaging stage, the connector related class is not packaged into a final release package. This is because connectors are typically associated with a particular operating environment, with different operating environments requiring different versions of the connector. If connector related classes are packaged, compatibility problems can occur in different environments. Moreover, the connector class library is often larger, the volume of the release package can be reduced without packing, and the deployment efficiency is improved. At runtime, the connector-related classes are dynamically loaded in the runtime environment by managing the connector groups through the unified environment class mentioned earlier. For example, multiple applications are deployed on a cloud platform, each application needs a different version of database connector, and through dynamic loading, an appropriate connector version can be loaded according to the actual requirement of each application, without including all connector versions in a release package.

Under a normal mechanism, java class loading is that parents are assigned to a parent class loader first, and when the parent class loader cannot find the abnormality of the class, the class loader is loaded. Therefore, only class loaders on one chain can call all classes, and because the class loader of the leaf node is at the end of the class loader chain, the class loader of the leaf node can load classes in a self-responsible range, and can also enable a parent class loader to attempt to load the classes in other ranges through a parent delegation mechanism. Therefore, the class loader of the leaf node can cover the loading range of all class loaders so as to call all classes, while in the embodiment of the invention, a branched-chain connector class loader appears, so that the final caller policy and task class loader can call the class created by the connector class loader and need to be returned in the basic platform class loader.

For a task common class loader, the class is not directly created by the task common class loader, but only binary data of the common class name and the class are cached, and when the class needs to be loaded, the binary data is projected to the task class loader applying for loading the class to finish creation. Thus, the JAR package in the task common class loader, which contains classes, creates copies in multiple task class loaders.

When the parent delegation mechanism enters a class loading method of a basic platform class loader, whether the class is contained in the connector index or not is preferentially detected, parent delegation is continuously carried out upwards without the class contained in the connector index, if the class is contained in the connector index, a corresponding connector class loader is found through the connector loader, class objects in a cache (the class objects are cached in the connector class loader after the first creation) are created or read in the corresponding connector class loader, and the class objects are returned to the task class loader in an original way according to a delegation path.

Example two

As shown in fig. 5, an embodiment of the present invention further provides a task execution system based on dynamic class loading, where the system includes:

the system comprises a basic platform class loader creation module, a reference index and a storage module, wherein the basic platform class loader creation module is used for creating a basic platform class loader, constructing a connector index and the reference index in the basic platform class loader, wherein the connector index is used for storing the mapping relation between the class and the connector, and the reference index is used for searching the class loader using the class in the connector according to the connector name;

The connector loader is used for creating a connector class loader group, and the connector class loader group generates an independent isolated connector class loader from each loaded JAR packet;

The transfer module is used for transferring the class loading request to the basic platform class loader according to the parent delegation mechanism after the task class loader and the strategy class loader receive the class loading request;

the positioning module is used for positioning the basic platform class loader to the connector class loader corresponding to the class requested to be loaded through the connector index according to the class loading request;

The class object creation and return module is used for the connector class loader to return the class object to the basic platform class loader after creating the class object according to the class requested to be loaded, and the basic platform class loader returns the class object to the strategy class loader and the task class loader after creating the reference index.

In some embodiments, the positioning module is specifically configured to:

when the class request received by the basic platform class loader is to establish connection with the third-party middleware, the basic platform class loader checks the connector index, finds a 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.

In some embodiments, the platform further comprises a positioning module, specifically configured to retrieve a policy class loader and a task class loader using classes in the connector according to the connector name when the JAR package is reloaded.

In some embodiments, the platform further comprises a common task class loader arranged between the base platform class loader and the task class loader for unified management and loading of classes in the common JAR package. The common task class loader is specifically for:

when the task class loader receives the class loading request, forwarding the class loading request to the common task class loader;

after receiving a class loading request, the common task class loader judges whether the class requested to be loaded is from a task JAR packet or a non-task JAR packet;

If the class requested to be loaded belongs to a task JAR packet, the common task class loader projects the loading request of the class into the class loader of the corresponding single task;

In some embodiments, the platform further comprises a reload and update module comprising:

When the JAR package related to the connector is updated, the connector loader creates a new connector class loader to load the updated JAR package and sends a creation notification to the basic platform class loader;

After receiving the creation notification, the basic platform class loader reconfigures the connector index to establish a mapping relation between the new class and the connector, traverses the reference index according to the changed connector name, and searches all policy class loaders and task class loaders using the connector;

The task loader reconstructs a task class loader using the class related to the connector to load the class related to the connector;

The policy loader reconstructs the policy class loader using the connector-related class to load the connector-related class.

In some embodiments, the platform further comprises a registration module, a class loader name generation module and a class loading module, wherein the registration module is used for acquiring a class name for creating a class object from the class object after the policy class loader and the task class loader acquire the class object, and judging whether the class object is created by the connector class loader according to the class loader name;

In some embodiments, the platform further comprises a recycling and scheduling sub-module, which is used for generating a corresponding task class loader for each task for recycling and scheduling the class, so that each task runs in an independent class loading environment.

In some embodiments, the platform further comprises a branched connector class loader, if all parent class loaders cannot load the class requested to be loaded, the class loading request is returned to the branched connector class loader, and the branched connector class loader searches for the class requested to be loaded under the responsible class path.

For details, please refer to the method embodiment.

The embodiment of the invention decouples tasks (business logic), connectors (third party call) and routing strategies by adding the loading/unloading mechanism of the connectors, and can dynamically release and arrange and combine, thereby reducing the complexity of function development and shortening the iteration period of the production environment.

Meanwhile, the dynamic gray level strategy can allow gray level verification to be carried out on tens of versions in a production environment, and the time-consuming problem that the traditional versions release different requirements and need to be verified in a queuing mode one by one is solved.

Referring to FIG. 6, a schematic diagram of a computer system 600 suitable for use in implementing an electronic device of an embodiment of the invention is shown. As shown in fig. 6, 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 RAM603, various programs and data required for the operation of the computer system 600 are also stored. The CPU601, ROM602, and RAM603 are connected to each other through a bus 604. An input/output (I/O) interface 605 is also connected to bus 604. The CPU601 is configured to implement a task execution method based on dynamic class loading provided by the present invention.

Connected to the I/O interface 605 are an input section 606 including a keyboard, a mouse, and the like, an output section 607 including a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, a speaker, and the like, a storage section 608 including a hard disk, and the like, and a communication section 609 including a network interface card such as a LAN card, a modem, and the like. The communication section 609 performs communication processing via a network such as the internet. The drive 610 is also connected to the I/O interface 605 as needed. A removable medium 611 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is installed on the drive 610 as necessary, so that a computer program read out therefrom is installed into the storage section 608 as necessary.

The above embodiments do not limit the scope of the present invention. It will be apparent to those skilled in the art that various modifications, combinations, sub-combinations and alternatives can occur depending upon design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the 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 base platform class loader and construct a connector index and a reference index in the base 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, and the task class loader group is used to load the Java class that defines the task or function to be executed;

Create a policy class loader group, which generates an independent and isolated policy class loader for each loaded JAR package. The policy class loader group is used to load the Java class that parses the routing rules of the execution task after the execution message arrives;

Create a connector class loader group. The connector class loader group generates an independent and isolated connector class loader for each loaded JAR package. The connector class loader group is used to load Java classes related to the connection pool for calling third-party middleware when executing tasks and policies.

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 a 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 is 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, further comprising:

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 base 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 related to the connector to load the class related to the connector;

The policy loader reconstructs a 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, further comprising:

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 was 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 is 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 unified management and loading of classes in a common JAR package.

7. The method according to claim 6, wherein the unified management and loading of classes in a public JAR package specifically comprises:

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 public 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 public 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 is characterized in that the method further includes: 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.

9. The method according to claim 1 is characterized in that the method further includes: if all parent class loaders cannot load the class requested to be loaded, the class loading request is returned to the branch connector class loader, and the branch 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 is used to create a base platform class loader and construct a connector index and a reference index in the base 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 class in the connector according to the connector name.

A task loader is used to create a task class loader group. The task class loader group generates an independent and isolated task class loader for each loaded JAR package. The task class loader group is used to load Java classes that define tasks or functions to be executed;

A policy loader is used to create a policy class loader group. Each loaded JAR package in the policy class loader group generates an independent and isolated policy class loader. The policy class loader group is used to load the Java class that parses the routing rules of the execution task after the execution message arrives;

Connector loader, used to create a connector class loader group. The connector class loader group generates an independent and isolated connector class loader for each loaded JAR package. The connector class loader group is used to load Java classes related to the connection pool for calling third-party middleware during task and policy execution;

A transfer module, configured to transfer 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, configured 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 loaded by the request 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.