A method and apparatus for thread pool management

Abstract

The application discloses a thread pool management method and device, and relates to the technical field of computers. A specific implementation of the method comprises the following steps: receiving a to-be-executed task submitted by a client; distributing the to-be-executed task to a preprocessing pool in a thread pool, and obtaining index data of the to-be-executed task; determining a label corresponding to the to-be-executed task according to the index data; and distributing the to-be-executed task to a response pool corresponding to the label in the thread pool. The implementation can distribute the to-be-executed task to the response pool corresponding to the label, realize the isolated execution of to-be-executed tasks with different labels, and dynamically adjust the label corresponding to the to-be-executed task, so that the rational use of resources is realized, and the safety and reliability of the system are improved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method and apparatus for thread pool management. Background Technology

[0002] With the rapid development of internet technology, the demand for access to application systems is increasing, and the requirements for their concurrent processing capabilities are also rising. Employing multithreading technology can maximize the utilization of CPU multi-core capabilities and improve the system's parallel computing power.

[0003] Thread pool technology, by pre-creating threads, avoids the impact of frequent thread destruction on system performance. Application schemes of thread pool technology include global shared pooling. In the global shared pooling scheme, application services share a single thread pool. When threads become blocked, it can easily lead to the exhaustion of thread pool resources and inability to respond in a timely manner. Under concurrent conditions, this can easily cause cluster service unavailability and a cascading failure. Summary of the Invention

[0004] In view of this, embodiments of the present invention provide a method and apparatus for thread pool management, which can allocate tasks to be executed to response pools corresponding to tags, realize the mutual isolation execution of tasks to be executed under different tags, and dynamically adjust the tags corresponding to tasks to be executed, thereby realizing the rational utilization of resources and improving the security and reliability of system operation.

[0005] To achieve the above objectives, according to one aspect of the present invention, a method for thread pool management is provided, comprising:

[0006] Receive tasks to be executed submitted by the client;

[0007] The task to be executed is assigned to the preprocessing pool in the thread pool, and the indicator data of the task to be executed is obtained;

[0008] The label corresponding to the task to be executed is determined based on the indicator data;

[0009] The task to be executed is assigned to the response pool corresponding to the label in the thread pool.

[0010] Optionally, the indicator data is the execution time of the task to be executed obtained through the preprocessing pool, and the label corresponding to the task to be executed is determined based on the indicator data, including:

[0011] When the execution time is greater than the preset execution time threshold, the label is a first label; when the execution time is less than or equal to the preset execution time threshold, the label is a second label.

[0012] Assigning the task to be executed to the response pool corresponding to the tag in the thread pool includes:

[0013] If the label is the first label, the task to be executed is assigned to the first response pool corresponding to the first label;

[0014] If the label is the second label, the task to be executed will be assigned to the second response pool corresponding to the second label;

[0015] The preprocessing pool, the first response pool, and the second response pool are response pools within the thread pool.

[0016] Optionally, before allocating the task to be executed to the preprocessing pool in the thread pool, the following steps are included:

[0017] The task to be executed is verified according to preset rules, and the verification is confirmed to be successful.

[0018] Optionally, the metric data is the execution time of the task to be executed obtained through the preprocessing pool. After allocating the task to be executed to the response pool corresponding to the tag in the thread pool, the process includes:

[0019] Monitor the first metric data of the task to be executed in the thread pool corresponding to the label;

[0020] If the first indicator data meets the preset conditions, update the label corresponding to the task to be executed.

[0021] Optionally, the method further includes:

[0022] Before assigning the task to be executed to the preprocessing pool in the thread pool, it is determined that the task to be executed does not have a corresponding preset label;

[0023] If the task to be executed has a corresponding preset label, the task to be executed will be assigned to the response pool corresponding to the preset label.

[0024] Optionally, after allocating the task to be executed to the response pool corresponding to the tag in the thread pool, the process includes:

[0025] Monitor the operational metrics data of the response pool corresponding to the tag;

[0026] 0. Determine the operating status of the response pool corresponding to the label based on the operating indicator data.

[0027] Optionally, the operational metric data is the waiting time of the task to be executed, and determining the operational status of the response pool corresponding to the tag based on the operational metric data includes:

[0028] If the waiting time is less than a preset waiting time threshold, the operating status of the response pool corresponding to the label is determined to be normal.

[0029] If the waiting time is greater than or equal to the preset waiting time threshold, the operating status of the response pool corresponding to the tag is determined to be abnormal.

[0030] Optionally, after allocating the task to be executed to the response pool in the thread pool corresponding to the label 0, the method further includes:

[0031] Determine whether the task to be executed is executed by the core thread in the response pool corresponding to the tag within a preset time.

[0032] If so, confirm that the response pool corresponding to the tag is operating normally;

[0033] Otherwise, it is determined that the operating status of the response pool corresponding to the label is abnormal.

[0034] Optionally, after determining that the operating status of the response pool corresponding to the tag is abnormal, the method further includes:

[0035] Send an expansion request to the resource allocation center, so that the resource allocation center returns expansion parameter data corresponding to the expansion request if it determines that there are resources corresponding to the expansion request;

[0036] In response to receiving the expansion parameter data, the core parameters in the response pool corresponding to the tag are adjusted. The core parameters include at least one of the core thread count, maximum thread count, and blocking queue capacity.

[0037] According to another aspect of the present invention, an apparatus for thread pool management is provided, comprising:

[0038] The receiving module receives tasks submitted by the client.

[0039] The acquisition module allocates the task to be executed to the preprocessing pool in the thread pool and acquires the indicator data of the task to be executed.

[0040] The determination module determines the tag corresponding to the task to be executed based on the indicator data;

[0041] The allocation module allocates the task to be executed to the response pool corresponding to the tag in the thread pool.

[0042] According to another aspect of the present invention, an electronic device is provided, comprising:

[0043] One or more processors;

[0044] Storage device for storing one or more programs.

[0045] When the one or more programs are executed by the one or more processors, the one or more processors implement the thread pool management method provided by the present invention.

[0046] According to another aspect of the present invention, a computer-readable medium is provided having a computer program stored thereon, which, when executed by a processor, implements the thread pool management method provided by the present invention.

[0047] One embodiment of the above invention has the following advantages or beneficial effects: after receiving the task to be executed submitted by the client, the task to be executed is allocated to the preprocessing pool, the indicator data of the task to be executed is obtained, and the label corresponding to the task to be executed is determined according to the indicator data. This realizes the allocation of the task to be executed to the response pool corresponding to the label, realizes the mutual isolation execution of the tasks to be executed with different labels, and can realize the dynamic adjustment of the label corresponding to the task to be executed, thereby realizing the rational use of resources and improving the security and reliability of system operation.

[0048] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description

[0049] The accompanying drawings are provided to better understand the invention and are not intended to unduly limit the scope of the invention. Wherein:

[0050] Figure 1 This is a schematic diagram of the main flow of a thread pool management method according to an embodiment of the present invention;

[0051] Figure 2 This is a schematic diagram of the main flow of another thread pool management method according to an embodiment of the present invention;

[0052] Figure 3 This is a schematic diagram of the main flow of another thread pool management method according to an embodiment of the present invention;

[0053] Figure 4 This is a schematic diagram of the main flow of another thread pool management method according to an embodiment of the present invention;

[0054] Figure 5 This is a schematic diagram of the main modules of a thread pool management device according to an embodiment of the present invention;

[0055] Figure 6 This is an exemplary system architecture diagram in which embodiments of the present invention can be applied;

[0056] Figure 7This is a schematic diagram of the structure of a computer system suitable for implementing terminal devices or servers of the present invention. Detailed Implementation

[0057] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0058] Figure 1 This is a schematic diagram of the main flow of a thread pool management method according to an embodiment of the present invention, as shown below. Figure 1 As shown, the method includes the following steps:

[0059] Step S101: Receive the task to be executed submitted by the client;

[0060] Step S102: Assign the tasks to be executed to the preprocessing pool in the thread pool and obtain the metric data of the tasks to be executed;

[0061] Step S103: Determine the label corresponding to the task to be executed based on the indicator data;

[0062] Step S104: Assign the task to be executed to the response pool corresponding to the label in the thread pool.

[0063] In this embodiment of the invention, the thread pool management method is used to manage the thread pool and its sub-pools, including a preprocessing pool, a first response pool, and a second response pool. After receiving a task to be executed submitted by a client, the task needs to be allocated to the corresponding response pool and executed using threads within that pool. Before allocating the task to the corresponding response pool, it needs to be processed in the preprocessing pool (prePool) to obtain the task's metrics data.

[0064] In this embodiment of the invention, before allocating the task to be executed to the preprocessing pool in the thread pool, the process includes: verifying the task according to preset rules and confirming that the verification passes. That is, after receiving the task submitted by the client, and confirming that the verification passes, the task is then allocated to the preprocessing pool. The preset rules can be custom rules, including built-in naming conventions, thread routing rules, etc. For example, it can verify whether the task name conforms to the built-in naming convention (i.e., naming format). It can also verify whether the task conforms to the default routing rule, that is, whether the task is allocated to the response pool based on the size of the indicator data and the preset threshold. If so, it is allocated according to the default routing rule; if not, it is verified whether the task conforms to the filtering rule, that is, whether the task is a task that does not consider the preset threshold. If the task conforms to the filtering rule, it is allocated to the custom response pool; if it does not conform to the filtering rule, the verification fails. The custom response pool is a custom pool within the thread pool that can be used to process tasks that conform to the filtering rules.

[0065] In this embodiment of the invention, the indicator data is the execution time of the task to be executed obtained through the preprocessing pool. The label corresponding to the task to be executed is determined according to the indicator data, including: when the execution time is greater than a preset execution time threshold, the label is a first label; when the execution time is less than or equal to the preset execution time threshold, the label is a second label.

[0066] In this embodiment of the invention, after the task to be executed passes the verification, before allocating the task to be executed to the preprocessing pool in the thread pool, the task to be executed is converted into a custom wrapper class RunnableWrapper and CallableWrapper. The task to be executed after the conversion of the custom wrapper class is submitted to the thread pool. After the task to be executed is converted by the custom wrapper class, the custom wrapper class can record task information such as task name, task creation event, execution time, waiting time, and application to which the task belongs. The above task information can be obtained by monitoring the task to be executed.

[0067] The metric data for tasks to be executed can be the execution time obtained from the preprocessing pool, i.e., the time required to complete the task in the preprocessing pool. When a task is submitted to the thread pool, it is first allocated to the preprocessing pool for processing to obtain its execution time. Specifically, the execution time of the task in the preprocessing pool is monitored and obtained within a preset execution period. If the preset execution period is the number of times the task is completed, the average execution time obtained from multiple executions can be used as the task's execution time. After determining the execution time, it is compared with a preset execution time threshold, which can be customized. If the execution time is greater than the preset threshold, it indicates a longer execution time, and a first label (e.g., a "tortise" label) indicating a longer execution time can be assigned to it. If the execution time is less than or equal to the preset threshold, it indicates a shorter execution time, and a second label (e.g., a "rabbit" label) indicating a shorter execution time can be assigned to it. By comparing the execution time with a preset execution time threshold, the label corresponding to the task to be executed is determined, and the task to be executed can be assigned according to the label.

[0068] In this embodiment of the invention, allocating the task to be executed to the response pool corresponding to the label in the thread pool includes:

[0069] If the tag is the first tag, the task to be executed will be assigned to the first response pool corresponding to the first tag;

[0070] If the tag is the second tag, the task to be executed will be assigned to the second response pool corresponding to the second tag;

[0071] Among them, the preprocessing pool, the first response pool, and the second response pool are response pools in the thread pool.

[0072] After determining the tag corresponding to the task to be executed, the task is assigned to the corresponding response pool according to the tag. The first tag corresponds to the first response pool (slow response pool, tortoisePool), and the second tag corresponds to the second response pool (fast response pool, rabbitPool), thereby realizing the dynamic allocation of tasks submitted by the client.

[0073] In this embodiment of the invention, the indicator data of the task to be executed can be data such as the task creation time, the application to which the task belongs, or other custom indicator data. By monitoring and obtaining the indicator data of the task to be executed and comparing it with the preset indicator data threshold, the task to be executed can be tagged and the task to be executed submitted by the client can be initially allocated.

[0074] In this embodiment of the invention, the indicator data is the execution time of the task to be executed obtained through the preprocessing pool. After allocating the task to be executed to the response pool corresponding to the label in the thread pool, the process includes:

[0075] Monitor the first metric data of the task to be executed in the thread pool corresponding to the label;

[0076] If the first indicator data meets the preset conditions, update the label corresponding to the task to be executed.

[0077] In this embodiment of the invention, when the indicator data is the execution time of the task to be executed obtained through the preprocessing pool, the first indicator data can be the first execution time of the task to be executed in the response pool corresponding to its label. The preset condition can be that if the execution time is greater than a preset execution time threshold, the first execution time is less than or equal to a preset waiting time threshold; or, if the execution time is less than or equal to a preset execution time threshold, the first execution time is greater than a preset execution time threshold. If the first indicator data meets the preset condition, the label corresponding to the task to be executed is updated. That is, if the label corresponding to the task to be executed is the first label and the first execution time is less than or equal to the preset execution time threshold, the label corresponding to the task to be executed is updated to the second label; if the label corresponding to the task to be executed is the second label and the first execution time is greater than the preset execution time threshold, the label corresponding to the task to be executed is updated to the first label. For example, if the task to be executed has a long execution time in the preprocessing pool, its corresponding label is determined to be a slow label, and it is thus assigned to the slow response pool for execution. If the execution time in the slow response pool is found to be shorter, its corresponding label is updated from a slow label to a fast label, so that it can be assigned to the fast response pool according to the fast label.

[0078] In this embodiment of the invention, if the indicator data is the execution time of the task to be executed obtained through the preprocessing pool, it is also possible to monitor multiple first indicator data, such as the first execution time, of the task to be executed in the response pool corresponding to the tag within a preset time range. If the execution time is greater than a preset execution time threshold, and multiple first execution times are all less than the preset execution time threshold, or if the execution time is less than or equal to the preset execution time threshold, and multiple first execution times are all greater than the preset execution time threshold, then the tag corresponding to the task to be executed is updated. That is, if the execution time of the task to be executed in the slow response pool is shorter than the execution time obtained in the preprocessing pool, then the tag corresponding to the task to be executed is updated from a slow tag to a fast tag, so that it can be subsequently allocated to the fast response pool.

[0079] In this embodiment of the invention, the method further includes: determining that the task to be executed does not have a corresponding preset tag before allocating it to the preprocessing pool in the thread pool; and allocating the task to be executed to the response pool corresponding to the preset tag if the task to be executed has a corresponding preset tag. That is, after receiving a task to be executed submitted by the client, it is determined whether the task to be executed has a corresponding preset tag. If it does, the task to be executed is allocated to the response pool corresponding to the preset tag; otherwise, it is allocated to the preprocessing pool. For example, if the task to be executed has a corresponding first tag, it is allocated to the first response pool; if it has a corresponding second tag, it is allocated to the second response pool; and if it does not have a corresponding tag, it is allocated to the preprocessing pool.

[0080] In embodiments of the present invention, such as Figure 2 As shown, after assigning the tasks to be executed to the response pool corresponding to the label in the thread pool, the process includes:

[0081] Step S201: Monitor the operational metrics data of the response pool corresponding to the tag;

[0082] Step S202: Determine the operating status of the response pool corresponding to the tag based on the operating indicator data.

[0083] In this embodiment of the invention, the core parameters of the thread pool include the core thread count, the maximum thread count, and the task blocking queue length. They may also include parameters such as idle thread survival time, thread factory, and rejection policy. The core thread count is the minimum thread count, which can be initialized in the response pool according to preset rules. These preset rules can be based on the application type (CPU-intensive, I / O-intensive). For example, if the application type is CPU-intensive, then the core thread count = number of CPU cores * (1 + I / O / CPU); if the application type is I / O-intensive, then the core thread count = number of CPU cores + 1.

[0084] In this embodiment of the invention, the core parameters can be implemented using a custom class that extends the thread pool of the JDK (Java Development Kit). This custom class allows for dynamic adjustment of the core thread count, maximum thread count, and blocking queue length. It also enables the implementation of a custom dynamic response pool and the extension of response pool parameters, such as the response pool ID, and the creation of a custom thread rejection policy. Specifically, the custom thread rejection policy can be implemented by returning a system busy message to the client when all core threads in the response pool are running, the maximum core thread count reaches its maximum value, and the blocking queue length reaches its maximum value (i.e., maximum resource utilization is achieved).

[0085] The runtime metrics of the response pool are monitored by using a custom wrapper class AbstractWrapper. These metrics include the creation time, waiting time, execution time, and response pool ID of threads in the response pool, as well as metrics for tasks to be executed in the response pool, such as the thread name executing the task, the waiting time of the task in the blocking queue, the execution time of the task, and the task name.

[0086] By monitoring the operational metrics data of the response pool corresponding to a tag, the operational status of the response pool corresponding to the tag can be determined. If the operational metric data is the waiting time of the tasks to be executed, the operational status of the response pool corresponding to the tag can be determined based on the operational metric data, including: if the waiting time is less than a preset waiting time threshold, the operational status of the response pool corresponding to the tag is determined to be normal; if the waiting time is greater than or equal to the preset waiting time threshold, the operational status of the response pool corresponding to the tag is determined to be abnormal. The waiting time of the tasks to be executed refers to the queuing time of the tasks in the blocking queue. If the waiting time is short, it means that the tasks can be executed within the preset waiting time threshold range, and the impact is acceptable, so the operational status of the response pool is normal. If the waiting time is long, it means that there are many tasks queuing in the blocking queue or that the task execution time is long, which will not only affect the execution of the task but also the execution of subsequent tasks submitted to the response pool, in which case the operational status of the response pool is abnormal.

[0087] In embodiments of the present invention, such as Figure 3 As shown, after allocating the tasks to be executed to the response pool corresponding to the label in the thread pool, the process also includes:

[0088] Step S301: Determine whether the task to be executed is executed by the core thread in the response pool corresponding to the tag within the preset time; if yes, proceed to step S302; if no, proceed to step S303.

[0089] Step S302: Confirm that the response pool corresponding to the tag is operating normally;

[0090] Step S303: Determine that the running status of the response pool corresponding to the tag is abnormal.

[0091] In this embodiment of the invention, if the task to be executed is assigned to a core thread in the response pool for execution within a preset time, such as being executed immediately, it indicates that there are core threads available in the response pool and the response pool is running normally. Alternatively, if it is not executed immediately but waits in the blocking queue, it indicates that there are no core threads available when the task to be executed is assigned to the response pool. If it is available for execution within the preset time, it indicates that the task to be executed has not been waiting in the blocking queue for long, and the impact is small, and the running state is normal. If it is not executed within the preset time, it indicates that the task to be executed has been waiting in the blocking queue for too long, which will affect the execution of the task, and the running state is abnormal.

[0092] In embodiments of the present invention, such as Figure 4 As shown, after determining that the response pool corresponding to the tag is in an abnormal running state, the process also includes:

[0093] Step S401: Send an expansion request to the resource allocation center so that the resource allocation center returns expansion parameter data corresponding to the expansion request if it determines that there are resources corresponding to the expansion request;

[0094] Step S402: In response to receiving expansion parameter data, adjust the core parameters in the response pool corresponding to the tag. The core parameters include at least one of the core thread count, maximum thread count, and blocking queue length.

[0095] In this embodiment of the invention, when the operating status of the response pool corresponding to a tag becomes abnormal, the response pool needs to send a scaling request to the resource allocation center. Upon receiving the scaling request, the resource allocation center determines whether the corresponding resources exist. If they do, it returns the corresponding scaling parameter data. After receiving the scaling parameter data, the response pool adjusts the core parameters in the response pool to improve the execution efficiency of tasks within the response pool. If the resources do not exist, a rule alarm is triggered, indicating that the administrator server resources cannot meet the scaling request, and cluster scaling is required. The scaling parameter data can be the number of core threads to be increased, the maximum number of threads, or the length of the blocking queue, and can also be customized to add response pools. By dynamically adjusting the core parameters in the response pool, reasonable resource utilization is achieved. This overcomes the problem in existing business line isolation pooling technologies where each thread pool has fixed parameters set manually based on experience. Inappropriate parameter settings can lead to frequent creation and destruction of threads in the thread pool, resulting in either excessive idleness or excessive busyness, causing resource waste.

[0096] In this embodiment of the invention, the operational metrics data of the monitoring response pool are analyzed. If a large number of tasks in the fast response pool experience excessively long waiting times, a scaling request is sent to the resource allocation center. The resource allocation center calculates and determines whether there are resources available for scaling. If so, scaling parameters are issued; otherwise, a rule-based alarm is triggered to notify the administrator. The resource allocation center enables adaptive adjustment of the thread pool's core parameters, achieving reasonable and efficient scheduling of thread pool resources. This avoids issues of threads being too busy or too idle in the thread pool, ensuring full utilization of server resources and improving system security and reliability.

[0097] The thread pool management method provided in this invention determines the label corresponding to the task to be executed based on the indicator data of the task to be executed, thereby allocating tasks to be executed with different labels to different response pools for execution, realizing thread isolation and execution, and dynamically adjusting the label corresponding to the task to be executed by monitoring the first indicator data of the tasks to be executed in the response pool.

[0098] Reduce the impact of external temporary factors on the tags corresponding to the tasks to be executed. Tasks to be executed are dynamically allocated to the corresponding response pools based on their tags. By monitoring the operational metrics of the response pools, when the number of threads in the response pools cannot meet the demand, resource expansion can be proactively requested from the resource allocation center. This allows for dynamic adjustment of core parameters in the response pools, thereby improving task execution efficiency. It also addresses the potential avalanche phenomenon in existing global thread pools and the issues of frequent thread creation and destruction, excessively busy or idle threads in business-isolated threads due to unreasonable parameter settings. This achieves rational resource utilization and improves system security and reliability.

[0099] like Figure 5 As shown, in another aspect of this embodiment of the invention, a thread pool management apparatus 500 is provided, comprising:

[0100] The receiving module 501 receives the tasks to be executed submitted by the client;

[0101] The acquisition module 502 allocates the tasks to be executed to the preprocessing pool in the thread pool and acquires the metric data of the tasks to be executed.

[0102] Module 503 determines the label corresponding to the task to be executed based on the indicator data;

[0103] The allocation module 504 allocates the tasks to be executed to the response pool corresponding to the label in the thread pool.

[0104] In this embodiment of the invention, the indicator data is the execution time of the task to be executed obtained through the preprocessing pool. The determination module 503 is further used to: when the execution time is greater than a preset execution time threshold, the label is a first label; when the execution time is less than or equal to the preset execution time threshold, the label is a second label.

[0105] The allocation module 504 is further configured to: allocate the task to be executed to the first response pool corresponding to the first label when the label is the first label;

[0106] If the tag is the second tag, the task to be executed will be assigned to the second response pool corresponding to the second tag;

[0107] Among them, the preprocessing pool, the first response pool, and the second response pool are response pools in the thread pool.

[0108] In this embodiment of the invention, the thread pool management device 500 further includes a verification module, used to: verify the task to be executed according to preset rules before allocating the task to be executed to the preprocessing pool in the thread pool, and determine that the verification is successful.

[0109] In this embodiment of the invention, the indicator data is the execution time of the task to be executed obtained through the preprocessing pool. The thread pool management device 500 also includes a monitoring module, which is used to: after allocating the task to be executed to the response pool corresponding to the label in the thread pool, monitor the first indicator data of the task to be executed in the thread pool corresponding to the label; and update the label corresponding to the task to be executed when the first indicator data meets the preset conditions.

[0110] In this embodiment of the invention, the acquisition module 502 is further configured to: determine that the task to be executed does not have a corresponding preset label before allocating the task to be executed to the preprocessing pool in the thread pool; and allocate the task to be executed to the response pool corresponding to the preset label when the task to be executed has a corresponding preset label.

[0111] In this embodiment of the invention, the monitoring module is further configured to: after allocating the task to be executed to the response pool corresponding to the tag in the thread pool, monitor the running indicator data of the response pool corresponding to the tag; and determine the running status of the response pool corresponding to the tag based on the running indicator data.

[0112] In this embodiment of the invention, the running indicator data is the waiting time of the task to be executed. The determining module 503 is further used to: determine that the running status of the response pool corresponding to the tag is normal when the waiting time is less than a preset waiting time threshold; and determine that the running status of the response pool corresponding to the tag is abnormal when the waiting time is greater than or equal to the preset waiting time threshold.

[0113] In this embodiment of the invention, the monitoring module is further configured to: after allocating the task to be executed to the response pool corresponding to the tag in the thread pool, determine whether the task to be executed is executed by the core thread in the response pool corresponding to the tag within a preset time; if so, determine that the running status of the response pool corresponding to the tag is normal; otherwise, determine that the running status of the response pool corresponding to the tag is abnormal.

[0114] In this embodiment of the invention, the monitoring module is further configured to: after determining that the operating status of the response pool corresponding to the tag is abnormal, send a capacity expansion request to the resource allocation center, so that the resource allocation center returns the capacity expansion parameter data corresponding to the capacity expansion request if it determines that there are resources corresponding to the capacity expansion request; in response to receiving the capacity expansion parameter data, adjust the core parameters in the response pool corresponding to the tag, the core parameters including at least one of the core thread count, the maximum thread count, and the blocking queue capacity.

[0115] Another aspect of the present invention provides an electronic device, including: one or more processors; and a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the thread pool management method of the present invention.

[0116] Another aspect of the present invention provides a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the thread pool management method of the present invention.

[0117] Figure 6 An exemplary system architecture 600 is shown, to which the thread pool management method or apparatus of embodiments of the present invention can be applied.

[0118] like Figure 6 As shown, system architecture 600 may include terminal devices 601, 602, and 603, a network 604, and a server 605. Network 604 serves as the medium for providing communication links between terminal devices 601, 602, and 603 and server 605. Network 604 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0119] Users can use terminal devices 601, 602, and 603 to interact with server 605 via network 604 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 601, 602, and 603, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0120] Terminal devices 601, 602, and 603 can be various electronic devices with displays and web browsing capabilities, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0121] Server 605 can be a server that provides various services, such as a backend management server that supports shopping websites browsed by users using terminal devices 601, 602, and 603 (for example only). The backend management server can analyze and process data such as received product information query requests, and feed back the processing results (such as target push information, product information - for example only) to the terminal devices.

[0122] It should be noted that the thread pool management method provided in this embodiment of the invention is generally executed by server 605, and correspondingly, the thread pool management device is generally set in server 605.

[0123] It should be understood that Figure 6 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0124] The following is for reference. Figure 7 It shows a schematic diagram of the structure of a computer system 700 suitable for implementing a terminal device of the present invention. Figure 7 The terminal device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0125] like Figure 7 As shown, the computer system 700 includes a central processing unit (CPU) 701, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 702 or programs loaded from storage section 708 into random access memory (RAM) 703. The RAM 703 also stores various programs and data required for the operation of the system 700. The CPU 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0126] The following components are connected to the I / O interface 705: an input section 706 including a keyboard, mouse, etc.; an output section 707 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN card, modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the I / O interface 705 as needed. A removable medium 711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 710 as needed so that computer programs read from it can be installed into the storage section 708 as needed.

[0127] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 709, and / or installed from removable medium 711. When the computer program is executed by central processing unit (CPU) 701, it performs the functions defined above in the system of this invention.

[0128] It should be noted that the computer-readable medium shown in this invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0129] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0130] The modules described in the embodiments of the present invention can be implemented in software or hardware. The described modules can also be housed in a processor; for example, a processor can be described as including a receiving module, an acquisition module, a determining module, and an allocation module. The names of these modules do not necessarily limit the module itself; for example, the receiving module can also be described as "receiving tasks submitted by a client."

[0131] In another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs, which, when executed by the device, cause the device to include: receiving a task to be executed submitted by a client; allocating the task to be executed to a preprocessing pool in a thread pool; obtaining indicator data of the task to be executed; determining a tag corresponding to the task to be executed based on the indicator data; and allocating the task to be executed to a response pool in the thread pool corresponding to the tag.

[0132] According to the technical solution of the present invention, the provided thread pool management method determines the label corresponding to the task to be executed based on the indicator data of the task to be executed, thereby allocating tasks to be executed with different labels to different response pools for execution, realizing the isolation of threads for execution, and dynamically adjusting the label corresponding to the task to be executed by monitoring the first indicator data of the task to be executed in the response pool, reducing the impact of external temporary factors on the label corresponding to the task to be executed. By dynamically allocating the task to be executed to the response pool corresponding to the label, and by monitoring the running indicator data of the response pool, when the threads in the response pool cannot meet the demand, the method can actively request resource expansion from the resource allocation center to realize the dynamic adjustment of the core parameters in the response pool, thereby improving the execution efficiency of the task, solving the avalanche phenomenon that may occur in the global thread pool in the prior art, and the phenomenon of frequent thread creation and destruction, excessively busy or idle threads due to unreasonable parameter settings in business isolation threads, realizing the rational utilization of resources and improving the security and reliability of the system.

[0133] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for managing thread pools, characterized in that, include: Receive tasks to be executed submitted by the client; The task to be executed is assigned to the preprocessing pool in the thread pool, and the indicator data of the task to be executed is obtained; the indicator data is the execution time of the task to be executed obtained through the preprocessing pool. The label corresponding to the task to be executed is determined based on the indicator data; The task to be executed is assigned to the response pool in the thread pool corresponding to the label; The tags corresponding to the tasks to be executed are determined based on the aforementioned indicator data, including: When the execution time is greater than a preset execution time threshold, the label is a first label; when the execution time is less than or equal to the preset execution time threshold, the label is a second label. Assigning the task to be executed to the response pool corresponding to the tag in the thread pool includes: If the label is the first label, the task to be executed is assigned to the first response pool corresponding to the first label; If the label is the second label, the task to be executed is assigned to the second response pool corresponding to the second label.

2. The method according to claim 1, characterized in that, The preprocessing pool, the first response pool, and the second response pool are response pools within the thread pool.

3. The method according to claim 1, characterized in that, Before assigning the task to be executed to the preprocessing pool in the thread pool, the process includes: The task to be executed is verified according to preset rules, and the verification is confirmed to be successful.

4. The method according to claim 1, characterized in that, The metric data refers to the execution time of the task to be executed obtained through the preprocessing pool. After allocating the task to be executed to the response pool corresponding to the tag in the thread pool, the process includes: Monitor the first metric data of the task to be executed in the thread pool corresponding to the label; If the first indicator data meets the preset conditions, update the label corresponding to the task to be executed.

5. The method according to claim 2, characterized in that, The method further includes: Before assigning the task to be executed to the preprocessing pool in the thread pool, it is determined that the task to be executed does not have a corresponding preset label; If the task to be executed has a corresponding preset label, the task to be executed will be assigned to the response pool corresponding to the preset label.

6. The method according to claim 1, characterized in that, After assigning the task to be executed to the response pool corresponding to the tag in the thread pool, the process includes: Monitor the operational metrics data of the response pool corresponding to the tag; The operational status of the response pool corresponding to the label is determined based on the operational indicator data.

7. The method according to claim 6, characterized in that, The operational metric data represents the waiting time of the task to be executed. The operational status of the response pool corresponding to the tag is determined based on the operational metric data, including: If the waiting time is less than a preset waiting time threshold, the operating status of the response pool corresponding to the tag is determined to be normal. If the waiting time is greater than or equal to the preset waiting time threshold, the operating status of the response pool corresponding to the tag is determined to be abnormal.

8. The method according to claim 1, characterized in that, After assigning the task to be executed to the response pool corresponding to the tag in the thread pool, the process further includes: Determine whether the task to be executed is executed by the core thread in the response pool corresponding to the tag within a preset time. If so, confirm that the response pool corresponding to the tag is operating normally; Otherwise, it is determined that the operating status of the response pool corresponding to the label is abnormal.

9. The method according to claim 7 or 8, characterized in that, After determining that the response pool corresponding to the tag is in an abnormal operating state, the process also includes: Send an expansion request to the resource allocation center, so that the resource allocation center returns expansion parameter data corresponding to the expansion request if it determines that there are resources corresponding to the expansion request; In response to receiving the expansion parameter data, the core parameters in the response pool corresponding to the tag are adjusted. The core parameters include at least one of the core thread count, maximum thread count, and blocking queue capacity.

10. A device for thread pool management, characterized in that, include: The receiving module receives tasks submitted by the client. The acquisition module allocates the task to be executed to the preprocessing pool in the thread pool and acquires the indicator data of the task to be executed; the indicator data is the execution time of the task to be executed obtained through the preprocessing pool. The determination module determines the tag corresponding to the task to be executed based on the indicator data; The allocation module allocates the task to be executed to the response pool corresponding to the tag in the thread pool; The determining module is further configured to: when the execution time is greater than a preset execution time threshold, the label is a first label; when the execution time is less than or equal to the preset execution time threshold, the label is a second label. The allocation module is further configured to: when the tag is a first tag, allocate the task to be executed to a first response pool corresponding to the first tag; and when the tag is a second tag, allocate the task to be executed to a second response pool corresponding to the second tag.

11. An electronic device, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-9.

12. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-9.

Images