Adaptive dynamic arrangement method and system of hybrid thread pool

Abstract

This invention discloses an adaptive dynamic orchestration method and system for hybrid thread pools. The method includes: statistically analyzing the execution characteristics of a target task within a preset sampling window; determining the task type of the target task based on the execution characteristics; allocating the target task to a corresponding thread pool based on the task type; monitoring the load metrics of all thread pools in real time; adjusting resource configuration of the thread pools based on the load metrics; and / or migrating tasks. This improves execution efficiency and system stability in hybrid task scenarios and enhances the adaptive capability to load fluctuations.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to an adaptive dynamic orchestration method and system for hybrid thread pools. Background Technology

[0002] Traditional platform threads in Java have high creation and switching costs, and in high-concurrency I / O scenarios, they are prone to resource exhaustion due to an explosion in the number of threads. The virtual threads introduced in JDK 21 are lightweight user-space threads, suitable for I / O-intensive tasks, but in CPU-intensive tasks, they are less efficient than platform threads due to the additional overhead of suspension / resumption and carrier thread switching.

[0003] Currently, the JDK does not provide a standardized framework for hybrid scheduling of platform threads and virtual threads. Developers commonly use two approaches: Standalone use: Maintain two separate thread pools and manually select which to submit. Disadvantages: Requires manual prediction of task types and cannot adapt to dynamic changes.

[0004] Fixed-ratio mixing: The mixing pool is constructed according to a fixed ratio (e.g., 16:1). Disadvantage: The ratio is fixed, and it cannot adapt to real-time load fluctuations.

[0005] The above methods have the following technical drawbacks: CPU-intensive task performance degradation: Virtual threads in pure CPU-intensive tasks incur additional overhead due to suspension / resumption and carrier thread switching, resulting in lower execution efficiency than platform threads.

[0006] Resource exhaustion under extreme load: During high concurrency, the number of virtual threads far exceeds the number of threads on the carrier platform. Large queuing leads to the loss of lightweight advantages and increases scheduling overhead.

[0007] Lack of a standardized hybrid scheduling framework: The JDK only provides basic virtual thread APIs and does not have a built-in hybrid scheduling framework. Developers who implement their own are prone to errors and face the risk of resource leaks.

[0008] Fixed ratios cannot adapt to dynamic loads: Business loads vary over time, and fixed-ratio mixing pools cannot be adjusted in real time, making manual parameter tuning slow and inefficient.

[0009] There is currently no effective solution to the above problems in existing technologies. Summary of the Invention

[0010] To address the aforementioned issues, this invention provides an adaptive dynamic orchestration method and system for hybrid thread pools. By identifying target task types in real time and allocating them to corresponding thread pools, it avoids performance degradation of CPU-intensive tasks executed on virtual threads. Simultaneously, it continuously monitors load metrics, adjusts resource configurations and / or migrates tasks in the thread pools, thereby preventing resource exhaustion under extreme loads, adapting to dynamic business changes, and providing a standardized hybrid scheduling framework.

[0011] To achieve the above objectives, an adaptive dynamic orchestration method for hybrid thread pools includes: statistically analyzing the execution characteristics of a target task within a preset sampling window; determining the task type of the target task based on the execution characteristics; allocating the target task to the corresponding thread pool based on the task type; monitoring the load metrics of all thread pools in real time; adjusting the resource configuration of the thread pools based on the load metrics; and / or migrating tasks.

[0012] Further optionally, the execution characteristics include: CPU usage percentage and blocking percentage; the step of determining the task type of the target task based on the execution characteristics includes: if the blocking percentage is greater than a first preset percentage threshold and the CPU usage percentage is less than a second preset percentage threshold, then the task type of the target task is determined to be I / O intensive; otherwise, it is determined whether the CPU usage percentage is greater than a third preset percentage threshold and the blocking percentage is less than a fourth preset percentage threshold. If yes, then the task type of the target task is CPU intensive; otherwise, the task type of the target task is mixed.

[0013] Further optionally, the target task is assigned to a corresponding thread pool according to the task type, including: when the task type of the target task is CPU intensive, it is assigned to a first thread pool; when the task type of the target task is I / O intensive or mixed, it is assigned to a second thread pool; wherein, the first thread pool is a platform thread pool and the second thread pool is a virtual thread pool.

[0014] Optionally, adjusting the resource configuration of the thread pool based on the load metric includes: when the queuing pressure of the second thread pool is greater than a first preset threshold and the resource utilization of the first thread pool is less than a second preset threshold, increasing the number of platform threads in the first thread pool; otherwise, determining whether the queuing pressure of the first thread pool is greater than the first preset threshold and the resource utilization of the second thread pool is less than the second preset threshold, and if so, increasing the ratio of virtual threads in the second thread pool to platform threads in the first thread pool; if not, determining whether the throughput decrease rate is greater than a third preset threshold, and if so, rolling back to the previous resource configuration; if not, maintaining the current resource configuration.

[0015] Further optionally, the step of migrating tasks to the thread pool based on the load metric includes: when the queuing pressure of the second thread pool is greater than a fourth preset threshold and the resource utilization of the first thread pool is less than a fifth preset threshold, selecting a preset number of CPU-intensive tasks from the execution queue of the second thread pool as tasks to be migrated; and migrating the tasks to be migrated to the first thread pool.

[0016] On the other hand, the present invention also provides an adaptive dynamic orchestration system for hybrid thread pools, comprising: a classification module, used to statistically analyze the execution characteristics of a target task within a preset sampling window, and determine the task type of the target task based on the execution characteristics; a thread pool allocation module, used to allocate the target task to the corresponding thread pool according to the task type; and an adaptive adjustment module, used to monitor the load indicators of all thread pools in real time, and adjust the resource configuration of the thread pools and / or migrate tasks according to the load indicators.

[0017] Further optionally, the execution characteristics include: CPU usage and blocking usage; the classification module includes: a first determination submodule, used to determine that the task type of the target task is I / O intensive if the blocking usage is greater than a first preset threshold and the CPU usage is less than a second preset threshold; a second determination submodule, used to determine whether the CPU usage is greater than a third preset threshold and the blocking usage is less than a fourth preset threshold when the conditions of the first determination submodule are not met; if so, the task type of the target task is CPU intensive; otherwise, the task type of the target task is mixed.

[0018] Further optionally, the thread pool allocation module includes: a first allocation submodule, used to allocate the target task to a first thread pool when the task type is CPU intensive; and a second allocation submodule, used to allocate the target task to a second thread pool when the task type is I / O intensive or mixed; wherein the first thread pool is a platform thread pool and the second thread pool is a virtual thread pool.

[0019] Further optionally, the adaptive adjustment module includes: a first configuration adjustment submodule, used to increase the number of platform threads in the first thread pool when the queuing pressure of the second thread pool is greater than a first preset threshold and the resource utilization of the first thread pool is less than a second preset threshold; a second configuration adjustment submodule, used to determine whether the queuing pressure of the first thread pool is greater than the first preset threshold and the resource utilization of the second thread pool is less than the second preset threshold when the conditions of the first configuration adjustment submodule are not met, and if so, to increase the ratio of the number of virtual threads in the second thread pool to the number of platform threads in the first thread pool; and a third configuration adjustment submodule, used to determine whether the throughput decline rate is greater than a third preset threshold when the conditions of the first and second configuration adjustment submodules are not met, and if so, to roll back to the previous resource configuration; otherwise, to maintain the current resource configuration.

[0020] Further optionally, the adaptive adjustment module further includes: a task to be migrated submodule, used to select a preset number of CPU-intensive tasks as tasks to be migrated from the execution queue of the second thread pool when the queuing pressure of the second thread pool is greater than a fourth preset threshold and the resource utilization of the first thread pool is less than a fifth preset threshold; and a task migration submodule, used to migrate the tasks to be migrated to the first thread pool.

[0021] The above technical solution has the following beneficial effects: By allocating CPU-intensive tasks to the platform thread pool and I / O-intensive tasks to the virtual thread pool, the additional overhead of virtual threads executing CPU-intensive tasks is avoided, improving the execution efficiency of CPU-intensive tasks and the concurrency capability of I / O-intensive tasks; by monitoring the load in real time and dynamically adjusting resource configuration or migrating tasks, resource exhaustion caused by virtual thread queuing under extreme high concurrency is avoided, thus enhancing system stability; by providing a standardized adaptive hybrid scheduling framework, the development threshold is lowered and the amount of custom scheduling code written is reduced; by automatically adjusting thread pool resources according to load indicators, the system can smoothly adapt to the dynamic changes in business load without manual parameter tuning, achieving adaptive optimization. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a flowchart of the adaptive dynamic orchestration method for hybrid thread pools provided in this embodiment of the invention; Figure 2This is a flowchart of the task type determination method provided in the embodiments of the present invention; Figure 3 This is a flowchart of the thread pool allocation method provided in an embodiment of the present invention; Figure 4 This is a flowchart of the resource configuration adjustment method provided in an embodiment of the present invention; Figure 5 This is a flowchart of the task migration method provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of the adaptive dynamic orchestration system for hybrid thread pools provided in an embodiment of the present invention; Figure 7 This is a schematic diagram of the classification module provided in an embodiment of the present invention; Figure 8 This is a schematic diagram of the thread pool allocation module provided in an embodiment of the present invention; Figure 9 This is a schematic diagram of the structure of the adaptive adjustment module for the resource configuration adjustment submodule provided in this embodiment of the invention; Figure 10 This is a schematic diagram of the adaptive adjustment module used for the task migration submodule provided in an embodiment of the present invention.

[0024] Figure reference numerals: 100 - Classification module; 1001 - First determination submodule; 1002 - Second determination submodule; 200 - Thread pool allocation module; 2001 - First allocation submodule; 2002 - Second allocation submodule; 300 - Adaptive adjustment module; 3001 - First configuration adjustment submodule; 3002 - Second configuration adjustment submodule; 3003 - Third configuration adjustment submodule; 3004 - Task to be migrated determination submodule; 3005 - Task migration submodule. Detailed Implementation

[0025] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0026] To address the problems in existing technologies where the inability to dynamically schedule platform threads and virtual threads leads to poor performance in CPU-intensive tasks, easy resource exhaustion under high concurrency, and a lack of standardized frameworks, this invention provides an adaptive dynamic orchestration method for hybrid thread pools. Figure 1 This is a flowchart of the adaptive dynamic orchestration method for hybrid thread pools provided in this embodiment of the invention, as follows: Figure 1 As shown, the method includes: S1. Statistically analyze the execution characteristics of the target task within the preset sampling window, and determine the task type of the target task based on the execution characteristics.

[0027] After a thread task is submitted, a preset sampling window (e.g., 5ms) is started. Within this sampling window, the execution characteristic data of the target task during execution is collected. These execution characteristics can distinguish the degree of dependence of the task on computing resources and waiting resources, such as the characteristic indicators of the task consuming processor resources and the characteristic indicators of the task being blocked due to waiting for external resources (such as I / O, network, locks).

[0028] Using the thread monitoring APIs provided by JDK 25 (such as Thread.getTotalCpuTime() and Thread.getBlockedTime()), one or more execution characteristic data of the target task are collected within the sampling window. Then, based on the collected characteristic data and combined with pre-defined classification rules (such as judgment logic based on feature thresholds or classification strategies based on statistical models), the target task is automatically mapped to a certain category among the predefined task types in the classification rules.

[0029] S2. Assign the target task to the corresponding thread pool according to the task type.

[0030] The system has several pre-configured thread pools, each with different execution characteristics (e.g., some thread pools are suitable for handling computationally intensive tasks, while others are suitable for handling waiting-intensive tasks). By establishing a mapping relationship between task types and thread pools, each type of task can be assigned to the thread pool that best matches its resource requirements.

[0031] Regarding the specific implementation of the mapping, static rules (such as a one-to-one correspondence between type and thread pool) can be used, or dynamic strategies (such as adjusting the mapping based on real-time load) can be introduced. In one feasible solution, a fixed type-thread pool mapping table is used, and the target thread pool is directly selected based on the identified type.

[0032] S3. Monitor the load metrics of all thread pools in real time, and adjust the resource configuration of the thread pools and / or migrate tasks based on the load metrics.

[0033] During task execution, the load status of all thread pools is monitored in real time, and indicators that reflect the busy or idle status of each thread pool are collected, such as task queue length, thread utilization, and average response time.

[0034] Based on the collected load metrics, the system dynamically determines whether there are resource bottlenecks or waste in each thread pool. When one thread pool is overloaded (e.g., due to severe task backlog) while another thread pool is relatively idle, an adaptive adjustment operation is automatically triggered. The adjustment operation includes resource configuration adjustments and / or task migration.

[0035] Resource configuration adjustment refers to changing the internal capacity parameters of a thread pool, such as increasing or decreasing the number of threads or adjusting the ratio between virtual threads and carrier resources, in order to improve the processing capacity of the target thread pool or release idle resources.

[0036] Task migration refers to transferring tasks to be executed from one thread pool to another, thereby achieving cross-pool load balancing, alleviating queuing pressure in the source thread pool, and improving the resource utilization of the target thread pool.

[0037] The triggering conditions and specific execution strategies for the above adjustment operations can be implemented in various ways, such as threshold-based rules, prediction models based on historical data, or closed-loop feedback control.

[0038] As an optional implementation method, the execution characteristics include: CPU usage and blocking usage.

[0039] CPU utilization refers to the ratio of processor time consumed by the target task within the sampling window to the total duration of the window, reflecting the intensity of the task's utilization of computing resources; blocking utilization refers to the ratio of the time the target task is blocked due to waiting for external resources (such as I / O, locks, network responses) to the total duration of the window, reflecting the degree of dependence of the task on waiting resources.

[0040] As an optional implementation method, Figure 2 This is a flowchart of the task type determination method provided in the embodiments of the present invention, such as... Figure 2 As shown, the task type of the target task is determined based on execution characteristics, including: S101. If the blocking percentage is greater than the first preset percentage threshold and the CPU percentage is less than the second preset percentage threshold, then the target task is determined to be an I / O intensive task.

[0041] The target task is determined to be an I / O intensive task when the following conditions are met: the blocking ratio is greater than the first preset ratio threshold, and at the same time the CPU ratio is less than the second preset ratio threshold.

[0042] The first and second preset percentage thresholds are pre-configured empirical parameters. In a typical setting, the first preset percentage threshold can be 0.6, and the second preset percentage threshold can be 0.2. This setting is based on the following principle: if the blocking time of a task within the sampling window exceeds 60%, while the CPU computation time is less than 20%, it indicates that the task spends most of its time waiting for external resources, with extremely low computational load, which is a typical characteristic of I / O intensive tasks.

[0043] It should be noted that the above thresholds (0.6 and 0.2) are only examples, and can be fine-tuned according to business scenarios in actual applications.

[0044] S102. Otherwise, determine whether the CPU percentage is greater than the third preset percentage threshold and the blocking percentage is less than the fourth preset percentage threshold. If yes, the task type of the target task is CPU intensive; otherwise, the task type of the target task is mixed.

[0045] If the conditions of step S101 above are not met (i.e., the blocking percentage is not greater than the first preset percentage threshold and the CPU percentage is not less than the second preset percentage threshold), then it is further determined whether the following conditions are met: the CPU percentage is greater than the third preset percentage threshold and the blocking percentage is less than the fourth preset percentage threshold.

[0046] If the above conditions are met, the target task is determined to be a CPU-intensive task. This condition means that the task consumes a high percentage of processor time within the sampling window (exceeding the third threshold), while the blocking / waiting time percentage is low (below the fourth threshold), indicating that the task primarily involves continuous computation and hardly waits for external resources—a typical characteristic of CPU-intensive tasks. In one exemplary setting, the third preset percentage threshold can be 0.7, and the fourth preset percentage threshold can be 0.1.

[0047] If the above conditions are also not met—that is, neither the I / O intensive condition nor the CPU intensive condition is satisfied—then the target task is determined to be a hybrid task. Hybrid tasks contain a certain proportion of computational operations and blocking / waiting operations, and cannot be clearly classified into the first two categories.

[0048] It should be noted that the specific values ​​of the third and fourth thresholds mentioned above (such as 0.7 and 0.1) are only examples and can be adjusted according to the characteristics of the business load in actual applications.

[0049] As an optional implementation method, Figure 3 This is a flowchart of the thread pool allocation method provided in an embodiment of the present invention, such as... Figure 3 As shown, the target task is assigned to the corresponding thread pool according to the task type, including: S201. When the target task is CPU-intensive, allocate it to the first thread pool.

[0050] S202. When the target task is IO-intensive or mixed, it is assigned to the second thread pool; where the first thread pool is the platform thread pool and the second thread pool is the virtual thread pool.

[0051] When a target task is determined to be CPU-intensive, it is assigned to the first thread pool for execution. The first thread pool is configured as a platform thread pool, a traditional thread pool composed of operating system kernel threads. Platform threads do not incur the overhead of virtual thread suspension and carrier switching when executing long-running computational tasks, enabling them to complete pure computational work more efficiently; therefore, they are suitable for handling CPU-intensive tasks.

[0052] When a target task is determined to be I / O intensive or mixed-type, it is assigned to the second thread pool for execution. The second thread pool is configured as a virtual thread pool, a lightweight thread pool built based on JDK virtual thread technology. Virtual threads can automatically yield the carrier thread when blocking and waiting (such as I / O or network requests), supporting massive concurrency with extremely low resource consumption. Therefore, it is suitable for handling I / O intensive tasks that are primarily waiting, as well as mixed-type tasks.

[0053] Create a dual-thread pool architecture using a hybrid thread pool builder (such as HybridExecutorBuilder), supporting custom parameter configuration and automatic parameter tuning.

[0054] In one exemplary configuration, the platform thread pool core thread count can be set to 4, and the maximum thread count can be set to 16. This configuration is based on the principle that the platform thread core count is close to the processor core count by default, and the maximum thread count does not exceed twice the processor core count, in order to balance the utilization of computing resources and context switching overhead.

[0055] The virtual thread pool and the platform thread pool maintain a default concurrency ratio, for example, a ratio of 16:1 between the number of virtual threads and the number of available platform threads. This ratio is the initial safe ratio recommended by the JDK, which can fully leverage the lightweight concurrency advantages of virtual threads while ensuring system stability.

[0056] To facilitate task submission, the hybrid thread pool provides two methods: one is specified type submission, where the caller explicitly declares the task type (CPU-intensive or I / O-intensive); the other is automatic identification submission, where the task type identification engine automatically determines the task type and allocates it to the corresponding thread pool.

[0057] As an optional implementation method, Figure 4 This is a flowchart of the resource configuration adjustment method provided in an embodiment of the present invention, such as... Figure 4 As shown, resource configuration adjustments for the thread pool are made based on load metrics, including: S301. When the queuing pressure of the second thread pool is greater than the first preset threshold and the resource utilization of the first thread pool is less than the second preset threshold, the number of platform threads in the first thread pool is increased.

[0058] When the queuing pressure of the second thread pool (virtual thread pool) is detected to be greater than the first preset threshold, and the resource utilization of the first thread pool (platform thread pool) is less than the second preset threshold, the number of platform threads in the first thread pool is automatically increased.

[0059] In this scenario, high queuing pressure in the virtual thread pool indicates a large number of I / O-intensive or mixed tasks awaiting execution. However, since virtual thread execution relies on platform threads as carriers, insufficient underlying platform threads prevent virtual threads from acquiring carrier resources in a timely manner, leading to queuing backlog. If the platform thread pool itself has low utilization (i.e., there are idle platform thread resources), increasing the number of threads in the platform thread pool can provide more carrier threads for the virtual thread pool, thereby alleviating the queuing pressure and improving overall throughput.

[0060] In one exemplary configuration, the first preset threshold can be set to 0.8 (indicating queuing pressure exceeding 80%), and the second preset threshold can be set to 0.3 (indicating resource utilization below 30%). Each time an adjustment is triggered, the increase in the number of platform threads can be dynamically determined based on the current queuing pressure level, for example, increasing the current number of threads by 10% each time or adding a fixed number of 2 threads. Meanwhile, to avoid frequent fluctuations, this adjustment is typically executed at a fixed period (e.g., every 10 seconds) and requires multiple consecutive fulfillments of the condition before triggering.

[0061] It should be noted that the first preset threshold, the second preset threshold, the increment of the number of threads, and the adjustment period can all be configured according to the actual deployment environment. This embodiment does not limit the specific values.

[0062] S302. Otherwise, determine whether the queuing pressure of the first thread pool is greater than the first preset threshold and the resource utilization of the second thread pool is less than the second preset threshold. If so, increase the ratio of the number of virtual threads in the second thread pool to the number of platform threads in the first thread pool.

[0063] If the condition in step S301 is not met (i.e., the second thread pool is not under high queuing pressure and the first thread pool is not idle), then it is further determined whether the following condition is met: the queuing pressure of the first thread pool (platform thread pool) is greater than the first preset threshold, and the resource utilization rate of the second thread pool (virtual thread pool) is less than the second preset threshold. If this condition is met, then the ratio of the number of virtual threads in the second thread pool to the number of platform threads in the first thread pool is increased.

[0064] In this scenario, the high queuing pressure in the platform thread pool indicates a backlog of CPU-intensive tasks requiring more platform thread resources for processing. Meanwhile, the low resource utilization of the virtual thread pool suggests fewer I / O-intensive or mixed-type tasks, meaning the existing concurrent capacity of the virtual thread pool is not being fully utilized. Increasing the ratio of virtual threads to platform threads allows each platform thread to handle more virtual threads, freeing up the platform thread pool's processing capacity to handle CPU-intensive tasks, while maintaining the same number of platform threads.

[0065] In one exemplary configuration, the first preset threshold can be set to 0.8, and the second preset threshold can be set to 0.3. The initial ratio of virtual threads to platform threads can be set to 16:1 (the safe ratio recommended by the JDK). When this adjustment is triggered, the ratio can be increased to 32:1, 64:1, etc., until the preset upper limit (e.g., 128:1) is reached. The ratio can be increased gradually or adjusted to a higher level all at once according to the current queuing pressure.

[0066] It should be noted that the first preset threshold, the second preset threshold, the initial ratio, and the step size for each adjustment can be flexibly configured according to the actual business load and hardware environment. This embodiment does not impose a unique limitation on specific values. Furthermore, to avoid parameter fluctuations, this adjustment is typically performed at a fixed period and is only triggered after the conditions are met multiple times consecutively.

[0067] S303. If not, determine whether the throughput decline rate is greater than the third preset threshold. If yes, roll back to the previous resource configuration; if no, maintain the current resource configuration.

[0068] If neither of the conditions in steps S301 nor S302 is met, i.e. there is no situation where one thread pool is under high queuing pressure and the other thread pool is idle, then it is necessary to further determine whether the overall throughput decline rate is greater than the third preset threshold.

[0069] Throughput measures the ability of a thread pool to process tasks per unit of time, typically expressed as the number of tasks completed per second or the request processing rate. The average throughput for each period is calculated by counting the total number of tasks completed within each data collection cycle and dividing that number by the cycle duration (e.g., 10 seconds).

[0070] The throughput decline rate can be obtained by subtracting the throughput of the current period from the throughput of the previous period, and then dividing the difference by the throughput of the previous period.

[0071] If the throughput decline rate exceeds the third preset threshold, it indicates a significant drop in processing capacity in the recent period, possibly due to excessive or unsuitable adjustments to the previous resource configuration. In this case, a rollback operation is performed to restore the resource configuration to its state before the last adjustment (i.e., the previous resource configuration).

[0072] If the throughput decline rate does not exceed the third preset threshold, it means that the current resource configuration can maintain an acceptable performance level and no adjustment is needed. Therefore, the current resource configuration should remain unchanged.

[0073] In one exemplary configuration, the third preset threshold can be set to 5% (i.e., triggering a rollback when the throughput decline rate exceeds 5%). The throughput decline rate can be calculated using a sliding window approach, comparing the task completion rate or processing volume per unit time of the current window with the previous window (or stable baseline window). The rollback operation can be a gradual rollback (e.g., rolling back 50% of the previous adjustment each time) or a one-time restoration to the previous stable configuration; the specific strategy can be set according to actual needs.

[0074] It should be noted that the value of the third preset threshold, the length of the time window for throughput statistics, and the specific method of rollback can all be flexibly configured according to the business scenario and system requirements. This embodiment does not impose a unique limitation on them.

[0075] As an optional implementation method, Figure 5 This is a flowchart of the task migration method provided in an embodiment of the present invention, such as... Figure 5 As shown, task migration for the thread pool is performed based on load metrics, including: S304. When the queuing pressure of the second thread pool is greater than the fourth preset threshold and the resource utilization of the first thread pool is less than the fifth preset threshold, a preset number of CPU-intensive tasks are selected from the execution queue of the second thread pool as tasks to be migrated.

[0076] When the queuing pressure of the second thread pool (virtual thread pool) is detected to be greater than the fourth preset threshold, and the resource utilization of the first thread pool (platform thread pool) is less than the fifth preset threshold, a preset number of CPU-intensive tasks are selected from the execution queue of the second thread pool as tasks to be migrated.

[0077] Under these conditions, excessive queuing pressure in the virtual thread pool indicates a backlog of tasks awaiting execution, which may include some CPU-intensive tasks (e.g., those arising from identification errors or characteristic changes during the execution of mixed tasks). In this case, if the platform thread pool is relatively idle, migrating these CPU-intensive tasks from the virtual thread pool to the platform thread pool can alleviate the queuing pressure in the virtual thread pool and improve the processing efficiency of CPU-intensive tasks by utilizing idle platform thread resources.

[0078] In one exemplary configuration, the fourth preset threshold can be set to 0.9 (indicating queuing pressure exceeding 90%), and the fifth preset threshold can be set to 0.5 (indicating resource utilization below 50%). The preset numbers can be set according to actual needs, for example, migrating a maximum of 10 tasks at a time to avoid instantaneous overload of the platform thread pool due to migrating too many tasks at once.

[0079] Furthermore, to ensure business security, the tasks to be migrated should be interruptible and stateless to avoid compromising task consistency during the migration process. Tasks eligible for migration can be filtered using tags in the task metadata, such as "stateless".

[0080] It should be noted that the fourth preset threshold, the fifth preset threshold, the upper limit of the number of migrations per time, and the migration conditions of the task can all be flexibly configured according to actual business needs, and this embodiment does not limit them to a single one.

[0081] S305. Migrate the task to be migrated to the first thread pool.

[0082] The selected tasks to be migrated are taken from the execution queue of the second thread pool and resubmitted to the first thread pool for execution. After the migration is complete, the first thread pool will process these CPU-intensive tasks according to its scheduling policy, while the corresponding tasks in the execution queue of the second thread pool are removed, thereby reducing queuing pressure.

[0083] This invention also provides an adaptive dynamic orchestration system for hybrid thread pools. Figure 6 This is a schematic diagram of the structure of the adaptive dynamic orchestration system for hybrid thread pools provided in an embodiment of the present invention, as shown below. Figure 6 As shown, the system includes: The classification module 100 is used to statistically analyze the execution characteristics of the target task within a preset sampling window and determine the task type of the target task based on the execution characteristics.

[0084] After a thread task is submitted, a preset sampling window (e.g., 5ms) is started. Within this sampling window, the execution characteristic data of the target task during execution is collected. These execution characteristics can distinguish the degree of dependence of the task on computing resources and waiting resources, such as the characteristic indicators of the task consuming processor resources and the characteristic indicators of the task being blocked due to waiting for external resources (such as I / O, network, locks).

[0085] Using the thread monitoring APIs provided by JDK 25 (such as Thread.getTotalCpuTime() and Thread.getBlockedTime()), one or more execution characteristic data of the target task are collected within the sampling window. Then, based on the collected characteristic data and combined with pre-defined classification rules (such as judgment logic based on feature thresholds or classification strategies based on statistical models), the target task is automatically mapped to a certain category among the predefined task types in the classification rules.

[0086] The thread pool allocation module 200 is used to allocate target tasks to the corresponding thread pools according to task type.

[0087] The system has several pre-configured thread pools, each with different execution characteristics (e.g., some thread pools are suitable for handling computationally intensive tasks, while others are suitable for handling waiting-intensive tasks). By establishing a mapping relationship between task types and thread pools, each type of task can be assigned to the thread pool that best matches its resource requirements.

[0088] Regarding the specific implementation of the mapping, static rules (such as a one-to-one correspondence between type and thread pool) can be used, or dynamic strategies (such as adjusting the mapping based on real-time load) can be introduced. In one feasible solution, a fixed type-thread pool mapping table is used, and the target thread pool is directly selected based on the identified type.

[0089] The adaptive adjustment module 300 is used to monitor the load metrics of all thread pools in real time, and adjust the resource configuration of the thread pools and / or migrate tasks based on the load metrics.

[0090] During task execution, the load status of all thread pools is monitored in real time, and indicators that reflect the busy or idle status of each thread pool are collected, such as task queue length, thread utilization, and average response time.

[0091] Based on the collected load metrics, the system dynamically determines whether there are resource bottlenecks or waste in each thread pool. When one thread pool is overloaded (e.g., due to severe task backlog) while another thread pool is relatively idle, an adaptive adjustment operation is automatically triggered. The adjustment operation includes resource configuration adjustments and / or task migration.

[0092] Resource configuration adjustment refers to changing the internal capacity parameters of a thread pool, such as increasing or decreasing the number of threads or adjusting the ratio between virtual threads and carrier resources, in order to improve the processing capacity of the target thread pool or release idle resources.

[0093] Task migration refers to transferring tasks to be executed from one thread pool to another, thereby achieving cross-pool load balancing, alleviating queuing pressure in the source thread pool, and improving the resource utilization of the target thread pool.

[0094] The triggering conditions and specific execution strategies for the above adjustment operations can be implemented in various ways, such as threshold-based rules, prediction models based on historical data, or closed-loop feedback control.

[0095] As an optional implementation method, the execution characteristics include: CPU usage and blocking usage.

[0096] CPU utilization refers to the ratio of processor time consumed by the target task within the sampling window to the total duration of the window, reflecting the intensity of the task's utilization of computing resources; blocking utilization refers to the ratio of the time the target task is blocked due to waiting for external resources (such as I / O, locks, network responses) to the total duration of the window, reflecting the degree of dependence of the task on waiting resources.

[0097] As an optional implementation method, Figure 7 This is a structural diagram of the classification module provided in an embodiment of the present invention, as shown below. Figure 7 As shown, the classification module 100 includes: The first determination submodule 1001 is used to determine that the task type of the target task is IO intensive if the blocking ratio is greater than the first preset ratio threshold and the CPU ratio is less than the second preset ratio threshold.

[0098] The target task is determined to be an I / O intensive task when the following conditions are met: the blocking ratio is greater than the first preset ratio threshold, and at the same time the CPU ratio is less than the second preset ratio threshold.

[0099] The first and second preset percentage thresholds are pre-configured empirical parameters. In a typical setting, the first preset percentage threshold can be 0.6, and the second preset percentage threshold can be 0.2. This setting is based on the following principle: if the blocking time of a task within the sampling window exceeds 60%, while the CPU computation time is less than 20%, it indicates that the task spends most of its time waiting for external resources, with extremely low computational load, which is a typical characteristic of I / O intensive tasks.

[0100] It should be noted that the above thresholds (0.6 and 0.2) are only examples, and can be fine-tuned according to business scenarios in actual applications.

[0101] The second determination submodule 1002 is used to determine whether the CPU percentage is greater than the third preset percentage threshold and the blocking percentage is less than the fourth preset percentage threshold when the conditions of the first determination submodule are not met. If so, the task type of the target task is CPU intensive; otherwise, the task type of the target task is mixed.

[0102] If the conditions of the first determination submodule are not met (i.e., the blocking percentage is not greater than the first preset percentage threshold and the CPU percentage is not less than the second preset percentage threshold), then it is further determined whether the following conditions are met: the CPU percentage is greater than the third preset percentage threshold and the blocking percentage is less than the fourth preset percentage threshold.

[0103] If the above conditions are met, the target task is determined to be a CPU-intensive task. This condition means that the task consumes a high percentage of processor time within the sampling window (exceeding the third threshold), while the blocking / waiting time percentage is low (below the fourth threshold), indicating that the task primarily involves continuous computation and hardly waits for external resources—a typical characteristic of CPU-intensive tasks. In one exemplary setting, the third preset percentage threshold can be 0.7, and the fourth preset percentage threshold can be 0.1.

[0104] If the above conditions are also not met—that is, neither the I / O intensive condition nor the CPU intensive condition is satisfied—then the target task is determined to be a hybrid task. Hybrid tasks contain a certain proportion of computational operations and blocking / waiting operations, and cannot be clearly classified into the first two categories.

[0105] It should be noted that the specific values ​​of the third and fourth thresholds mentioned above (such as 0.7 and 0.1) are only examples and can be adjusted according to the characteristics of the business load in actual applications.

[0106] As an optional implementation method, Figure 8 This is a structural diagram of the thread pool allocation module provided in an embodiment of the present invention, as shown below. Figure 8 As shown, the thread pool allocation module 200 includes: The first allocation submodule 2001 is used to allocate the target task to the first thread pool when the task type of the target task is CPU intensive.

[0107] The second allocation submodule 2002 is used to allocate the target task to the second thread pool when the task type is IO intensive or mixed; wherein the first thread pool is the platform thread pool and the second thread pool is the virtual thread pool.

[0108] When a target task is determined to be CPU-intensive, it is assigned to the first thread pool for execution. The first thread pool is configured as a platform thread pool, a traditional thread pool composed of operating system kernel threads. Platform threads do not incur the overhead of virtual thread suspension and carrier switching when executing long-running computational tasks, enabling them to complete pure computational work more efficiently; therefore, they are suitable for handling CPU-intensive tasks.

[0109] When a target task is determined to be I / O intensive or mixed-type, it is assigned to the second thread pool for execution. The second thread pool is configured as a virtual thread pool, a lightweight thread pool built based on JDK virtual thread technology. Virtual threads can automatically yield the carrier thread when blocking and waiting (such as I / O or network requests), supporting massive concurrency with extremely low resource consumption. Therefore, it is suitable for handling I / O intensive tasks that are primarily waiting, as well as mixed-type tasks.

[0110] Create a dual-thread pool architecture using a hybrid thread pool builder (such as HybridExecutorBuilder), supporting custom parameter configuration and automatic parameter tuning.

[0111] In one exemplary configuration, the platform thread pool core thread count can be set to 4, and the maximum thread count can be set to 16. This configuration is based on the principle that the platform thread core count is close to the processor core count by default, and the maximum thread count does not exceed twice the processor core count, in order to balance the utilization of computing resources and context switching overhead.

[0112] The virtual thread pool and the platform thread pool maintain a default concurrency ratio, for example, a ratio of 16:1 between the number of virtual threads and the number of available platform threads. This ratio is the initial safe ratio recommended by the JDK, which can fully leverage the lightweight concurrency advantages of virtual threads while ensuring system stability.

[0113] To facilitate task submission, the hybrid thread pool provides two methods: one is specified type submission, where the caller explicitly declares the task type (CPU-intensive or I / O-intensive); the other is automatic identification submission, where the task type identification engine automatically determines the task type and allocates it to the corresponding thread pool.

[0114] As an optional implementation method, Figure 9 This is a schematic diagram of the structure of the adaptive adjustment module for the resource configuration adjustment submodule provided in this embodiment of the invention, as shown below. Figure 9 As shown, the adaptive adjustment module 300 includes: The first configuration adjustment submodule 3001 is used to increase the number of platform threads in the first thread pool when the queuing pressure of the second thread pool is greater than the first preset threshold and the resource utilization of the first thread pool is less than the second preset threshold.

[0115] When the queuing pressure of the second thread pool (virtual thread pool) is detected to be greater than the first preset threshold, and the resource utilization of the first thread pool (platform thread pool) is less than the second preset threshold, the number of platform threads in the first thread pool is automatically increased.

[0116] In this scenario, high queuing pressure in the virtual thread pool indicates a large number of I / O-intensive or mixed tasks awaiting execution. However, since virtual thread execution relies on platform threads as carriers, insufficient underlying platform threads prevent virtual threads from acquiring carrier resources in a timely manner, leading to queuing backlog. If the platform thread pool itself has low utilization (i.e., there are idle platform thread resources), increasing the number of threads in the platform thread pool can provide more carrier threads for the virtual thread pool, thereby alleviating the queuing pressure and improving overall throughput.

[0117] In one exemplary configuration, the first preset threshold can be set to 0.8 (indicating queuing pressure exceeding 80%), and the second preset threshold can be set to 0.3 (indicating resource utilization below 30%). Each time an adjustment is triggered, the increase in the number of platform threads can be dynamically determined based on the current queuing pressure level, for example, increasing the current number of threads by 10% each time or adding a fixed number of 2 threads. Meanwhile, to avoid frequent fluctuations, this adjustment is typically executed at a fixed period (e.g., every 10 seconds) and requires multiple consecutive fulfillments of the condition before triggering.

[0118] It should be noted that the first preset threshold, the second preset threshold, the increment of the number of threads, and the adjustment period can all be configured according to the actual deployment environment. This embodiment does not limit the specific values.

[0119] The second configuration adjustment submodule 3002 is used to determine whether the queuing pressure of the first thread pool is greater than the first preset threshold and the resource utilization of the second thread pool is less than the second preset threshold when the conditions of the first configuration adjustment submodule are not met. If so, the ratio of the number of virtual threads in the second thread pool to the number of platform threads in the first thread pool is increased.

[0120] If the conditions of the first configuration adjustment submodule are not met (i.e., the second thread pool is not under high queuing pressure and the first thread pool is not idle), then it is further determined whether the following conditions are met: the queuing pressure of the first thread pool (platform thread pool) is greater than the first preset threshold, and the resource utilization of the second thread pool (virtual thread pool) is less than the second preset threshold. If this condition is met, then the ratio of the number of virtual threads in the second thread pool to the number of platform threads in the first thread pool is increased.

[0121] In this scenario, the high queuing pressure in the platform thread pool indicates a backlog of CPU-intensive tasks requiring more platform thread resources for processing. Meanwhile, the low resource utilization of the virtual thread pool suggests fewer I / O-intensive or mixed-type tasks, meaning the existing concurrent capacity of the virtual thread pool is not being fully utilized. Increasing the ratio of virtual threads to platform threads allows each platform thread to handle more virtual threads, freeing up the platform thread pool's processing capacity to handle CPU-intensive tasks, while maintaining the same number of platform threads.

[0122] In one exemplary configuration, the first preset threshold can be set to 0.8, and the second preset threshold can be set to 0.3. The initial ratio of virtual threads to platform threads can be set to 16:1 (the safe ratio recommended by the JDK). When this adjustment is triggered, the ratio can be increased to 32:1, 64:1, etc., until the preset upper limit (e.g., 128:1) is reached. The ratio can be increased gradually or adjusted to a higher level all at once according to the current queuing pressure.

[0123] It should be noted that the first preset threshold, the second preset threshold, the initial ratio, and the step size for each adjustment can be flexibly configured according to the actual business load and hardware environment. This embodiment does not impose a unique limitation on specific values. Furthermore, to avoid parameter fluctuations, this adjustment is typically performed at a fixed period and is only triggered after the conditions are met multiple times consecutively.

[0124] The third configuration adjustment submodule 3003 is used to determine whether the throughput decrease rate is greater than a third preset threshold when the conditions of the first configuration adjustment submodule and the second configuration adjustment submodule are not met. If yes, it rolls back to the previous resource configuration; otherwise, it keeps the current resource configuration.

[0125] If neither the conditions of the first configuration adjustment submodule nor the second configuration adjustment submodule are met, that is, there is no situation where one thread pool is under high queuing pressure and the other thread pool is idle, then it is necessary to further determine whether the overall throughput decline rate is greater than the third preset threshold.

[0126] Throughput measures the ability of a thread pool to process tasks per unit of time, typically expressed as the number of tasks completed per second or the request processing rate. The average throughput for each period is calculated by counting the total number of tasks completed within each data collection cycle and dividing that number by the cycle duration (e.g., 10 seconds).

[0127] The throughput decline rate can be obtained by subtracting the throughput of the current period from the throughput of the previous period, and then dividing the difference by the throughput of the previous period.

[0128] If the throughput decline rate exceeds the third preset threshold, it indicates a significant drop in processing capacity in the recent period, possibly due to excessive or unsuitable adjustments to the previous resource configuration. In this case, a rollback operation is performed to restore the resource configuration to its state before the last adjustment (i.e., the previous resource configuration).

[0129] If the throughput decline rate does not exceed the third preset threshold, it means that the current resource configuration can maintain an acceptable performance level and no adjustment is needed. Therefore, the current resource configuration should remain unchanged.

[0130] In one exemplary configuration, the third preset threshold can be set to 5% (i.e., triggering a rollback when the throughput decline rate exceeds 5%). The throughput decline rate can be calculated using a sliding window approach, comparing the task completion rate or processing volume per unit time of the current window with the previous window (or stable baseline window). The rollback operation can be a gradual rollback (e.g., rolling back 50% of the previous adjustment each time) or a one-time restoration to the previous stable configuration; the specific strategy can be set according to actual needs.

[0131] It should be noted that the value of the third preset threshold, the length of the time window for throughput statistics, and the specific method of rollback can all be flexibly configured according to the business scenario and system requirements. This embodiment does not impose a unique limitation on them.

[0132] As an optional implementation method, Figure 10 This is a schematic diagram of the adaptive adjustment module used in the task migration submodule according to an embodiment of the present invention, as shown below. Figure 10 As shown, the adaptive adjustment module 300 also includes: The task to be migrated submodule 3004 is used to select a preset number of CPU-intensive tasks as tasks to be migrated from the execution queue of the second thread pool when the queuing pressure of the second thread pool is greater than the fourth preset threshold and the resource utilization of the first thread pool is less than the fifth preset threshold.

[0133] When the queuing pressure of the second thread pool (virtual thread pool) is detected to be greater than the fourth preset threshold, and the resource utilization of the first thread pool (platform thread pool) is less than the fifth preset threshold, a preset number of CPU-intensive tasks are selected from the execution queue of the second thread pool as tasks to be migrated.

[0134] Under these conditions, excessive queuing pressure in the virtual thread pool indicates a backlog of tasks awaiting execution, which may include some CPU-intensive tasks (e.g., those arising from identification errors or characteristic changes during the execution of mixed tasks). In this case, if the platform thread pool is relatively idle, migrating these CPU-intensive tasks from the virtual thread pool to the platform thread pool can alleviate the queuing pressure in the virtual thread pool and improve the processing efficiency of CPU-intensive tasks by utilizing idle platform thread resources.

[0135] In one exemplary configuration, the fourth preset threshold can be set to 0.9 (indicating queuing pressure exceeding 90%), and the fifth preset threshold can be set to 0.5 (indicating resource utilization below 50%). The preset numbers can be set according to actual needs, for example, migrating a maximum of 10 tasks at a time to avoid instantaneous overload of the platform thread pool due to migrating too many tasks at once.

[0136] Furthermore, to ensure business security, the tasks to be migrated should be interruptible and stateless to avoid compromising task consistency during the migration process. Tasks eligible for migration can be filtered using tags in the task metadata, such as "stateless".

[0137] It should be noted that the fourth preset threshold, the fifth preset threshold, the upper limit of the number of migrations per time, and the migration conditions of the task can all be flexibly configured according to actual business needs, and this embodiment does not limit them to a single one.

[0138] The task migration submodule 3005 is used to migrate tasks to the first thread pool.

[0139] The selected tasks to be migrated are taken from the execution queue of the second thread pool and resubmitted to the first thread pool for execution. After the migration is complete, the first thread pool will process these CPU-intensive tasks according to its scheduling policy, while the corresponding tasks in the execution queue of the second thread pool are removed, thereby reducing queuing pressure.

[0140] The above technical solution has the following beneficial effects: By allocating CPU-intensive tasks to the platform thread pool and I / O-intensive tasks to the virtual thread pool, the additional overhead of virtual threads executing CPU-intensive tasks is avoided, improving the execution efficiency of CPU-intensive tasks and the concurrency capability of I / O-intensive tasks; by monitoring the load in real time and dynamically adjusting resource configuration or migrating tasks, resource exhaustion caused by virtual thread queuing under extreme high concurrency is avoided, thus enhancing system stability; by providing a standardized adaptive hybrid scheduling framework, the development threshold is lowered and the amount of custom scheduling code written is reduced; by automatically adjusting thread pool resources according to load indicators, the system can smoothly adapt to the dynamic changes in business load without manual parameter tuning, achieving adaptive optimization.

[0141] The above-described specific embodiments of the invention further illustrate the purpose, technical solution, and beneficial effects of the invention. It should be understood that the above content is only for specific embodiments of the invention and is not intended to limit the scope of protection of the invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the invention should be included within the scope of protection of the invention.

Claims

1. An adaptive dynamic orchestration method of a hybrid thread pool, characterized in that, include: Within a preset sampling window, the execution characteristics of the target task are statistically analyzed, and the task type of the target task is determined based on the execution characteristics. The target task is assigned to the corresponding thread pool according to the task type. Monitor the load metrics of all thread pools in real time, and adjust the resource configuration of the thread pools and / or migrate tasks based on the load metrics.

2. The adaptive dynamic orchestration method of hybrid thread pool according to claim 1, characterized in that, The execution characteristics include: CPU usage and blocking usage; The step of determining the task type of the target task based on the execution characteristics includes: If the blocking percentage is greater than a first preset percentage threshold and the CPU percentage is less than a second preset percentage threshold, then the target task is determined to be an I / O intensive task. Otherwise, determine whether the CPU percentage is greater than the third preset percentage threshold and the blocking percentage is less than the fourth preset percentage threshold. If yes, the task type of the target task is CPU intensive; otherwise, the task type of the target task is mixed.

3. The adaptive dynamic orchestration method of hybrid thread pool according to claim 2, characterized in that, Assigning the target task to the corresponding thread pool according to the task type includes: When the target task is CPU-intensive, it is assigned to the first thread pool; When the target task is of I / O intensive or mixed type, it is assigned to the second thread pool; wherein the first thread pool is the platform thread pool and the second thread pool is the virtual thread pool.

4. The adaptive dynamic orchestration method for hybrid thread pools according to claim 3, characterized in that, The step of adjusting the resource configuration of the thread pool based on the load metric includes: When the queuing pressure of the second thread pool is greater than the first preset threshold and the resource utilization of the first thread pool is less than the second preset threshold, the number of platform threads in the first thread pool is increased. Otherwise, determine whether the queuing pressure of the first thread pool is greater than the first preset threshold and the resource utilization of the second thread pool is less than the second preset threshold. If so, increase the ratio of the number of virtual threads in the second thread pool to the number of platform threads in the first thread pool. If not, determine whether the throughput decline rate is greater than the third preset threshold. If yes, roll back to the previous resource configuration; otherwise, maintain the current resource configuration.

5. The adaptive dynamic orchestration method for hybrid thread pools according to claim 3, characterized in that, The step of migrating tasks to the thread pool based on the load metrics includes: When the queuing pressure of the second thread pool is greater than the fourth preset threshold and the resource utilization of the first thread pool is less than the fifth preset threshold, a preset number of CPU-intensive tasks are selected from the execution queue of the second thread pool as tasks to be migrated. The task to be migrated is migrated to the first thread pool.

6. An adaptive dynamic orchestration system for hybrid thread pools, characterized in that, include: The classification module is used to statistically analyze the execution characteristics of a target task within a preset sampling window, and determine the task type of the target task based on the execution characteristics. The thread pool allocation module is used to allocate the target task to the corresponding thread pool according to the task type. The adaptive adjustment module is used to monitor the load metrics of all thread pools in real time, and adjust the resource configuration of the thread pools and / or migrate tasks based on the load metrics.

7. The adaptive dynamic orchestration system for hybrid thread pools according to claim 6, characterized in that, The execution characteristics include: CPU usage and blocking usage; The classification module includes: The first determination submodule is used to determine that the task type of the target task is IO intensive if the blocking ratio is greater than a first preset ratio threshold and the CPU ratio is less than a second preset ratio threshold. The second determination submodule is used to determine whether the CPU percentage is greater than the third preset percentage threshold and the blocking percentage is less than the fourth preset percentage threshold when the conditions of the first determination submodule are not met. If so, the task type of the target task is CPU intensive; otherwise, the task type of the target task is mixed.

8. The adaptive dynamic orchestration system for hybrid thread pools according to claim 7, characterized in that, The thread pool allocation module includes: The first allocation submodule is used to allocate the target task to the first thread pool when the task type is CPU intensive. The second allocation submodule is used to allocate the target task to the second thread pool when the task type is IO intensive or mixed; wherein the first thread pool is the platform thread pool and the second thread pool is the virtual thread pool.

9. The adaptive dynamic orchestration system for hybrid thread pools according to claim 8, characterized in that, The adaptive adjustment module includes: The first configuration adjustment submodule is used to increase the number of platform threads in the first thread pool when the queuing pressure of the second thread pool is greater than the first preset threshold and the resource utilization of the first thread pool is less than the second preset threshold. The second configuration adjustment submodule is used to determine whether the queuing pressure of the first thread pool is greater than the first preset threshold and the resource utilization of the second thread pool is less than the second preset threshold when the conditions of the first configuration adjustment submodule are not met. If so, the ratio of the number of virtual threads in the second thread pool to the number of platform threads in the first thread pool is increased. The third configuration adjustment submodule is used to determine whether the throughput decline rate is greater than a third preset threshold when the conditions of the first configuration adjustment submodule and the second configuration adjustment submodule are not met. If yes, it rolls back to the previous resource configuration; otherwise, it keeps the current resource configuration.

10. The adaptive dynamic orchestration system for hybrid thread pools according to claim 8, characterized in that, The adaptive adjustment module further includes: The task to be migrated submodule is used to select a preset number of CPU-intensive tasks as tasks to be migrated from the execution queue of the second thread pool when the queuing pressure of the second thread pool is greater than the fourth preset threshold and the resource utilization of the first thread pool is less than the fifth preset threshold. The task migration submodule is used to migrate the task to be migrated to the first thread pool.

Images