A task execution method and system based on dynamic class loading

Abstract

The present invention provides a task execution method and system based on dynamic class loading, belongs to the field of computer technology, includes creating a basic platform class loader, and building a connector index in the basic platform class loader; creating a task class loader group, a policy class loader group and a connector class loader group respectively, each group generates an independent and isolated class loader for each loaded JAR package; after the task and policy class loaders receive a class loading request, the class loading request is passed to the basic platform class loader according to a parent delegation mechanism delegation; it locates the connector class loader corresponding to the class loaded by the request through the connector index according to the class loading request, creates a class object according to the class loaded by the request, and returns the class object to the policy class loader and the task class loader according to the delegation path. It pre-allocates resources using the class loader by pre-deploying the running resources of the Java virtual machine, thereby reducing the startup time during task execution.

Description

Technical Field

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

[0002] In Java, custom class loaders can be used to dynamically load and unload JAR (Java ARchive) packages in a running Java program without restarting. However, if garbage collection is to be performed (Garbage Collection (GC) is a mechanism for automatic memory management in programming languages such as Java. Its main task is to identify and reclaim memory space 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. In other words, if an update to a JAR package is to be loaded, all the class loaders involved need to be destroyed together. Generally, there is a tree-like relationship between class loaders. When a class wants to load its dependent class, the class loader first searches up the parent through the parent delegation mechanism, and at this time only a class name can be obtained.

[0003] The class loader is a built-in mechanism of Java. However, due to the complexity of enterprise-level applications, it can lead to problems such as memory usage not being released when content is frequently updated, and eventually leading to memory overflow. Summary of the Invention

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

[0005] To achieve the above objectives, in a first aspect, an embodiment of the present invention provides a task execution method based on dynamic class loading, the method comprising the following steps:

[0006] Create a base platform class loader and build a connector index and a reference index in the base platform class loader; 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

[0007] 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;

[0008] 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;

[0009] 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;

[0010] 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;

[0011] 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;

[0012] 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 through the basic platform class loader.

[0013] In a second aspect, an embodiment of the present invention provides a task execution system based on dynamic class loading, the system comprising:

[0014] 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. 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;

[0015] 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;

[0016] A policy loader is used to create a policy class loader group, which generates an independent and isolated policy class loader for each loaded JAR package;

[0017] A connector loader is used to create a connector class loader group, which generates an independent and isolated connector class loader for each loaded JAR package;

[0018] 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;

[0019] 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;

[0020] The 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.

[0021] The above technical solution has the following beneficial effects:

[0022] The present invention pre-deploys the running resources of the Java virtual machine and uses a class loader to pre-allocate resources, thereby reducing the startup time when the task is executed.

[0023] The present invention sets a connector loader to encapsulate the relevant resources of the connection pool, and implements a connector reloading mechanism by constructing a connector index and a reference index. When a JAR package needs to be updated or reloaded, the connector index and the reference index can be used to locate the old class loader that can be destroyed. Since the class loader holds a reference to the class it loads, when the class loader is destroyed, including the class loader object, class definition object, and class instance, when none of the three have a reference, the memory occupied by these classes can be reclaimed by the garbage collection mechanism of the Java virtual machine, thereby freeing up memory. A new class loader is then used to load the updated JAR package to achieve dynamic updating. This mechanism allows the system to update functional modules without restarting, thereby improving the flexibility and availability of the system.

[0024] By supporting dynamic routing strategies, the present invention enables the work that was originally put into production and queued for verification at night to be verified in parallel during the day, thereby improving efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0026] Figure 1 This is a flowchart of a task execution method based on dynamic class loading according to an embodiment of the present invention;

[0027] Figure 2 This is an architectural diagram of a task execution method based on dynamic class loading according to an embodiment of the present invention;

[0028] Figure 3 This is a flowchart of the implementation of the task class loader calling the connector class according to an embodiment of the present invention;

[0029] Figure 4 is a flow chart of a connector reloading mechanism according to an embodiment of the present invention;

[0030] Figure 5 This is a functional block diagram of a task execution system based on dynamic class loading according to an embodiment of the present invention;

[0031] Figure 6 This is a functional block diagram of an electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0032] The following describes embodiments of the present disclosure in more detail with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the accompanying 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 described herein. Rather, these embodiments 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 illustrative purposes only and are not intended to limit the scope of protection of the present disclosure.

[0033] It should be understood that the various steps described in the method embodiments of the present disclosure may be performed 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 respect.

[0034] As used herein, the term "including" and its variations are open-ended, i.e., "including but not limited to." The term "based on" means "based, at least in part, on." The term "one embodiment" means "at least one embodiment," the term "another embodiment" means "at least one additional embodiment," and the term "some embodiments" means "at least some embodiments." Other terms are defined in the following description.

[0035] It should be noted that the concepts of "first" and "second" mentioned in this 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.

[0036] It should be noted that the modifications of "one" and "multiple" mentioned in the present disclosure are illustrative rather than restrictive, and those skilled in the art should understand that unless otherwise clearly indicated in the context, they should be understood as "one or more". Example 1

[0037] Figure 1 This is a flowchart of a task execution method based on dynamic class loading according to an embodiment of the present invention. Figure 1 As shown, the method includes the following steps:

[0038] 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 class in the connector according to the connector name.

[0039] A base platform class loader, also known as a subclass loader, is created from the JVM (Java Virtual Machine) predefined application container class loader ("app") and used as the base platform for the customized class loading and management mechanism of this embodiment. In Java, the application class loader (also known as the system class loader) is one of the JVM's predefined class loaders, responsible for loading classes under the application class path. This embodiment creates a customized subclass loader, namely the base platform class loader, based on the application class loader to extend the class loading functionality, implement customized class loading logic, load classes from specific locations, and so on. By inheriting the application class loader, its existing functionality can be reused while adding its own features.

[0040] Step 12: Create a task class loader group. The task class loader group generates an independent and isolated task class loader for each loaded JAR package.

[0041] In this embodiment, the task class loader of the task class loader group is created and managed by the task loader. The task class loader group is used to load the Java class that defines the tasks or functions to be executed. These tasks or functions can 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, conversion, and analysis on data. Similarly, an independent class loader is generated for each JAR package in the task class loader group to ensure class loading isolation between different task JAR packages.

[0042] Step S13: Create a policy class loader group, in which each loaded JAR package is generated into an independent and isolated policy class loader.

[0043] In this embodiment, the policy loader creates and manages the policy class loaders of the policy class loader group. The policy class loader group is responsible for loading the Java class that parses the routing rules for executing tasks after the execution message arrives. These rules are used to determine how to route task requests to the appropriate task class. When the message arrives at the system, these classes are responsible for parsing the message and executing the corresponding routing rules, 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 message type and source. An independent and isolated class loader is generated for each corresponding JAR package within the policy class loader group. This means that the class loading environment in each JAR package is independent of each other, and classes with the same name in different JAR packages will not interfere with each other. This isolation helps avoid class conflicts and can achieve grayscale release with dynamically called routing policies.

[0044] Specifically, a grayscale release is a software release strategy, also known as a canary release. It allows for the gradual introduction of new features or new code versions into a production environment. Initially, the new features or new code versions are tested with a small number of users or traffic to observe their operation and performance. If everything works correctly, the rollout is gradually expanded to cover all users or traffic. This reduces the risks associated with new features or versions and helps identify and resolve potential issues promptly.

[0045] Dynamic routing strategies are one of the technical means of implementing grayscale releases. When various types of requests (such as remote procedure calls (RPCs), RESTful API requests, and message queue consumption) arrive at the platform, the system uses specific rules to determine which service instance or execution logic to route them to. These rules are called routing strategies, and they are dynamic and can be adjusted based on different conditions and needs.

[0046] When a request reaches the platform, the system analyzes its call parameters. These parameters can include various information, such as user ID, request time, request source, and business type. Based on these parameters, the system executes appropriate policy routing. For example, routing by user ID: For a grayscale release of a new feature, you can route requests from some user IDs to the new service instance or execution logic, while routing requests from other user IDs to the old service instance or execution logic. For example, you could select users with IDs ending in even numbers as grayscale users and route their requests to the new version of the service. Routing can also be based on request time. For example, during a certain time period (such as a specific time of day), all requests could be routed to the new service instance for testing. Routing can also be based on request source (e.g., different client types, different network environments), for example, only requests from specific client versions could be routed to the new service. Policy routing can be used to programmatically handle specific traffic requests. Specifically, requests that meet certain conditions can be directed to execute business logic (functions) in a specific task class. For example, developers might define multiple task classes, each containing different business logic. For example, consider an old version of a task class, OldTask, and a new version, NewTask. Both implement the same interface or inherit from the same parent class. In the routing policy code, conditional checks are performed based on the request parameters. If the request meets the specified conditions, the business logic in the new version of the task class, NewTask, is invoked; if the conditions are not met, the business logic in the old version of the task class, OldTask, is invoked.

[0047] This embodiment uses a dynamically called routing strategy, combines request parameters for policy routing, and processes specific traffic requests through coding, thereby achieving grayscale release and allowing new functions or new versions to be gradually promoted within a controllable range.

[0048] Step S14: creating a connector class loader group, which generates an independent and isolated connector class loader for each loaded JAR package.

[0049] In this embodiment, the connector class loader of the connector class loader group is created and managed by the connector loader. The connector class loader group is used to load Java classes related to the connection pool for calling third-party middleware (such as database, cache, third-party interface, etc.) when tasks and policies are executed. The connection pool is used to manage connections with third-party middleware to improve system performance and resource utilization. For example, when using JDBC (Java Database Connectivity) to connect to a database, the connection pool can reuse database connections to reduce the overhead of frequently creating and destroying connections. The connector class loader group generates an independent class loader for each JAR package containing the connection pool implementation to ensure that different third-party middleware connection pools are isolated from each other to avoid mutual influence.

[0050] In this embodiment, the 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. The task class loader group and the policy class loader group do not affect each other when using these connection pools, ensuring system concurrency and resource utilization.

[0051] Step S15: After receiving the class loading request, the task class loader and the policy class loader pass the class loading request to the basic platform class loader according to the parent delegation mechanism.

[0052] Specifically, parent delegation is the core principle of Java class loading. When a class loader receives a class loading request, it does not first attempt to load the class itself. Instead, it delegates the request to its parent class loader. This process continues upward until it reaches the top-level startup class loader. Then, starting with the startup 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, which continues trying until the class is successfully loaded or all class loaders have failed.

[0053] Step S16: 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.

[0054] When the parent delegation mechanism enters the class loading method of the base platform class loader, the base platform class loader first checks whether the class is included in the connector index. The connector index is a data structure that records the mapping between classes and connectors, that is, which classes belong to which connectors. If the class is included in the connector index, it indicates that the class is associated with a specific connector. The base platform class loader then uses the connector loader to find the corresponding connector class loader. The connector class loader is a class loader specifically responsible for loading classes associated with a specific connector. After finding the corresponding connector class loader, the connector class loader loads the class. If this is the first time the class is loaded, the connector class loader creates an object of the class and caches it internally. Subsequently, if the same class is requested to be loaded again, the connector class loader reads the class object directly from the cache without creating it from scratch.

[0055] In step S17, the connector class loader creates a class object according to the requested class and returns the class object to the basic platform class loader. The basic platform class loader creates a corresponding reference index and returns the class object to the policy class loader and the task class loader.

[0056] As an example, suppose a task class needs to load a class named com.example.DBConnector. The class loading request passes through a series of class loaders before arriving at the base platform class loader. The base platform class loader checks the connector index and finds the com.example.DBConnector class in the connector index, indicating that the 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 this is the first time the com.example.DBConnector class is loaded, the connector class loader creates an object of this class and caches it; if it is not the first time, the class object is read directly from the cache. The connector class loader returns the com.example.DBConnector class object to the task class loader via the delegation path, and the task class can then use this class object to perform database connection operations. In this embodiment, connector-related classes are loaded and cached by a dedicated connector class loader, avoiding duplicate loading and improving class loading efficiency. Different connector class loaders can independently manage their own class loading and caching, isolating different connector-related classes and avoiding class conflicts. Connector indexes allow for flexible control over which classes are loaded by the connector class loader and which continue to follow the traditional parent delegation mechanism, improving class loading flexibility and manageability. Furthermore, upon receiving the class object returned by the connector class loader, the base platform class loader will establish a corresponding reference index, allowing for quick locating of the policy class loader and task class loader when subsequently reloading the JAR package.

[0057] This embodiment of the present invention defines a policy class loader group (used to write routing rules for executing tasks parsed after Java class execution messages arrive), a task class loader group (used to define tasks or functions to be executed), and a connector class loader group (used to provide connection pools for invoking third-party middleware, such as databases, caches, and third-party interfaces, when executing tasks or policies). These three class loader groups each have distinct functions and are internally managed by their respective managers (e.g., policy loader, task loader, and connector loader). Each group generates an independent, isolated class loader for the corresponding loaded JAR package, allowing the old class loader to be destroyed and memory to be released when the JAR package is reloaded. Because each class loader group generates an independent class loader for the corresponding loaded JAR package, these class loaders are isolated from each other. Classes with the same name loaded by different class loaders are treated as different classes, thus preventing class conflicts between different JAR packages. For example, if one JAR package uses an old version of a third-party library, while another uses a newer version, independent class loaders ensure that each uses its own version of the library, preventing version conflicts.

[0058] The connector JAR package contains various class definitions. When the JAR package is loaded, these class definitions are converted into class objects, and many class object instances are created based on these classes to implement specific business functions. When the JAR package is reloaded, the old class objects and class object instances are no longer needed because the new JAR package contains new versions of the same classes or has changed their structure and functionality. If these old objects are not released, they will continue to occupy memory, causing memory leaks and ultimately exhausting system resources, affecting normal program operation. The class loader is responsible for loading class bytecode into the JVM and creating corresponding class objects. When the connector JAR package is reloaded, the connector class loader object that was originally used to load the JAR package is no longer needed. This is because the new JAR package must be loaded by a new class loader to ensure that the latest class definitions are loaded. Furthermore, the old connector class loader object holds references to the old class objects and other related resources. If these resources are not released, they cannot be reclaimed. That is, if other policy class loaders, task class loaders, or their instances reference classes created by the connector (i.e., classes in the JAR package), these references must also be processed when the connector's JAR package is reloaded. This is because these references prevent the old class objects and related resources from being reclaimed by the garbage collector. Even if the classes in the connector's JAR package are updated, these old references still point to the old class objects, resulting in inconsistent states or errors. Therefore, to address this issue and ensure the correct release of memory and the normal operation of the system, this embodiment proposes the concept of connectors to encapsulate the relevant resources of the connection pool and implements a connector reloading mechanism by constructing connector indexes and reference indexes. These policy and task class loaders and their instances that reference the classes created by the connectors must be processed accordingly, freeing the memory space they occupy or updating their references to point to the new class objects. For example, when a JAR package needs to be updated or reloaded, the connector index and reference index can be used to locate the old class loader that can be destroyed. Because class loaders hold references to the classes they load, destroying a class loader (including the class loader object, class definition objects, and class instances) frees them from references. The memory occupied by these classes can be reclaimed by the Java Virtual Machine's garbage collection mechanism, freeing up memory. A new class loader is then used to load the updated JAR package, enabling dynamic updates. This mechanism allows functional modules to be updated without a system restart, improving system flexibility and availability.

[0059] In some embodiments, the base 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 comprising: after the base platform class loader receives the class loading request, checking the connector index, finding the connector class loader corresponding to the class requested to be loaded according to the connector index, and instructing the corresponding connector class loader to create a class object according to the class requested to be loaded;

[0060] If the corresponding class loader is not found in the connector index, the request 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.

[0061] 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 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.

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

[0063] In this embodiment, the hash dictionary index forest is a data structure composed of multiple hash dictionaries, similar to a collection of hash tables. Each hash table can store data according to different rules or categories. The connector index uses the Java hash dictionary index forest data structure to search for connectors based on class name. It records the connectors belonging to each class, making it easy to quickly locate the corresponding connector during class loading.

[0064] 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 when the JAR package is reloaded.

[0065] In this way, 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, avoid repeated search and loading operations, and improve class loading efficiency.

[0066] In this embodiment, the reference index records the set of policy class loaders and task class loaders that use classes from a specific connector. The base platform class loader can use the reference index to quickly identify the relevant set of class loaders and centrally process class loading requests, avoiding duplication. When a class loader loads a class associated with a specific connector, it records that class loader under the corresponding connector name in the reference index. This allows the reference index to reflect in real time which class loaders use classes from which connectors. When the base platform class loader receives a class loading request, it first checks the connector index to determine whether the requested class belongs to a specific connector. If so, it retrieves the set of class loaders that use that connector from the reference index using the connector name. After obtaining the relevant set of class loaders, the base platform class loader can centrally process requests from these class loaders. For example, it can assign only one class loader to load the class and then share the loading result with other class loaders, avoiding repeated search and loading operations for each class loader.

[0067] This embodiment creates a subclass loader from the application class loader as a base platform and uses two indexing mechanisms, reference index and connector index, to better manage the relationship between class loaders and connectors. The reference index tracks which class loaders use classes of a specific connector, while the connector index quickly finds the corresponding connector based on the class name, thereby improving system maintainability and performance.

[0068] In some embodiments, as Figure 4 As 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 notification to the basic platform class loader.

[0069] In software development, especially in highly dynamic systems, there's a need to reload connector JAR packages. For example, when a connector's functionality needs to be updated, a vulnerability needs to be fixed, or the connector needs to adapt to new environmental changes, the corresponding JAR package is reloaded to achieve the upgrade or adjustment. In this embodiment, when a connector-related JAR package needs to be updated or reloaded, the original connector class loader is not directly reused. Instead, a new connector class loader is created. Because class loaders cache classes when loading, reusing the old class loader would prevent the classes in the new JAR package from being loaded correctly, causing the program to continue using the old class version. Creating a new connector class loader ensures that the latest class definitions are loaded from the new JAR package. When a connector JAR package is reloaded or updated, the system needs a way to notify other related components so that they can make appropriate adjustments. This embodiment uses a method of sending a notification to the base platform class loader. The base platform class loader typically plays a relatively central role in the entire class loading system, acting as a JAR "hub" to communicate information about connector reloads to other components that need to know.

[0070] 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 classes related to the connector.

[0071] When a new connector class loader loads a new JAR package, the mapping between the classes and connectors in it changes. The base platform class loader needs to re-merge the connector index to update these mappings to ensure that the connector to which the class belongs can be accurately found during subsequent class loading.

[0072] Specifically, when loading a new connector JAR package, 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 mapping relationship between the new class and the connector is added to the connector index. If the class name already exists in the index, but the corresponding connector has changed, the mapping relationship is updated. If certain 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.

[0073] After the base platform class loader updates the connector index, it triggers a reference index to quickly locate the class loaders associated with the reloaded connector. For example, if there are multiple class loaders that rely on certain functionality or classes provided by the connector when loading their respective classes, these class loaders will be recorded in this collection. After obtaining the collection of class loaders that reference the connector, the system iterates through the collection. For each element in the collection, that is, each class loader, the reconstruction and loading operation is performed. In other words, these class loaders in the collection need to be reinitialized and reconfigured to correctly load classes related to the reloaded connector. For example, class definitions in the connector JAR file are reread, class associations are reestablished, and memory space is reallocated to ensure that these class loaders use the latest version of the connector, thereby ensuring that the entire system functions properly and can adapt to the changes brought about by the connector reload.

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

[0075] Because the connector JAR file has been reloaded, its classes have changed. To ensure that task and policy classes use the latest connector classes, the policy / task loader needs to reload the relevant classes. This ensures that task and policy execution is compatible with the new connector version and avoids errors caused by inconsistent class versions.

[0076] Consider a system with multiple tasks and policies, all of which depend on a database connector. When the database connector's JAR package needs to be updated, a new connector class loader is created to load the new JAR package. The base platform class loader then re-merges the connector index forest and updates the class-connector mapping. It then searches the reference index to identify which task and policy class loaders use this database connector. Finally, these task and policy class loaders reload the relevant classes to adapt to the new database connector version.

[0077] Specifically, when the connector JAR package begins to reload, it triggers the base platform class loader to update the reference index and connector index. The base platform class loader will first traverse the reference index and connector index and remove all records related to the old connector. This can be achieved by finding and deleting the record with the old connector name as the key, and deleting all class name mapping records pointing to the old connector. The base 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 base platform class loader will update the reference index and connector index according to the new class loading situation. The new reference relationship and the mapping relationship between the class and the connector are added to the corresponding index.

[0078] By releasing these related objects, the embodiment of the present invention can effectively reclaim memory, avoid memory leaks and potential program errors, and enable the system to run in a clean and stable state after the connector JAR package is reloaded, using the classes and functions in the new JAR package to complete corresponding tasks.

[0079] In some embodiments, the method may further include:

[0080] After the policy class loader and the task class loader obtain the class object, the class loader name that created the class object is obtained from the class object, and the class loader name is used to determine whether the class object is created by the connector class loader.

[0081] 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 in the reference index of the base platform class loader.

[0082] Specifically, when the policy class loader and the task class loader receive a class object returned by the parent class loader, they can obtain the name of the class loader that created the class object through some means (such as a method or property of the class object). Based on the class loader name, they determine the class's origin. If the class is found to have been created by a connector class loader, it indicates that the class is associated with a connector. Connector class loaders are typically responsible for loading classes related to connections to external resources (such as databases and message queues). If the class is determined to have been created by a connector class loader, the task class loader and the policy class loader must register a reference index for the class with the base platform class loader. This means that the task class loader or policy class loader records information about the loaded class in the base platform class loader's reference index. This registration allows the base platform class loader to clearly understand which class loader loaded each class and any dependencies between these classes. When a connector changes (such as reloading a JAR package), the base platform class loader can use the reference index to quickly locate the affected class and the corresponding class loader, and then take appropriate action, such as reloading the relevant class, to ensure normal system operation.

[0083] like Figure 2 As 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 unified management and loading of classes in the common JAR package.

[0084] In this embodiment, the task class will rely on some public JAR packages. To prevent each task class loader from repeatedly loading classes in these public JAR packages, a public task class loader is added between the base platform class loader and the task class loader. However, the public task class loader itself does not create any classes. It is simply an index of the relationship between JAR packages and classes. It maintains a mapping (map) with the class name as the key and the URL path of the class in the JAR package as the value. It follows a hierarchical overlay (i.e., newly introduced class mappings will overwrite old mappings). It knows which classes exist in which JAR packages. For classes in the JAR packages involved in the task class loader (including the public part), the public task class loader will project these classes into the class loader of the single task that initiated the parent delegation source for creation. In this way, each task has its own independent class instance. Even if these classes come from a public JAR package, isolation between tasks can be achieved to avoid mutual interference.

[0085] For classes in non-task JAR packages—that is, classes that fall outside the scope of the task class loader—the public task class loader follows the parent delegation mechanism, passing the class loading request up to the parent class loader, which then completes the class creation. This ensures that the loading of Java core classes and other non-task-related classes follows the standard Java class loading process, ensuring system stability and security.

[0086] This embodiment implements isolation by setting up a public task class loader to project classes belonging to the task class loader (including the public) JAR package into the class loader of a single task. For classes in non-task JAR packages, class creation is implemented upward through parent delegation. This allows for centralized management of public class loading and improves resource utilization efficiency.

[0087] In some embodiments, unified management and loading of classes in a public JAR package specifically include:

[0088] When the task class loader receives a class loading request, it forwards the class loading request to the public task class loader.

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

[0090] 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.

[0091] In this embodiment, when a task needs to load a class, the task class loader will first ask the public task class loader. The public task class loader determines whether this class belongs to the JAR package involved in the task class loader (including the public part) based on the index it maintains. If so, the public task class loader will "project" the loading request of this class into the task class loader corresponding to the 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 public JAR package, these classes loaded by the class loader of each task are isolated from each other, and different tasks will not affect each other.

[0092] For example, suppose there are two tasks: Task A and Task B, both of which depend on the public common.jar and their own specific taskA.jar and taskB.jar. When Task A needs to load the com.example.CommonClass class in common.jar: Task A's class loader asks the public task class loader. The public task class loader knows from the index that com.example.CommonClass belongs to the public JAR package and is related to Task A. The public task class loader "projects" the loading request of this class to Task A's class loader. Task A's class loader 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 the class will be created through Task B's class loader, which is isolated from the instance in Task A.

[0093] The embodiment 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. Classes in the public JAR package do not need to be repeatedly loaded in each task class loader, saving memory and system resources.

[0094] 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 the parent delegation mechanism.

[0095] In this embodiment, when a task class loader encounters a class in a non-task JAR package, it needs to pass the load request upward. The public task class loader is an intermediate node in this process. It will pass 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.

[0096] This embodiment helps maintain class loading consistency across the entire system by setting up a common task class loader. It acts as an intermediate layer, standardizing the path for class loading requests. This ensures that no matter which task class loader initiates a request to load a non-task JAR package class, it will follow a unified process and path, thus avoiding class loading confusion.

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

[0098] In scenarios where JAR packages are dynamically loaded and updated, the common task class loader can better manage class loading changes. When non-task JAR packages are added or updated in the system, the common task class loader can promptly detect these changes and correctly load the new or updated classes during parent delegation. It acts as a unified management node, coordinating the loading and use of non-task JAR package classes by different task class loaders.

[0099] Through this design of the embodiment of the present invention, isolation between task classes is achieved, and classes in the public JAR package are effectively shared. At the same time, the correct loading of non-task classes is guaranteed, the characteristics of the Java class loading mechanism are fully utilized, and the flexibility and maintainability of the system are improved.

[0100] In some embodiments, the method may further include: 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.

[0101] Specifically, Java uses a parent delegation mechanism to load classes. Under this mechanism, class loaders form a tree structure, with each class loader having a parent class loader. When a class loader receives a class loading request, it first delegates the request to the parent class loader, attempting to load the class layer by layer, starting with the top-level bootstrap class loader. If the parent class loader fails to load the class, the current class loader attempts to load the class itself.

[0102] In Java, the uniqueness of a class is determined by both its fully qualified name (including the package name) and the class loader that loaded it. This means that even if two classes have the same fully qualified name, if they are loaded by different class loaders, the Java Virtual Machine (JVM) will treat them as different classes. This is because different class loaders have independent namespaces, and the classes in each namespace are isolated from each other.

[0103] In this embodiment, the task class loader generates a subclass loader for each task, so that the classes of each task are loaded into their own independent 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, suppose there are two tasks, each with a class named com.example.MyClass. Because each task has its own independent subclass loader, the two com.example.MyClass classes will be loaded by different class loaders. Although the class names are the same, because they are loaded by different class loaders, the JVM will treat them as different classes.

[0104] Because different tasks rely on different versions of the same library. This embodiment uses different class loaders to load these tasks, so each task can use the library version it needs, avoiding the version conflict problem. For example, task A relies on library-1.0.jar, and task B relies on library-2.0.jar. Using different class loaders can ensure that the two tasks each use their own library version. Moreover, each task has its own class loader, and when the task ends, the class loader corresponding to the task can be destroyed. Since the class loader holds a reference to the class it loads, after the class loader is destroyed, the memory occupied by these classes can be reclaimed by the garbage collection mechanism of the JVM, realizing class recycling scheduling and improving memory usage efficiency.

[0105] In some embodiments, the method may further include: if all parent class loaders cannot 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 under the responsible class path.

[0106] In this embodiment, a branch chain refers to the situation where the connector class loader is not on the path of its parent delegation relative to the policy class loader and the task class loader. Since these class loaders can only behave according to parent delegation, the branch chain is invisible to them. In this case, the base platform class loader is required to act as an intermediary to pass the loaded connector class object and package it so that it appears to be a class loaded by the base platform class loader from the perspective of the policy class loader or the task class loader.

[0107] In order to enable those skilled in the art to better understand the technical solution provided by the embodiment of the present application, a task execution method based on dynamic class loading provided by the embodiment of the present application is described in detail below. Figure 3 The implementation process of the task class loader calling the connector class in the embodiment of the present invention is as follows: Figure 3 As shown, it includes the following steps:

[0108] S1, class loading method: the task class loader delegates the class requested to be loaded to the public task class loader through the parent delegation mechanism;

[0109] S2, class loading method: The public task class loader checks whether the class requested to be loaded is in the public class dictionary (task JAR). If so, it projects it to the task class loader that requested to load the class and calls the class creation method; if not, it delegates the class requested to be loaded to the basic platform class loader through the parent delegation mechanism;

[0110] S3, class loading method: The base platform class loader checks whether the class requested to be loaded is in the connector index. If so, the connector loader locates the specified connector class loader and executes S4. If not, the parent delegation mechanism is used to delegate the class requested to be loaded to the JVM class loader (i.e., the parent class loader) and execute S5.

[0111] S4, class loading method: After the connector class loader calls the class creation method, it returns the class object to the task class loader according to the original path and executes S6;

[0112] S5, class loading method: If the JVM class loader fails to find the class, it returns to the original leaf node class and then loads it in the task class loader;

[0113] S6, the task class loader registers the reference index of this class with the basic platform class loader.

[0114] In this embodiment, when the task class loader calls the connector runtime environment, a unified environment class manages the connector group through static classes and singleton storage. Specifically, the three managers—the connector loader, the policy loader, and the task loader—must be callable by any class in the entire mechanism to achieve a coherent system. Tasks introduce connector dependencies during development, but connector-related classes are not packaged during release.

[0115] In Java, a static class is a class that contains static members (static variables and static methods). The key feature of a static class is that its members can be accessed directly without creating a class instance. Using a static class to manage a connector group allows related management methods and data to be easily accessed throughout the application without having to create a new management class instance for each connector required, thus improving code convenience and consistency.

[0116] Singleton storage refers to the singleton pattern, which ensures that a class has only one instance and provides a global access point. Managing connector groups using the singleton storage pattern ensures that there is only one unified connector group manager instance throughout the application lifecycle. This prevents inconsistent operations on the connector group by multiple instances, ensuring the consistency and stability of the connector group state. For example, in a multi-threaded environment, without the singleton pattern, different threads would create different connector group manager instances, leading to confusion in the use and management of connectors. The singleton pattern, however, ensures that all threads access the same connector group manager instance, achieving unified management of connectors.

[0117] During the development phase, tasks rely on connectors to interact with third-party middleware (such as databases, caches, and third-party APIs). By including connector dependencies in their projects, developers enable the development environment to find and use connector-related classes and functionality. This allows developers to call connector methods during development and write business logic that interacts with third-party middleware. For example, when developing a database operation task, by including a database connector dependency, developers can use the connector's API to perform database connections, queries, and inserts.

[0118] During the release packaging phase, connector-related classes 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 connector-related classes are packaged, compatibility issues will arise in different environments. Moreover, connector class libraries are often relatively large, and not packaging can reduce the size of the release package and improve deployment efficiency. At runtime, the connector group is managed through the unified environment class mentioned above, and connector-related classes are dynamically loaded in the runtime environment. For example, if multiple applications are deployed 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 including all connector versions in the release package.

[0119] Under the normal mechanism, Java class loading is first delegated to the parent class loader by the parents. When the parent class loader cannot find the exception of the class, it is loaded in the current class loader. Therefore, there is generally only one class loader on the chain, and the class loader on its leaf node can call all classes. Because the class loader of the leaf node is at the very end of the class loader chain, it can not only load the classes within its own scope of responsibility, but also allow its parent class loader to try to load classes in other scopes through the parent delegation mechanism. Therefore, the class loader of the leaf node can cover the loading scope of all class loaders, so that all classes can be called; and in an embodiment of the present invention, a branched connector class loader appears. To enable the final caller strategy and task class loader to call the class created by the connector class loader, it is necessary to allow it to return in the basic platform class loader.

[0120] The task public class loader does not directly create classes. Instead, it caches public class names and class binary data. When a class needs to be loaded, it projects it to the task class loader that requests class loading to complete the creation. Therefore, classes contained in the JAR package in the task public class loader will be copied in multiple task class loaders.

[0121] 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, parent delegation will continue upward; if the class is included in the connector index, the corresponding connector class loader will be found through the connector loader, and the class object in the cache (the class object is cached in the connector class loader after the first creation) will be created or read, and returned to the task class loader along the original delegation path. Example 2

[0122] like Figure 5 As shown, an embodiment of the present invention further provides a task execution system based on dynamic class loading, the system comprising:

[0123] The basic platform class loader creation module is used to create the basic platform class loader and build the connector index and reference index in the basic platform class loader. 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.

[0124] Task loader, 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.

[0125] Policy loader, used to create a policy class loader group. The policy class loader group generates an independent and isolated policy class loader for each loaded JAR package.

[0126] Connector loader, used to create a connector class loader group, which generates an independent and isolated connector class loader for each loaded JAR package;

[0127] The transfer module is used to transfer the class loading request to the basic platform class loader according to the parent delegation mechanism after the task class loader and the policy class loader receive the class loading request;

[0128] A positioning module is 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;

[0129] The class object creation and return module is used by the connector class loader to create a class object according to the requested class and return the class object to the basic platform class loader. 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.

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

[0131] 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 requested to be loaded based on the connector index, and instructs the corresponding connector class loader to create a class object according to the class requested to be loaded.

[0132] In some embodiments, the platform further includes: a positioning module specifically configured to retrieve a policy class loader and a task class loader for using classes in the connector according to the connector name when reloading the JAR package.

[0133] In some embodiments, the platform further includes: a public task class loader, which is set between the basic platform class loader and the task class loader, and is used to uniformly manage and load classes in the public JAR package. The public task class loader is specifically used to:

[0134] When the task class loader receives a class loading request, it forwards the class loading request to the public task class loader;

[0135] After receiving the class loading request, the public task class loader determines whether the class requested to be loaded is from the task JAR package or the non-task JAR package;

[0136] 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 corresponding single task class loader;

[0137] 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 the parent delegation mechanism.

[0138] In some embodiments, the platform further includes: a reload and update module, including:

[0139] 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 base platform class loader;

[0140] 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 changed connector name to find all policy class loaders and task class loaders that use the connector;

[0141] The task loader restructures the task class loader that uses connector-related classes to load connector-related classes;

[0142] The policy loader restructures the policy class loader that uses connector-related classes to load connector-related classes.

[0143] In some embodiments, the platform further includes: a registration module for obtaining the class loader name that created the class object from the class object after the policy class loader and the task class loader obtain the class object, and determining whether the class object was created by the connector class loader based on the class loader name;

[0144] 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 in the reference index of the base platform class loader.

[0145] In some embodiments, the platform further includes: a recycling scheduling submodule, which is used by the task loader to generate a corresponding task class loader for each task for class recycling scheduling, so that each task can run in its own independent class loading environment.

[0146] In some embodiments, the platform also includes: a branch connector class loader. If all parent class loaders cannot load the class requested to be loaded, the class loading request will be returned to the branch connector class loader, and the branch connector class loader will search for the class requested to be loaded under the responsible class path.

[0147] Please refer to the method examples for specific details.

[0148] The embodiment of the present invention decouples tasks (business logic), connectors (third-party calls), and routing strategies by adding a connector loading / unloading mechanism, and allows for dynamic publishing and combination of these, thereby reducing the complexity of function development and shortening the iteration cycle of the production environment.

[0149] At the same time, the dynamic grayscale strategy allows grayscale verification of dozens of versions at the same time in the production environment, solving the time-consuming problem of traditional version releases requiring queuing for verification one by one according to different requirements.

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

[0151] The following components are connected to the I / O interface 605: an input section 606 including a keyboard, a mouse, and the like; an output section 607 including devices such as a cathode ray tube (CRT), a liquid crystal display (LCD), and speakers; a storage section 608 including devices such as a hard disk; and a communication section 609 including a network interface card such as a LAN card or a modem. 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 needed. Removable media 611, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 610 as needed, so that computer programs read from the removable media can be installed in the storage section 608 as needed.

[0152] The above specific embodiments do not limit the scope of protection of the present invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention are intended to be included within the scope of protection 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, 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. It 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 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, 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 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, characterized in that The method further includes: setting a public task class loader between the basic platform class loader and the task class loader for uniformly managing and loading classes in a public 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 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, characterized in that The method further includes: 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 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.

Images