Thread pool monitoring management method
By using ZooKeeper tool to build a publish-subscribe system in a distributed environment, dynamic adjustment of Java thread pool parameters is achieved, and the problem of Java thread pool parameter configuration is solved one-time and cannot be modified dynamically, improving the system's flexibility and response speed.
Patent Information
- Application Number
- CN202510577896.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-07
- Publication Date
- 2025-08-15
AI Technical Summary
In the prior art, the Java thread pool parameter configuration is one-time and cannot be modified dynamically, resulting in difficulty in initial configuration and inconvenient tuning. The existing monitoring tool is consumed with large resources and many complex configurations, which affects system flexibility and response speed.
Deploy the thread pool client and management end in a distributed environment, use the ZooKeeper tool to build a publish-subscribe system, the client initializes the thread pool and periodically reports the running data, the management end dynamically modifys and pushes parameters, and dynamically adjusts the classes through Java native thread pool implementation classes.
It realizes rapid response and dynamic adjustment of thread pool parameters, reduces learning costs and complex configurations, improves system flexibility and response speed, and avoids service interruptions caused by downtime.
Smart Images
Figure CN120492264A_ABST
Abstract
Description
Technical Field
[0001] The invention belongs to the field of computer technology, and in particular relates to a thread pool monitoring and management method. Background Art
[0002] Computer programs use threads to execute tasks and process data. When handling concurrent tasks or batch data, single-threaded processing is inefficient, so multithreading is generally preferred. Java developers use thread pools to accomplish multithreading, managing and controlling the number of threads used by an application and their lifecycle. Java developers set up thread pools and configurable thread pool parameters during program development. After program development is complete, they set these parameters before starting the application. Configuring thread pool parameters is particularly critical when using a thread pool. Improper parameter configuration can cause malfunctions and unpredictable system issues.
[0003] The Java thread pool is a set of APIs integrated into the JDK for developers to call, allowing them to easily create and manage threads. However, there is no dedicated monitoring and control platform for Java thread pools, and thread pool parameters can only be configured once. This means that after the application starts, thread pool parameters cannot be dynamically modified. Therefore, during the actual parameter configuration process, developers must estimate the optimal parameters for the thread pool, such as the number of core threads and the maximum number of threads, before starting the application. Because these parameters typically depend on the specific workload of the application, it is difficult to accurately estimate them without actual operating data. If the application fails after it goes online, developers modify the relevant code or configuration files and redeploy the application, which may cause service interruptions. This limitation of one-time parameter configuration brings difficulties in initial configuration and inconvenience in tuning.
[0004] To address these challenges, Java's JMX technology enables Java systems to monitor and dynamically adjust application configurations, specifically for monitoring and dynamically modifying thread pools. However, due to its comprehensive functionality, JMX consumes significant resources. Introducing JMX solely for thread pool monitoring and adjustment would consume additional system resources. Furthermore, JMX monitors and influences a vast amount of data, such as JVM information, application logs, and other system-level information, potentially leaking business and user information. While third-party libraries and monitoring tools can address the shortcomings of existing technologies, they also introduce additional challenges, such as complex configuration, incompatibility with applications and environments, and the learning curve for new tools.
[0005] Currently, there are many dynamic thread pool systems on the market that allow developers and administrators to centrally manage and monitor thread pools running in different applications, enabling more flexible and efficient use of system resources and facilitating timely adjustment of thread pools to respond to varying load demands. However, such tools require that all thread pool configurations rely on a unified configuration service. If the service fails or goes down, it will directly affect the thread pools of all applications that rely on it, making it impossible for the thread pools to adjust according to the latest configuration, which in turn causes application performance degradation or service interruption. Secondly, because thread pool configurations are centrally created by the management side, developers need to register with the management side before using the thread pool. This process is more complicated than the traditional method of creating and configuring thread pools directly in the application client. Especially in scenarios where thread pool configurations need to be frequently modified or a large number of thread pools need to be managed, this centralized management approach may increase additional development and maintenance workload, leading to delays in configuration updates and reducing the flexibility and responsiveness of the system.
[0006] Since the existing thread pool monitoring technology has poor flexibility and slow modification response, a new thread pool monitoring and management technology is needed to achieve efficient monitoring and dynamic adjustment while maintaining the native thread pool without introducing additional third-party tools. Summary of the Invention
[0007] To address existing technical issues, this invention provides a thread pool monitoring and management method. This method aims to address the inconvenience of traditional thread pool runtime monitoring, specifically the current situation where downtime is required to release updates to fix issues. This innovative solution is presented. The core advantage of this method lies in its high consistency with native APIs, significantly reducing the user learning curve and migration costs, ensuring seamless technology integration and rapid deployment.
[0008] The technical solution of the present invention is a method for monitoring and managing a thread pool, which specifically comprises the following steps:
[0009] Step 1: Establish loosely coupled communication between the thread pool client and the thread pool manager: Deploy the thread pool client and thread pool manager in a distributed environment, use the ZooKeeper tool to build a publish-subscribe system in the distributed environment, define the manager as the publisher, and the client as the subscriber; integrate the client into the application and monitor changes in data nodes in ZooKeeper; the manager exposes an interface for receiving data to the client;
[0010] Step 2: Initialize the application's thread pool using the client: Encapsulate the Java native thread pool implementation class in the client Jar package; when the application starts, access the API provided by the Jar package, call the implementation class to create a thread pool, and initialize the thread pool configuration;
[0011] Step 3: The client periodically collects and reports thread pool operation data: The client collects thread pool operation data, uses the HTTP protocol, calls the interface exposed by the management end, and reports the operation data to the management end; the operation data includes instantaneous data and cumulative data; the instantaneous data refers to the data collected only when reporting, including the application name, client IP, thread pool name and corresponding thread pool working parameters; the cumulative data refers to the cumulative number of times the thread pool executes tasks, including the number of successful executions and the number of failed executions; the cumulative number is saved in the memory after each update;
[0012] Step 4: Parameter Saving and Dynamic Modification: After the management end receives the running data in step 3, it saves and records the application name, client IP, thread pool name, and corresponding thread pool working parameters; using the thread pool name and client IP recorded by the management end, the user searches for the specified thread pool and modifies the thread pool working parameters; based on the publish-subscribe system in step 1, the management end pushes the modified working parameters to ZooKeeper and saves them in the data node corresponding to the thread pool name, waiting for the client to pull them;
[0013] Step 5: Thread pool early warning monitoring: The server extracts the number of active threads and the maximum number of threads from the running data, and calculates the thread activity according to Formula 1; extracts the used queue length and the idle queue length, and calculates the queue load according to Formula 2; extracts the number of task execution failures, and calculates the rejection increment value according to Formula 3; if any of the above values exceeds the early warning threshold, the management end sends an early warning message to the user through a predetermined notification method;
[0014] Formula 1: Thread activity = number of active threads / maximum number of threads;
[0015] Formula 2: Queue load = used queue length / (used queue length + idle queue length);
[0016] Formula 3: Rejection increment value = number of task execution failures - number of previous task execution failures.
[0017] In step 1, the client Jar package is integrated into the application code using the Maven tool. Specifically, the Jar package is integrated into the application code by specifying coordinates, where the value of the coordinate GroupId is the name of the application; the value of the coordinate ArtifactId is the name of the Jar package; and the value of the coordinate Version is the version number of the Jar package.
[0018] In step 1, the management end creates a data node with a theme of "thread pool name" in the ZooKeeper, and the client subscribes to the data node.
[0019] In step 3, the interface exposed by the management terminal is called through the interface address, and the interface address is configured in advance in the configuration file of the client;
[0020] In step 3, the reporting frequency is preferably 1 time / min; the accumulated data is not cleared after the reporting is completed.
[0021] The step 4 specifically includes:
[0022] Step 4-1: The ZooKeeper data node receives the modified operating parameters. Based on the ZooKeeper tool's processing mechanism for newly received data, the data node updates the stored data, triggering a node update event. The node update event is then sent to the client.
[0023] Step 4-2: After the client monitors the event, it reads the modified working parameters from the data node, calls the parameter setting method supported by the Java native "ThreadPoolExecutor" class, and dynamically modifies the thread pool working parameters.
[0024] In step 4, the threshold of the queue load is 60%, the threshold of the thread activity is 90%, and the threshold of the rejection increment value is 0.
[0025] The beneficial effects achieved by the present invention are:
[0026] 1) The present invention deploys a thread pool client and a management end in a distributed environment, creates a publish-subscribe system based on the ZooKeeper tool, and promptly sends the thread pool working parameters modified by the management end to the client via ZooKeeper. In the constructed lightweight architecture, the client does not need to register with the management end in advance, and temporary downtime or offline of either party does not affect the transmission of modified parameters, so that the thread pool can respond to changes quickly, ensuring that the thread pool can execute tasks based on the latest working parameters, and improving the modification response speed.
[0027] 2) The present invention encapsulates the implementation class of the native thread pool in the thread pool client JAR package and synchronously extends other implementation classes to achieve client-based thread pool initialization, operation data reporting and dynamic modification of working parameters. While maintaining the use of the native thread pool, no additional third-party tools are introduced to achieve efficient monitoring and dynamic adjustment of the thread pool, reduce the learning cost of new tools for developers, and avoid additional complex configuration problems. BRIEF DESCRIPTION OF THE DRAWINGS
[0028] Figure 1 A schematic diagram of a thread pool monitoring and management process in an embodiment of the present invention;
[0029] Figure 2 A schematic diagram of a management terminal recording thread pool working parameters in an embodiment of the present invention;
[0030] Figure 3 A schematic diagram of a management terminal modifying thread pool working parameters in an embodiment of the present invention;
[0031] Figure 4 The figure is a schematic diagram of the system structure of a thread pool monitoring and management in an embodiment of the present invention. DETAILED DESCRIPTION
[0032] In order to make the objectives, technical solutions and advantages of the present invention more clear, the present invention is described in detail below with reference to the accompanying drawings and specific embodiments.
[0033] The main goal of the thread pool is to manage and control the number of threads used in the application, as well as the management of the thread life cycle. The overhead of thread creation and destruction is relatively large. By reusing threads through the thread pool, this overhead can be reduced and system performance can be improved. At the same time, the thread pool can also queue and schedule tasks. When all threads are busy, newly submitted tasks can wait in the queue until a thread is free. However, the configuration of thread pool parameters is only allowed once, that is, after the application is started, the thread pool parameters cannot be modified dynamically. Although Java's JMX technology and third-party libraries and monitoring tools can make up for the technical deficiencies of "configuring only once", it also brings more problems such as additional complex configuration, difficulty in compatibility with applications and environments, and the learning cost of new tools. Therefore, the thread pool management and monitoring method based on the native thread pool is particularly important. In an embodiment of the present invention,
[0034] Figure 1 The following is a flowchart of a thread pool monitoring and management process according to an embodiment of the present invention, specifically including:
[0035] Step 101: Establishing loosely coupled communication between the thread pool client and the thread pool manager: Using the ZooKeeper tool to build a publish-subscribe system in a distributed environment, defining the manager as the publisher and the client as the subscriber; the client is integrated into the application and monitors changes in data nodes in ZooKeeper; the manager exposes an interface to the client for the client to call and report thread pool operation data;
[0036] In step 101, the client Jar package is integrated into the application code using the Maven tool. Specifically, the Jar package is integrated into the application code by specifying coordinates, wherein the value of the coordinate GroupId is the name of the application; the value of the coordinate ArtifactId is the name of the Jar package; and the value of the coordinate Version is the version number of the Jar package.
[0037] In step 101, the ZooKeeper tool is used to build a publish-subscribe system. The manager creates a data node in ZooKeeper with the topic "thread pool name," and the client subscribes to the data node. Compared to other tools that support publish-subscribe systems, ZooKeeper is simple to configure and requires minimal manpower. It is particularly suitable for distributed environments where thread pools, clients, and managers operate independently and require data exchange.
[0038] Step 102: Initialize the thread pool of the application using the client: encapsulate the implementation class of the Java native thread pool in the client Jar package; when the application starts, access the API provided by the Jar package, the client calls the implementation class to create the thread pool, and reads the thread pool configuration from the preset parameters of the application.
[0039] The creation and use of Java native thread pools are accomplished through the "java.util.concurrent.ExecutorService" interface and its implementation classes, such as the "ThreadPoolExecutor" class and the "Executors" factory class. In an embodiment of the present invention, the client JAR package encapsulates the "ThreadPoolExecutor" class and replaces the original "java.util.concurrent.ExecutorService" interface with the API provided by the Jar package. Although this involves the reconstruction of the original code, the API internally encapsulates the Java native "ThreadPoolExecutor" class, retaining all the functions of the native thread pool and being able to encapsulate other classes to extend the thread pool management function.
[0040] Step 103: The thread pool client periodically collects and reports thread pool operation data: the client collects the operation data of the thread pool, uses the HTTP protocol, calls the interface exposed by the management end, and reports the operation data to the management end; the operation data includes instantaneous data and cumulative data; the instantaneous data refers to data collected only when reporting, including application name, client IP, thread pool name and corresponding thread pool working parameters. The thread pool working parameters in the embodiment of the present invention include the number of core threads, maximum number of threads, number of active threads, used queue length, idle queue length, and number of tasks to be processed; the cumulative data refers to the cumulative number of times the thread pool executes tasks, including the number of successful executions and the number of failed executions; the cumulative number is saved in the memory after each update;
[0041] In step 103, the interface exposed by the management terminal is called through the interface address, and the interface address is configured in advance in the configuration file of the client;
[0042] In step 103, the reporting frequency is preferably 1 time / min; the accumulated data is not cleared after the reporting is completed;
[0043] Step 104: Save and dynamically modify thread pool parameters: After the management end receives the running data in step 103, it saves and records the client IP, thread pool name and corresponding thread pool working parameters; through the thread pool name and client IP recorded by the management end, the user searches for the specified thread pool, such as Figure 2 This is a schematic diagram of the management end recording the thread pool working parameters in an embodiment of the present invention. Click the modify button in the figure to modify the working parameters of the thread pool, such as Figure 3 This is a schematic diagram of the management end modifying the thread pool working parameters in an embodiment of the present invention; based on the publish-subscribe system of step 101, the management end first pushes the modified working parameters to ZooKeeper and saves them in the data node corresponding to the thread pool name, waiting for the client to pull them. In this embodiment of the present invention, the thread pool does not need to be registered with the management end in advance. Since the thread pool client IP and thread pool name are both included in the running data, when the running data is reported to the management end, the management end will automatically save it. The user can find the thread pool saved by the management end through the visual interface of the management end, and then complete the modification of the thread pool working parameters.
[0044] The step 104 specifically includes:
[0045] Step 104-1: The ZooKeeper data node receives the modified working parameters. Based on the ZooKeeper tool's processing mechanism for newly received data, the data node updates the stored data, triggering a node update event. The node update event is then sent to the client.
[0046] ZooKeeper is a middleware that provides coordination services for distributed applications. It can quickly push data updates to all clients that need them. This embodiment of the present invention uses ZooKeeper's data nodes to store modified thread pool operating parameters. This means that any parameter changes are immediately pushed to all clients that monitor these parameter changes. This allows the thread pool to quickly respond to changes, ensuring that all thread pool instances are operating based on the latest operating parameters, and improving system responsiveness and consistency.
[0047] Step 104-2: After the client monitors the event, it reads the modified operating parameters from the data node and calls the parameter setting methods supported by the Java native "ThreadPoolExecutor" class to dynamically modify the thread pool operating parameters. The Java native "ThreadPoolExecutor" class provides common parameter setting methods, such as setCorePoolSize(int corePoolSize) for setting the number of core threads in the thread pool and setMaximumPoolSize(int maximumPoolSize) for setting the maximum number of threads in the thread pool. These methods support dynamic setting of thread pool operating parameters during thread pool operation, allowing the thread pool to better adapt to application needs. Taking the number of core threads as an example, if a period of high load is expected, the user can increase the number of core threads to reduce thread creation overhead; conversely, if the load is expected to decrease, the user can reduce the number of core threads to save resources.
[0048] Step 105: Thread pool operation warning monitoring: the server extracts the number of active threads and the maximum number of threads in the operation data, and calculates the thread activity according to formula 1; extracts the used queue length and the idle queue length, and calculates the queue load according to formula 2; extracts the number of task execution failures, and calculates the rejection increment value according to formula 3; if any of the above values exceeds the warning threshold, the management end sends a warning message to the server through a predetermined notification method.
[0049] Formula 1: Thread activity = number of active threads / maximum number of threads;
[0050] Formula 2: Queue load = used queue length / (used queue length + idle queue length)
[0051] Formula 3: Rejection increment value = number of task execution failures - number of previous task execution failures
[0052] In step 4, the threshold of the queue load is 60%, the threshold of the thread activity is 90%, and the threshold of the rejection increment value is 0.
[0053] After observing and debugging actual operations, technicians found that setting alerts with activity levels below 90%, queue load below 60%, and a rejection increment value of 0 ensures maximum thread pool performance and avoids serious issues. The technicians considered the queue load threshold settings for flexibility. In reality, the queue load warning threshold should be neither too high nor too low. If the threshold is set too low, the system may issue alerts too frequently, which may cause confusion for system administrators and may cause real problems to go unnoticed. If the threshold is set too high, by the time the alert is actually triggered, the system may no longer have enough time and space to address the problem. Furthermore, regarding thread activity, by retaining 10% adjustment space to accommodate sudden task increases, new tasks can be added promptly, avoiding rejection or long wait times due to sudden high loads.
[0054] Figure 4 This is a schematic diagram of the system structure of a thread pool monitoring and management in an embodiment of the present invention, which includes a thread pool client, a thread pool management terminal, a configuration service center and a database.
[0055] The client is embedded in the application and includes a creation module, a configuration acquisition module, and a data reporting module; the creation module is used to initialize and configure the thread pool of the application; the configuration parameters include the thread pool name, the number of core threads, the maximum number of threads, the idle survival time of the thread and its time unit, the task queue and its length, the fairness policy of task processing, the task rejection policy, and the thread pool decorator; the configuration acquisition module is used to monitor and obtain external thread pool working parameters and perform dynamic modification of the thread pool working parameters; the data reporting module is used to collect thread pool operation data and report it to the management end, and at the same time capture upload exceptions and perform exception handling;
[0056] The management terminal is configured as a visual web graphical interface, which receives thread pool operation data reported by the client by exposing an interface for the client to call. The management terminal includes a display module, a management module, and an early warning module. The display module is used to visualize the received operation data; the management module is used to manage the operation data, modify and push the thread pool operating parameters; the early warning module is used to configure the operation early warning conditions and analyze the operation data to determine whether the thread pool operation meets the early warning conditions. The thread pool operating parameters include the thread pool name, the number of core threads, the maximum number of threads, and the queue length.
[0057] The Zookeeper is used to receive the thread pool working parameters modified by the management end; the client monitors the Zookeeper and pulls the corresponding modified thread pool parameters from the Zookeeper according to the client IP address;
[0058] The database is used to store thread pool working parameters modified by the management end.
[0059] The beneficial effects achieved by the present invention are:
[0060] 1) The present invention deploys a thread pool client and a management end in a distributed environment, creates a publish-subscribe system based on the ZooKeeper tool, and promptly sends the thread pool working parameters modified by the management end to the client via ZooKeeper. In the constructed lightweight architecture, the client does not need to register with the management end in advance, and temporary downtime or offline of either party does not affect the transmission of modified parameters, so that the thread pool can respond to changes quickly, ensuring that the thread pool can execute tasks based on the latest working parameters, and improving the modification response speed.
[0061] 2) The present invention encapsulates the implementation class of the native thread pool in the thread pool client JAR package and synchronously extends other implementation classes to achieve client-based thread pool initialization, operation data reporting and dynamic modification of working parameters. While maintaining the use of the native thread pool, no additional third-party tools are introduced to achieve efficient monitoring and dynamic adjustment of the thread pool, reduce the learning cost of new tools for developers, and avoid additional complex configuration problems.
[0062] The present invention may also have many other implementation methods. The above embodiments do not limit the present invention in any way. Without departing from the spirit and essence of the present invention, those skilled in the art may make various corresponding changes and modifications based on the present invention. Any other improvements and applications made to the above embodiments in an equivalent transformation manner should fall within the scope of protection of the claims attached to the present invention.
Claims
1. A thread pool monitoring and management method, characterized in that: Include: Step 1: Establish loosely coupled communication between the thread pool client and the thread pool manager: Deploy the thread pool client and thread pool manager in a distributed environment, use the ZooKeeper tool to build a publish-subscribe system in the distributed environment, define the manager as the publisher, and the client as the subscriber; integrate the client into the application and monitor changes in data nodes in ZooKeeper; the manager exposes an interface for receiving data to the client; Step 2: Initialize the application's thread pool using the client: Encapsulate the Java native thread pool implementation class in the client Jar package; when the application starts, access the API provided by the Jar package, call the implementation class to create a thread pool, and initialize the thread pool configuration; Step 3: The client periodically collects and reports thread pool operation data: The client collects thread pool operation data, uses the HTTP protocol, calls the interface exposed by the management end, and reports the operation data to the management end; the operation data includes instantaneous data and cumulative data; the instantaneous data refers to the data collected only when reporting, including the application name, client IP, thread pool name and corresponding thread pool working parameters; the cumulative data refers to the cumulative number of times the thread pool executes tasks, including the number of successful executions and the number of failed executions; the cumulative number is saved in the memory after each update; Step 4: Parameter Saving and Dynamic Modification: After the management end receives the running data in step 3, it saves and records the application name, client IP, thread pool name, and corresponding thread pool working parameters; using the thread pool name and client IP recorded by the management end, the user searches for the specified thread pool and modifies the thread pool working parameters; based on the publish-subscribe system in step 1, the management end pushes the modified working parameters to ZooKeeper and saves them in the data node corresponding to the thread pool name, waiting for the client to pull them; Step 5: Thread pool early warning monitoring: The server extracts the number of active threads and the maximum number of threads from the running data, and calculates the thread activity according to Formula 1; Extract the used queue length and idle queue length, and calculate the queue load according to Formula 2. Extract the number of task execution failures and calculate the rejection increment value according to Formula 3; if any of the above values exceeds the warning threshold, the management end sends a warning message to the user through the predetermined notification method; Formula 1: Thread activity = number of active threads / maximum number of threads; Formula 2: Queue load = used queue length / (used queue length + idle queue length); Formula 3: Rejection increment value = number of task execution failures - number of previous task execution failures.
2. A thread pool monitoring and management method according to claim 1, characterized in that: In step 1, the client Jar package is integrated into the application code using the Maven tool. Specifically, the Jar package is integrated into the application code by specifying coordinates, where the value of the coordinate GroupId is the name of the application; the value of the coordinate ArtifactId is the name of the Jar package; and the value of the coordinate Version is the version number of the Jar package. In step 1, the management end creates a data node with the theme of "thread pool name" in the ZooKeeper, and the client subscribes to the data node.
3. A thread pool monitoring and management method as described in claim 2, characterized in that: In step 3, the interface exposed by the management terminal is called through the interface address, and the interface address is configured in advance in the configuration file of the client; In step 3, the reporting frequency is preferably 1 time / min; the accumulated data is not cleared after the reporting is completed.
4. A thread pool monitoring and management method as claimed in claim 3, characterized in that: The step 4 specifically includes: Step 4-1: The ZooKeeper data node receives the modified operating parameters. Based on the ZooKeeper tool's processing mechanism for newly received data, the data node updates the stored data, triggering a node update event. The node update event is then sent to the client. Step 4-2: After the client monitors the event, it reads the modified working parameters from the data node, calls the parameter setting method supported by the Java native "ThreadPoolExecutor" class, and dynamically modifies the thread pool working parameters.
5. A thread pool monitoring and management method according to claim 4, characterized in that: In step 4, the threshold of the queue load is 60%, the threshold of the thread activity is 90%, and the threshold of the rejection increment value is 0.