Method and system for realizing dynamic thread pool based on Agent

Abstract

The invention discloses a method and system for realizing a dynamic thread pool based on Agent, and relates to the technical field of thread pools, and the method comprises the following steps: collecting internal operation state data of a task execution module and resource use data of a host machine through an environment perception module, and generating a system state snapshot; the central decision-making agent receives the snapshot and generates an adjustment instruction based on a built-in mixed decision-making model; the dynamic actuator module executes the instruction to modify operating parameters of the task execution module. According to the method, closed-loop dynamic control over the thread pool parameters is achieved, key configurations such as the core thread count and the maximum thread count can be adaptively adjusted according to real-time loads and resource conditions, the problems that static configuration resources are rigid and manual adjustment and optimization are difficult are solved, and the system resource utilization rate, the response capacity and the overall stability are improved.

Description

Technical Field

[0001] This invention relates to the field of thread pool technology, and in particular to a method and system for implementing a dynamic thread pool based on an agent. Background Technology

[0002] In modern high-concurrency and high-performance software systems, thread pools reuse pre-created threads to execute tasks, effectively avoiding the system overhead caused by frequent thread creation and destruction, thereby significantly improving system responsiveness, throughput, and resource utilization. The core parameters of a thread pool are typically set statically during initialization and remain fixed during subsequent operation.

[0003] However, in real-world production environments, system loads often exhibit complex and fluctuating peak-and-trough characteristics, gradually revealing the inherent limitations of this static configuration model. On one hand, fixed parameter configurations cannot flexibly adapt to dynamically changing loads. During low-load periods, too many core threads remain idle, leading to wasted CPU and memory resources; while during high-load periods, the limited maximum number of threads and queue capacity can easily cause severe task backlog, degrading response time and potentially triggering system memory overflow or service avalanche. Furthermore, to achieve optimal performance, operations personnel must rely on experience-based predictions and extensive stress testing to manually adjust parameters—a tedious, time-consuming process requiring advanced expertise. Once the system's business model or operating environment changes, the original configuration may quickly become invalid, necessitating manual re-tuning and resulting in high operational costs. Moreover, traditional thread pools are essentially passive task execution frameworks, lacking awareness of their internal operating status (such as queue backlog and task processing efficiency) and external system environment (such as overall CPU load and memory utilization), thus preventing them from making autonomous decisions and adjusting parameters based on this information. Summary of the Invention

[0004] This invention provides a method and system for implementing a dynamic thread pool based on an agent. The technical problem it aims to solve is: how to provide a comprehensive technical solution that can perceive the internal and external states of the system in real time and autonomously and intelligently adjust the key parameters of the thread pool to achieve efficient resource utilization and continuous performance optimization.

[0005] In a first aspect, embodiments of the present invention provide a method for implementing a dynamic thread pool based on an agent, applied to a dynamic thread pool system. The dynamic thread pool system includes a task execution module, an environment awareness module connected to the task execution module, a central decision-making agent connected to the environment awareness module, and a dynamic executor module connected to the central decision-making agent and the task execution module. The method includes: The environmental perception module collects internal operating status data of the task execution module and resource usage data of the host machine where the task execution module is located. A system status snapshot is generated based on the internal operating status data and the resource usage data; The system state snapshot is input into the central decision-making agent, which then generates adjustment instructions for the operating parameters of the task execution module. The adjustment instructions are executed by the dynamic executor module to modify the operating parameters of the task execution module.

[0006] Optionally, the step of generating adjustment instructions for the operating parameters of the task execution module through the central decision-making agent includes: The system state snapshot is input into the rule engine built into the central decision-making agent for matching; If the system state snapshot matches a preset high-priority rule, the adjustment instruction is generated based on the matched high-priority rule; If the system state snapshot does not match a high-priority rule, the system state snapshot is input into the reinforcement learning model built into the central decision-making agent. The reinforcement learning model outputs a recommended action and generates the adjustment instruction based on the recommended action.

[0007] Optionally, the construction and application of the reinforcement learning model includes the following steps: The system state snapshot is used as the state space of the reinforcement learning model; The action space of the reinforcement learning model is defined by adjusting the core thread count, maximum thread count, and work queue capacity of the task execution module. The reward function of the reinforcement learning model is constructed based on at least one of the following performance metrics: average task latency, system throughput, CPU utilization, and memory utilization. During the operation of the reinforcement learning model, the reward value obtained after executing the adjustment instruction is calculated according to the reward function.

[0008] Optionally, it also includes: Collect training data, which includes the system state snapshot, adjustment instructions generated based on the snapshot, a new system state snapshot obtained after executing the instructions, and a calculated reward value. The training data is stored in a preset experience playback buffer. Training data is periodically sampled from the experience replay buffer; The parameters of the reinforcement learning model are updated using the training data.

[0009] Optionally, when the adjustment instruction indicates a reduction in the number of core threads, executing the adjustment instruction through the dynamic executor module to modify the operating parameters of the task execution module includes: Enable the core thread idle timeout function of the task execution module; Calculate the new number of core threads based on the adjustment instructions; Any excess threads whose current core thread count exceeds the new core thread count will automatically terminate after their idle time reaches a preset timeout threshold.

[0010] Optionally, the task execution module uses a dynamically adjustable blocking queue as a work queue; the step of executing the adjustment instruction through the dynamic executor module to modify the operating parameters of the task execution module includes: Calculate the new queue capacity value based on the adjustment content regarding the work queue capacity in the adjustment instruction; Modify the upper limit of the blocked queue to the new queue capacity value.

[0011] Optionally, the dynamic thread pool system further includes a cooperative communication bus connected to the central decision-making agent; the method further includes: Through the cooperative communication bus, the load status information obtained by the central decision-making agent of this dynamic thread pool system is sent to the central decision-making agent of other dynamic thread pool systems. Through the cooperative communication bus, load status information sent by the central decision-making agent of other dynamic thread pool systems is received; Based on the received load status information and the status of this dynamic thread pool system, cooperative control instructions involving task routing or load sharing are generated.

[0012] Secondly, embodiments of the present invention propose a dynamic thread pool system for implementing the method described in the first aspect, including: The task execution module is used to receive and execute externally submitted tasks and output the internal running status data of the thread pool. An environment awareness module, connected to the task execution module, is used to collect internal operating status data output by the task execution module and resource usage data of the host machine, and generate a system status snapshot based on the collected data. A central decision-making intelligent agent, connected to the environmental perception module, is used to receive the system state snapshot and generate adjustment instructions for the operating parameters of the task execution module based on the built-in hybrid decision model. The dynamic executor module, connected to the central decision-making agent and the task execution module, is used to receive the adjustment instructions and modify the operating parameters of the task execution module according to the adjustment instructions.

[0013] Optionally, the hybrid decision-making model built into the central decision-making agent includes a rule engine and a reinforcement learning model.

[0014] Optionally, it also includes a collaborative communication bus; the collaborative communication bus is connected to the central decision-making agent and is used to transmit load status information among the central decision-making agents of multiple dynamic thread pool systems.

[0015] This invention provides a method and system for implementing a dynamic thread pool based on an agent. The method includes: collecting internal operating status data of a task execution module and resource usage data of the host machine where the task execution module resides through an environment awareness module; generating a system status snapshot based on the internal operating status data and the resource usage data; inputting the system status snapshot into a central decision-making agent, which generates adjustment instructions for the operating parameters of the task execution module; and executing the adjustment instructions through a dynamic executor module to modify the operating parameters of the task execution module. This invention effectively overcomes the rigid resource allocation problem caused by static parameter configuration in traditional thread pools by constructing an automated closed-loop system including awareness, decision-making, and execution stages. Specifically, by continuously collecting the internal operating status of the thread pool and host machine resource usage data, a status snapshot reflecting the overall system load is generated in real time; then, parameter adjustment instructions are automatically generated based on this status snapshot, driving the execution unit to dynamically modify the core parameters of the thread pool. This process enables the critical configuration of the thread pool to adaptively adjust to changes in actual load and resource conditions without relying on manual prediction and intervention. This significantly improves the system's resource utilization efficiency, responsiveness, and overall stability under high concurrency and fluctuating load scenarios, while reducing operational complexity and costs. Attached Figure Description

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

[0017] Figure 1 This is a flowchart illustrating a method for implementing a dynamic thread pool based on an agent, as provided in an embodiment of the present invention. Figure 2 This is a structural block diagram of a dynamic thread pool system provided in an embodiment of the present invention. Detailed Implementation

[0018] 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, not all, of the embodiments of the present invention. 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.

[0019] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0020] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0021] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0022] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0023] See Figure 2 This invention provides a dynamic thread pool system for implementing an agent-based dynamic thread pool method proposed in this invention, comprising: The task execution module 10 is used to receive and execute externally submitted tasks and output the internal running status data of the thread pool.

[0024] The environment perception module 20 is connected to the task execution module 10 and is used to collect the internal operating status data output by the task execution module 10 and the resource usage data of the host machine, and generate a system status snapshot based on the collected data.

[0025] The central decision-making intelligent agent 30 is connected to the environmental perception module 20 and is used to receive the system state snapshot and generate adjustment instructions for the operating parameters of the task execution module 10 based on the built-in hybrid decision model.

[0026] The dynamic executor module 40 is connected to the central decision-making agent 30 and the task execution module 10, and is used to receive the adjustment instructions and modify the operating parameters of the task execution module 10 according to the adjustment instructions.

[0027] In practice, the various modules of the system can be deployed within the same application process and call each other through programming interfaces.

[0028] The task execution module 10 is specifically implemented as a thread pool executor instance. This thread pool executor instance is encapsulated to provide a status query interface, enabling it not only to execute Runnable or Callable tasks, but also to return internal running status data such as the number of currently active threads, the number of threads in the pool, and the queue size when called externally. This data can be encapsulated in a data transfer object for output.

[0029] Furthermore, the environment awareness module 20 is implemented as a background service or scheduled task. It holds an instance of the task execution module 10 through dependency injection or direct reference. It periodically calls the status query interface of the task execution module 10 to obtain internal runtime status data. Simultaneously, it collects the host machine's CPU and memory usage by integrating a system monitoring library. The environment awareness module 20 aggregates these two types of data to construct a system status snapshot object.

[0030] Specifically, during the process of constructing a system state snapshot, the environment awareness module 20 can preprocess and extract features from the collected raw data to generate higher-dimensional performance metrics. For example, it can calculate derived metrics such as queue saturation (the ratio of the current size of the work queue to its total capacity) and thread activity rate (the ratio of the number of active threads to the current total number of threads). These calculated feature metrics can more intuitively reflect the load pressure and resource utilization of the thread pool and are encapsulated together in the system state snapshot, providing richer and more expressive state information for subsequent decision-making.

[0031] Furthermore, the central decision-making agent 30 is implemented as an event listener or service. It listens for system state snapshot events published by the environment perception module 20, or is directly invoked by the environment perception module 20. Internally, it encapsulates decision-making logic, and upon receiving a snapshot, it calculates and generates an adjustment instruction object. This adjustment instruction object explicitly describes the parameters to be modified and their target values.

[0032] Furthermore, the dynamic executor module 40 is implemented as a command executor. It listens for adjustment instructions from the central decision-making agent 30, or is directly invoked by the central decision-making agent 30. The dynamic executor module 40 holds an instance of the task execution module 10, and according to the specific content of the adjustment instruction, calls the corresponding parameter setting method on the task execution module 10 to complete the modification, such as calling the setMaximumPoolSize method, which is not specifically limited in this invention.

[0033] The system architecture defined in this embodiment divides functions such as state perception, intelligent decision-making, and command execution into independent and clearly defined modules, making the system easy to understand, develop, and maintain. The task execution module 10 focuses on task scheduling and execution, and exposes state through standardized interfaces, enabling perception; the environment perception module 20 specializes in the unified collection and formatting of multi-source data, providing high-quality input for decision-making; the central decision-making agent 30 acts as the control hub, encapsulating all decision-making complexity; and the dynamic executor module 40 ensures that control commands can be executed safely and accurately. Furthermore, the modules communicate through well-defined interfaces, reducing internal coupling and improving testability and reliability.

[0034] In some preferred embodiments, the hybrid decision-making model built into the central decision-making agent 30 includes a rule engine and a reinforcement learning model; the central decision-making agent 30 is configured to: preferentially use the rule engine to match preset rules based on the system state snapshot to generate adjustment instructions; when no preset rule is matched, the reinforcement learning model outputs recommended actions based on the system state snapshot to generate adjustment instructions.

[0035] In specific implementation, the internal structure of the central decision-making intelligent agent 30 of the system is specifically implemented as including two core sub-components.

[0036] The rules engine subcomponent is implemented as a configurable rule processor. Internally, it maintains a list of rules, each containing a conditional expression and an action definition. The conditional expression is constructed using fields from a system state snapshot, such as "cpuUsage>0.95&&queueSize == queueCapacity". The action definition is associated with the code logic that generates specific adjustment instructions. The rules engine is configured to evaluate these rules in priority order.

[0037] As an example, the rule base can pre-define the following rules: a high-priority emergency rule, the condition being "system CPU utilization consistently exceeds 95% and the work queue is full," with the action "immediately switch the thread pool's task rejection policy to CallerRunsPolicy and issue an alert"; a medium-priority rule, the condition being "queue saturation is greater than 80% and the number of active threads equals the current total number of threads," with the action "suggest increasing the maximum number of threads by 10%"; and a low-priority rule, the condition being "queue saturation is less than 10%, thread activity is less than 30%, and system CPU utilization is less than 50%, with the action "suggest reducing the number of core threads by 2." These exemplary rules demonstrate how to translate operational experience into executable assurance logic.

[0038] The reinforcement learning model subcomponent is implemented as a loaded machine learning model instance, such as a neural network model trained and exported using the TensorFlow or PyTorch framework. The reinforcement learning model can be trained and deployed using deep reinforcement learning algorithms suitable for continuous action spaces, such as deep deterministic policy gradient algorithms or proximal policy optimization algorithms. These algorithms can handle action output requirements that require fine-grained, continuous adjustment of parameters such as the number of core threads and the maximum number of threads. The neural network model is encapsulated in an adapter, which is responsible for converting system state snapshots into model input tensors and decoding the model's output action tensors into parameter adjustment suggestions.

[0039] Specifically, the reinforcement learning model is implemented using a proximal policy optimization (PPO) algorithm based on the Actor-Critic framework. The state space is a normalized snapshot vector of the system states, and the action space consists of continuously adjusted values ​​for the core thread count, maximum thread count, and queue capacity of the thread pool. The reward function comprehensively considers average task latency, throughput, CPU utilization, and memory utilization, and calculates the immediate reward through a weighted summation. Model training employs an offline experience replay mechanism, periodically sampling historical state-action-reward data from the experience buffer and updating the network parameters using gradient descent.

[0040] The main control flow of the central decision-making agent 30 is configured as follows: upon receiving a system state snapshot, it first calls the rule engine sub-component for matching and evaluation. If the rule engine matches a high-priority rule, the agent directly uses the action generated by that rule to form the final adjustment instruction, and the reinforcement learning model sub-component is not called during this process. Only when the rule engine fails to match a high-priority rule will the agent call the reinforcement learning model sub-component, send the state snapshot to the reinforcement learning model for inference, and use the output of the reinforcement learning model as the basis for generating the adjustment instruction.

[0041] This embodiment prioritizes the rule engine, ensuring that the system can react quickly and predictably in a deterministic manner when faced with known, well-defined anomalies or critical states. The reinforcement learning model, as a secondary but primary decision source, is given the space to explore and optimize within safe boundaries, enabling it to handle massive amounts of complex routine operating states and continuously learn and evolve. This system-level configuration allows the agent to retain the advantages of data-driven methods in adapting to complex environments while eliminating potential uncontrollable risks through the rule engine.

[0042] In some preferred embodiments, a collaborative communication bus is also included; the collaborative communication bus is connected to the central decision-making agent 30 and is used to transmit load status information among the central decision-making agents 30 of the multiple dynamic thread pool systems.

[0043] In practice, the collaborative communication bus is integrated into the system as an independent infrastructure component.

[0044] This collaborative communication bus can be a client instance of a message broker service or a lightweight internal message dispatcher. Its actual implementation is either a client connection object connecting to a message middleware (such as RabbitMQ or Redis) or an in-memory event bus implementation.

[0045] In terms of system architecture, each instance of the central decision-making agent in the dynamic thread pool system holds a reference to the cooperative communication bus client instance. The bus client provides methods for publishing messages and subscribing to topics. By calling the publish method, the agent sends local load status information to a public or specific topic on the bus. Simultaneously, by calling the subscribe method, the agent registers a listener callback function to receive and process messages published by other agents on the same topic on the bus.

[0046] The cooperative communication bus itself is responsible for message routing and distribution. When an agent publishes a message, the cooperative communication bus broadcasts it to all listeners of other agents that have subscribed to that topic, based on the message's subject. In this way, a loosely coupled communication channel is established between the central decision-making agents 30 of multiple dynamic thread pool systems, without the need for each other to be directly aware of the other's existence or network address.

[0047] Please see Figure 1 This invention provides a method for implementing a dynamic thread pool based on an agent, the method comprising the following steps: S1, through the environment perception module, collect the internal operating status data of the task execution module and the resource usage data of the host machine where the task execution module is located.

[0048] The internal operating status data includes the current number of threads, the number of active threads, and the current size and capacity of the work queue. The host machine's resource usage data includes CPU utilization and memory utilization.

[0049] In practice, the task execution module can be implemented as an enhanced thread pool executor, such as an extension of the ThreadPoolExecutor in the standard library. Besides executing tasks, the task execution module also uses internal counters and monitoring hooks to maintain and provide external access to internal runtime status data such as the current number of threads, the number of active threads, and the current size and remaining capacity of the work queue.

[0050] The environment awareness module runs as an independent service or component, performing data acquisition at a fixed frequency (e.g., once per second) or in an event-driven manner. This module obtains internal runtime status data by calling the application programming interface provided by the task execution module. Simultaneously, it collects host machine resource usage data, specifically CPU utilization and memory utilization, through the operating system's performance counter interface or monitoring library.

[0051] S2, Generate a system status snapshot based on the internal operating status data and the resource usage data.

[0052] In practice, after the data collection is completed, the environmental perception module cleans and formats the collected raw data, integrates the internal operating status data and resource usage data, and generates a structured system status snapshot. This snapshot is a data object containing all the above indicators.

[0053] S3, input the system state snapshot into the central decision-making agent, and generate adjustment instructions for the operating parameters of the task execution module through the central decision-making agent.

[0054] In practice, the central decision-making agent receives a system state snapshot from the environmental perception module. This agent encapsulates decision-making logic; upon receiving the system state snapshot, it analyzes and calculates based on the information in the snapshot, ultimately generating a specific adjustment instruction. This instruction specifies the operational parameters that need to be modified (e.g., the number of core threads) and their target values ​​or changes.

[0055] In some preferred embodiments, the step of generating adjustment instructions for the operating parameters of the task execution module through the central decision-making agent includes: inputting the system state snapshot into a rule engine built into the central decision-making agent for matching; if the system state snapshot matches a preset high-priority rule, generating the adjustment instructions based on the matched high-priority rule; if the system state snapshot does not match a high-priority rule, inputting the system state snapshot into a reinforcement learning model built into the central decision-making agent, outputting recommended actions through the reinforcement learning model, and generating the adjustment instructions based on the recommended actions.

[0056] In practice, the rule engine implementation includes a predefined rule library. Each rule consists of a trigger condition and a corresponding action. For example, the trigger condition for a high-priority rule might be that the system CPU utilization exceeds 95% and the work queue is full. When a system state snapshot is input, the rule engine matches the metrics in it with the trigger conditions of all rules one by one. If the snapshot data meets the conditions of a high-priority rule, the rule engine immediately executes the action logic defined by that rule, generating corresponding adjustment instructions, such as temporarily modifying the thread pool's task rejection policy to be executed by the caller. This process has the highest priority and skips subsequent reinforcement learning model inference.

[0057] It should be noted that in the dynamic thread pool system involved in this invention, high-priority rules typically correspond to system emergency states. For example, when CPU utilization consistently exceeds 95% and the work queue is full, the rule engine triggers this rule, generating adjustment instructions to forcibly modify the task rejection policy or issue a system alarm. The execution priority of this rule is higher than the inference process of the reinforcement learning model. Its design aims to monitor key risk indicators in the system state snapshot in real time. When preset emergency conditions are met, such as when system resources are about to be exhausted or the service queue is completely saturated, this rule will be triggered immediately. Once triggered, the central decision-making agent will interrupt the subsequent inference process of the reinforcement learning model and directly generate and execute explicit adjustment instructions based on this rule, such as forcibly modifying the task rejection policy or issuing an alarm. This mechanism provides a deterministic and rapid safe response channel for the entire adaptive optimization system, ensuring system stability and predictable behavior under extreme scenarios.

[0058] The reinforcement learning model can be implemented based on a deep neural network. When the system state snapshot does not trigger any high-priority rules, the snapshot is converted into the state vector format required by the reinforcement learning model and input into the model. The forward propagation computation inside the model outputs a recommended action vector based on its current policy parameters. This vector is decoded and transformed into specific adjustment suggestions for parameters such as the number of core threads and the maximum number of threads, thereby generating adjustment instructions.

[0059] This embodiment achieves a balance between response speed and decision intelligence by limiting the central decision-making agent to a hybrid decision-making mechanism that combines a rule engine and a reinforcement learning model, thereby improving the overall reliability and adaptability of the system. The rule engine, acting as a fast channel, can make deterministic responses to explicit and predictable extreme states (such as resource exhaustion risks) with extremely low latency, providing robust security for the system and preventing escalation. Meanwhile, the reinforcement learning model, acting as an optimization channel, handles a large number of non-extreme and complex operating states. It can learn the non-linear, long-term dynamic relationship between load and resources, thus making more refined and global optimization decisions. This division of labor and collaboration allows the system to both react quickly to emergencies like a rule-based system to avoid failures, and continuously learn and optimize under normal conditions like an intelligent system to pursue optimal long-term performance.

[0060] In some preferred embodiments, the construction and application of the reinforcement learning model includes the following steps: using the system state snapshot as the state space of the reinforcement learning model; using the adjustment actions of the core thread number, maximum thread number, and work queue capacity of the task execution module as the action space of the reinforcement learning model; constructing the reward function of the reinforcement learning model based on at least one of the performance indicators of average task latency, system throughput, CPU utilization, and memory utilization; and calculating the reward value obtained after executing the adjustment instruction according to the reward function during the operation of the reinforcement learning model.

[0061] In practice, regarding the construction of the state space, various metrics included in the system state snapshot, such as queue saturation, thread activity rate, average task time, and CPU utilization, are normalized and then concatenated into a fixed-length numerical vector. This vector serves as the input state for the reinforcement learning model at each decision time.

[0062] Regarding the definition of the action space, the actions that the model needs to output are designed to adjust one or more thread pool parameters. For example, the action space can be a three-dimensional continuous space, corresponding to changes in the core thread count, the maximum thread count, and the work queue capacity, respectively. The output values ​​are scaled and mapped to the absolute value or percentage of the actual adjustment.

[0063] Furthermore, regarding the construction of the reward function, a function is needed to quantify the quality of each decision during model training and application. This function is calculated using system performance metrics as input. For example, a specific implementation of the reward function could be: the reward value equals the negative average task latency multiplied by weight one, plus the system throughput multiplied by weight two, and then subtracts the CPU utilization multiplied by weight three. Here, the average task latency and system throughput can be calculated from the monitoring data of the task execution module, while the CPU utilization comes from the data collected by the environment perception module.

[0064] In a specific embodiment, the reward function can be designed to comprehensively consider multiple system objectives. For example, the reward value R can be calculated using the following formula: R = w1 * (-AvgLatency) + w2 * Throughput + w3 * (-CpuUsage) + w4 * (-MemoryUsage) + Penalty. Here, AvgLatency represents the average task latency, Throughput represents throughput, CpuUsage represents CPU utilization, MemoryUsage represents memory utilization, w1 to w4 are the weight coefficients for each item, and Penalty is a penalty for abnormal situations such as task rejection. This reward function guides the reinforcement learning model to reduce latency and increase throughput while simultaneously reducing resource consumption and avoiding system overload.

[0065] Furthermore, the setting of weighting coefficients reflects the preference for different optimization objectives, which is not specifically limited in this invention.

[0066] Furthermore, regarding reward calculation, after the reinforcement learning model generates and executes the adjustment instruction, the environment perception module collects the new system state. Based on the changes in performance metrics between the old and new states, the aforementioned reward function can be called to calculate the immediate reward value obtained from executing the instruction, which is then used for subsequent model training.

[0067] In this embodiment, by using a system snapshot encompassing both internal and external states as the state space, the model's decision-making basis is expanded from a single queue length to a comprehensive system context, providing a sufficient information foundation for the model to learn complex strategies. Furthermore, by directly defining the adjustment of key thread pool parameters as the action space, the model's output can be precisely translated into actual control operations, achieving end-to-end optimization from perception to execution. Furthermore, by constructing a reward function based on multi-dimensional performance metrics, the model's learning direction is guided in principle, ensuring it not only focuses on task processing speed but also considers multiple objectives such as resource consumption and system stability. For example, introducing a penalty term for high CPU utilization in the reward function can guide the model to automatically avoid suboptimal strategies that create too many threads, leading to increased resource contention, during the learning process. This design enables the learned strategy to automatically balance throughput, latency, and resource efficiency, achieving global, long-term performance optimization, surpassing traditional methods that only adjust thresholds for a single metric.

[0068] In some preferred embodiments, the training steps further include: collecting training data, the training data including the system state snapshot, adjustment instructions generated based on the snapshot, a new system state snapshot obtained after executing the instructions, and a calculated reward value; storing the training data in a preset experience replay buffer; periodically sampling training data from the experience replay buffer; and using the training data to update the parameters of the reinforcement learning model.

[0069] In practice, the step of collecting training data is completed by a central decision-making agent or an independent data collection service. Each time the central decision-making agent generates an adjustment instruction based on a system state snapshot, that instruction is executed. The system records a four-tuple of data for this decision: a system state snapshot before the decision, the generated adjustment instruction, a new system state snapshot collected after a time interval following the instruction's execution, and the reward value calculated according to the reward function. This four-tuple constitutes a complete empirical dataset.

[0070] Furthermore, in the step of storing training data into the experience replay buffer, the system maintains a fixed-size first-in-first-out queue as the experience replay buffer. Newly generated experience data is appended to the end of this buffer. When the buffer is full, the oldest data is removed.

[0071] Furthermore, the periodic sampling of training data is triggered by a timed task. For example, every hour or when the amount of data in the buffer reaches a threshold, the training program randomly and uniformly samples a small batch of empirical data from the empirical replay buffer.

[0072] Furthermore, in the step of updating model parameters using training data, a batch of sampled empirical data is used to perform the update operation of the reinforcement learning algorithm. For example, if a proximal policy optimization algorithm is used, this batch of data will be used to calculate the policy gradient and value function loss, and then the parameter weights of the policy network and value network will be updated through the backpropagation algorithm, thereby improving the model policy.

[0073] In this embodiment, historical decision data is collected and stored through an experience replay buffer, addressing the issues of strong data sample correlation and low efficiency in online learning. Furthermore, periodic random sampling from the buffer for training breaks the temporal correlation between data, making model updates more stable and facilitating convergence to a better strategy. Furthermore, separating the time-consuming model training process from the real-time decision-making thread and performing it offline asynchronously ensures that the real-time performance and low latency of online decision-making are not affected. Furthermore, the system can utilize accumulated experience data for model iteration during off-peak periods, thereby continuously improving the agent's decision-making ability as the system runs. For example, after experiencing multiple traffic peaks, the model, through offline training, can learn more accurate scaling timing and magnitude, exhibiting better performance in similar scenarios in the future.

[0074] S4, the adjustment instruction is executed through the dynamic executor module to modify the operating parameters of the task execution module.

[0075] In practice, the dynamic executor module is responsible for executing the adjustment instructions issued by the central decision-making agent. Based on the instruction type, the dynamic executor module calls the parameter setting interface provided by the task execution module, such as calling the `setCorePoolSize` method to modify the core thread count, thereby safely modifying the running parameters of the task execution module.

[0076] In this embodiment, by introducing an environment-aware module and a central decision-making agent, an automated closed loop from state perception to decision execution is constructed, overcoming the rigidity problem of traditional static thread pool configuration. Specifically, the environment-aware module continuously collects data on the internal state of the thread pool and the host machine's resources, enabling the system to obtain a multi-dimensional, real-time operational profile. Furthermore, the central decision-making agent generates adjustment instructions based on this profile, driving the dynamic executor module to modify the parameters. This process transforms the thread pool's operating parameters from fixed values ​​into variables that can dynamically change according to actual load and resource conditions. For example, when the system detects a continuous increase in the work queue and sufficient CPU capacity, it can automatically increase the number of threads to improve processing power; conversely, it can automatically reduce the size when the load is low to save resources. This method realizes a shift from manual preset to system self-adaptation, providing a basic automated framework for solving rigid resource configuration and improving resource utilization efficiency.

[0077] In some preferred embodiments, when the adjustment instruction indicates a reduction in the number of core threads, the step of executing the adjustment instruction through the dynamic executor module to modify the operating parameters of the task execution module includes: enabling the core thread idle timeout function of the task execution module; calculating a new number of core threads according to the adjustment instruction; and causing excess threads whose current number of core threads exceeds the new number of core threads to automatically terminate after the idle time reaches a preset timeout threshold.

[0078] In practice, when enabling the core thread idle timeout function, the dynamic executor module first checks whether the core thread timeout function of the task execution module is enabled. If it is not enabled, it calls the setting interface of the task execution module to set the flag allowing core thread timeout to true and simultaneously sets a specific idle timeout threshold, such as sixty seconds.

[0079] Furthermore, in the step of calculating the new core thread count, the dynamic executor module parses the adjustment instructions, which may contain the target core thread count or the number of core threads to be reduced from the current core thread count. The module calculates the final core thread count to be set based on the instruction content.

[0080] Furthermore, during the step of waiting for idle threads to automatically terminate, the dynamic executor module calls the task execution module's interface to set the core thread count to the new value calculated above. After setting, the task execution module does not immediately terminate any threads. Threads currently executing tasks will continue working. Threads that are already idle and whose idle time exceeds the preset timeout threshold will be automatically terminated by the thread pool framework. For threads that are idle but have not yet reached their timeout period, they will terminate automatically after their idle time accumulates to the threshold. The dynamic executor module does not forcibly interrupt any threads during this process.

[0081] In this embodiment, by specifically defining the safe operation process when reducing the number of core threads, a smooth scaling down of the thread pool is achieved, ensuring the continuity of business execution and data consistency. Traditional methods of directly reducing the number of threads may forcibly interrupt currently working threads, leading to task failures or inconsistent states. This method, however, transforms the scaling down instruction into a gentle, conditionally triggered background process by enabling and relying on the core thread idle timeout mechanism. The system only sets a lower thread count target and allows excess threads to naturally complete their current tasks and remain idle for a period before automatically ending their lifecycle. This means that no thread executing critical business logic will be suddenly terminated, and all tasks can be completed normally. This lossless adjustment method significantly improves system reliability and service availability during dynamic adjustment, enabling automatic scaling down to be safely implemented in production environments and avoiding new risks introduced by resource adjustments.

[0082] In some preferred embodiments, the task execution module uses a dynamically adjustable blocking queue as a work queue; the step of executing the adjustment instruction through the dynamic executor module to modify the operating parameters of the task execution module includes: calculating a new queue capacity value based on the adjustment content regarding the work queue capacity in the adjustment instruction; and modifying the upper limit of the blocking queue capacity to the new queue capacity value.

[0083] In practice, the task execution module uses a blocking queue that supports dynamic capacity adjustment, such as a custom, resizable blocking queue.

[0084] Furthermore, upon receiving a command to adjust the work queue capacity, the dynamic executor module first parses the command. The command may specify a new absolute capacity value or an adjustment percentage based on the current capacity. The dynamic executor module then calculates the new queue capacity value based on the current queue capacity and the command content. This calculation process ensures that the new capacity value is within a preset, reasonable range.

[0085] Furthermore, the dynamic executor module obtains the work queue instance used by the task execution module. By calling the capacity setting method provided by this queue instance, it modifies the queue's maximum capacity to the calculated new value. This operation is typically thread-safe to ensure that during the modification process, task enqueueing and dequeueing operations do not lead to data errors or abnormal queue states. After the modification is complete, subsequent task submissions will determine the remaining queue space based on the new capacity.

[0086] In this embodiment, the system's buffering and resilience in the face of sudden traffic surges is enhanced by the technical feature of dynamically adjusting the work queue capacity. In traditional thread pools, the queue capacity is fixed. When a sudden surge in traffic exceeds the thread's processing capacity, the queue quickly fills up, triggering task rejection and potentially leading to request failures or a degraded user experience. This method makes the queue capacity a dynamically adjustable parameter. When the agent predicts or senses an impending surge in traffic and thread expansion requires time or is limited by resources, it can prioritize increasing the queue capacity, providing a larger buffer for tasks to tolerate temporary load spikes and buying time for internal thread expansion or external load balancing. Conversely, during periods of stable load, the queue capacity can be appropriately reduced to decrease the average waiting time of tasks in the queue and reduce the memory consumption of queued tasks. This dynamic adjustment capability allows the thread pool to more flexibly balance latency, throughput, and memory consumption, providing a traffic shaping and overload protection mechanism and improving the overall resilience and stability of the system in the face of load fluctuations.

[0087] In some preferred embodiments, the dynamic thread pool system further includes a collaborative communication bus connected to the central decision-making agent; the method further includes: sending load status information obtained by the central decision-making agent of this dynamic thread pool system to the central decision-making agents of other dynamic thread pool systems through the collaborative communication bus; receiving load status information sent from the central decision-making agents of other dynamic thread pool systems through the collaborative communication bus; and generating collaborative control instructions involving task routing or load sharing based on the received load status information and the status of this dynamic thread pool system.

[0088] In practice, the central decision-making agent, in addition to generating local adjustment instructions, is also responsible for handling coordination logic. It encapsulates key load status information of its thread pool, such as queue saturation and its own load level, into a message. This message is then published to a predefined channel or topic on the coordination communication bus by calling the client interface of the coordination communication bus. The specific implementation of the coordination communication bus can be a message middleware based on a publish-subscribe pattern, such as Redis Pub / Sub or Apache Kafka.

[0089] Meanwhile, the central decision-making agent subscribes to relevant channels on the bus to continuously monitor load status information sent by other dynamic thread pool system agents. When such messages are received, the agent parses them.

[0090] Based on received external load information and a snapshot of its current system state, the central decision-making agent executes collaborative decision-making logic. For example, if its own load is high and it receives a low-load signal from other instances in the same service, the agent generates a collaborative control instruction. This instruction does not directly modify thread pool parameters, but may notify the upstream gateway or load balancer through a callback function to route some traffic to the low-load instance; or, if its own load is low, after receiving an overload distress signal, it can send a signal upstream that it can accept more tasks.

[0091] In this embodiment, by introducing a collaborative communication bus and cross-agent information exchange steps, the local autonomy of a single thread pool is elevated to system-level global coordination, effectively solving the problems of resource silos and uneven load distribution in a distributed environment. A single central decision-making agent can only optimize based on the resource status of its own instance, which may lead to local optima. For example, one instance may frequently reject tasks due to insufficient resources, while other instances in the same cluster remain idle. In this embodiment, each agent gains a global perspective, enabling it to perceive the load status of other similar service instances. Based on this global information, agents can make collaborative decisions beyond their own resource limitations, such as guiding traffic migration between instances. This achieves a decentralized, self-organizing load balancing and backpressure control mechanism within the distributed system. When a service node experiences excessive pressure, the collaborative mechanism can proactively alleviate traffic congestion, preventing the node from becoming a performance bottleneck or even crashing. Simultaneously, idle resources are fully utilized, thereby improving the overall throughput and resource utilization of the entire service cluster and enhancing the overall resilience and high availability of the microservice architecture.

[0092] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0093] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Since these modifications and variations fall within the scope of the claims and their equivalents, this invention also intends to include these modifications and variations.

[0094] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for implementing a dynamic thread pool based on an agent, characterized in that, The method is applied to a dynamic thread pool system, which includes a task execution module, an environment awareness module connected to the task execution module, a central decision-making agent connected to the environment awareness module, and a dynamic executor module connected to the central decision-making agent and the task execution module; the method includes: The environmental perception module collects internal operating status data of the task execution module and resource usage data of the host machine where the task execution module is located. A system status snapshot is generated based on the internal operating status data and the resource usage data; The system state snapshot is input into the central decision-making agent, which then generates adjustment instructions for the operating parameters of the task execution module. The adjustment instructions are executed by the dynamic executor module to modify the operating parameters of the task execution module.

2. The method for implementing a dynamic thread pool based on an Agent according to claim 1, characterized in that, The step of generating adjustment instructions for the operating parameters of the task execution module through the central decision-making agent includes: The system state snapshot is input into the rule engine built into the central decision-making agent for matching; If the system state snapshot matches a preset high-priority rule, the adjustment instruction is generated based on the matched high-priority rule; If the system state snapshot does not match a high-priority rule, the system state snapshot is input into the reinforcement learning model built into the central decision-making agent. The reinforcement learning model outputs a recommended action and generates the adjustment instruction based on the recommended action.

3. The method for implementing a dynamic thread pool based on an Agent according to claim 2, characterized in that, The construction and application of the reinforcement learning model includes the following steps: The system state snapshot is used as the state space of the reinforcement learning model; The action space of the reinforcement learning model is defined by adjusting the core thread count, maximum thread count, and work queue capacity of the task execution module. The reward function of the reinforcement learning model is constructed based on at least one of the following performance metrics: average task latency, system throughput, CPU utilization, and memory utilization. During the operation of the reinforcement learning model, the reward value obtained after executing the adjustment instruction is calculated according to the reward function.

4. The method for implementing a dynamic thread pool based on an Agent according to claim 2 or 3, characterized in that, Also includes: Collect training data, which includes the system state snapshot, adjustment instructions generated based on the snapshot, a new system state snapshot obtained after executing the instructions, and a calculated reward value. The training data is stored in a preset experience playback buffer. Training data is periodically sampled from the experience replay buffer; The parameters of the reinforcement learning model are updated using the training data.

5. The method for implementing a dynamic thread pool based on an agent according to claim 1, characterized in that, When the adjustment instruction indicates a reduction in the number of core threads, the execution of the adjustment instruction through the dynamic executor module to modify the operating parameters of the task execution module includes: Enable the core thread idle timeout function of the task execution module; Calculate the new number of core threads based on the adjustment instructions; Any excess threads whose current core thread count exceeds the new core thread count will automatically terminate after their idle time reaches a preset timeout threshold.

6. The method for implementing a dynamic thread pool based on an agent according to claim 1, characterized in that, The task execution module uses a dynamically adjustable blocking queue as its work queue; the step of executing the adjustment instruction through the dynamic executor module to modify the operating parameters of the task execution module includes: Calculate the new queue capacity value based on the adjustment content regarding the work queue capacity in the adjustment instruction; Modify the upper limit of the blocked queue to the new queue capacity value.

7. The method for implementing a dynamic thread pool based on an agent according to claim 1, characterized in that, The dynamic thread pool system further includes a collaborative communication bus connected to the central decision-making agent; the method further includes: Through the cooperative communication bus, the load status information obtained by the central decision-making agent of this dynamic thread pool system is sent to the central decision-making agent of other dynamic thread pool systems. Through the cooperative communication bus, load status information sent by the central decision-making agent of other dynamic thread pool systems is received; Based on the received load status information and the status of this dynamic thread pool system, cooperative control instructions involving task routing or load sharing are generated.

8. A dynamic thread pool system, characterized in that, To implement the method of any one of claims 1 to 7, comprising: The task execution module is used to receive and execute externally submitted tasks and output the internal running status data of the thread pool. An environment awareness module, connected to the task execution module, is used to collect internal operating status data output by the task execution module and resource usage data of the host machine, and generate a system status snapshot based on the collected data. A central decision-making intelligent agent, connected to the environmental perception module, is used to receive the system state snapshot and generate adjustment instructions for the operating parameters of the task execution module based on the built-in hybrid decision model. The dynamic executor module, connected to the central decision-making agent and the task execution module, is used to receive the adjustment instructions and modify the operating parameters of the task execution module according to the adjustment instructions.

9. The system according to claim 8, characterized in that, The central decision-making agent incorporates a hybrid decision-making model that includes a rule engine and a reinforcement learning model.

10. The system according to claim 8 or 9, characterized in that, It also includes a collaborative communication bus; the collaborative communication bus is connected to the central decision-making agent and is used to transmit load status information among the central decision-making agents of multiple dynamic thread pool systems.

Images