An exception handling method, system and medium of a thread pool

Abstract

The application discloses a kind of thread pool exception handling method, system and equipment, the method is: if the running state data of the thread pool of acquisition target service exceeds preset exception threshold, acquisition call link data and resource utilization;Running state data, call link data and resource utilization are input to the preset decision tree model, by first judgment layer, resource utilization is compared with resource utilization baseline interval, to determine resource occupation state determination result, by second judgment layer, according to resource occupation state determination result, call link data is analyzed, to determine the quality of service of dependent service category, by third judgment layer, comprehensive running state data and service quality category are analyzed, and the thread pool exception type is obtained;Based on thread pool exception type, generate disposal strategy to dispose thread pool.Therefore, the application can accurately dispose thread pool exception in microservice architecture.

Description

Technical Field

[0001] This invention relates to the field of exception handling, and in particular to an exception handling method, system, and medium for thread pools. Background Technology

[0002] In a microservice architecture, the thread pool, as a core component coordinating concurrent requests and limited computing resources, directly impacts service throughput, response time, and overall stability. Thread pool anomalies (such as task backlog or frequent rejections) are not isolated events; they can be a direct manifestation of internal system bottlenecks or a chain reaction triggered by sudden upstream traffic surges or downstream dependency failures. Failure to identify and address these anomalies promptly and accurately can lead to anything from minor service performance degradation and a poor user experience to severe service failures due to thread resource exhaustion, which can then rapidly spread through synchronous call chains, potentially causing a system-wide application collapse. Therefore, automated and intelligent root cause diagnosis and precise handling of thread pool anomalies are crucial for ensuring the resilience of microservice architectures, achieving fault self-healing, and maintaining business continuity.

[0003] Existing technologies typically rely on preset single-dimensional threshold alarms (such as thread pool queue length or task rejection count) to identify anomalies, and the handling methods are mostly fixed strategies based on experience, such as restarting the service or simple scaling up. This approach has fundamental flaws in terms of accuracy: First, it lacks root cause analysis, failing to distinguish whether the anomaly stems from its own code defects, downstream service latency, or underlying resource contention, leading to a high rate of misdiagnosis. For example, when a dependent service fails, it may be misjudged as insufficient resources, resulting in blind scaling up. Second, its decision-making logic heavily depends on the manual intervention and experience-based judgment of operations personnel. It requires manual analysis of monitoring metrics, logs, and link data, resulting in slow response times and subjective conclusions. In complex distributed interaction scenarios, it is difficult to guarantee the accuracy, timeliness, and consistency of handling strategies, often addressing only the symptoms and not the root cause, and may even amplify the impact of the failure due to improper handling. Summary of the Invention

[0004] This invention provides a method, system, and medium for handling exceptions in thread pools, which can accurately handle thread pool exceptions in microservice architectures.

[0005] This invention provides an exception handling mechanism for thread pools, including: Collect runtime status data of the target service's thread pool; If the running status data exceeds the preset abnormal threshold, the call chain data corresponding to the target dependent service of the target service and the resource utilization rate of the server where the target service is located are collected. The running status data, the call chain data, and the resource utilization rate are input into a preset decision tree model. The first judgment layer in the decision tree model compares the resource utilization rate with the resource utilization rate baseline range to determine the resource occupancy status judgment result. The second judgment layer in the decision tree model analyzes the call chain data based on the resource occupancy status judgment result to determine the service quality category of the dependent service. The third judgment layer in the decision tree model analyzes the running status data and the service quality category in combination to obtain the thread pool exception type. The resource utilization rate baseline range is determined based on historical normal operation data. Based on the thread pool exception type, a handling strategy matching the thread pool exception type is generated, and the thread pool is handled according to the handling strategy.

[0006] This invention constructs a multi-dimensional foundation for anomaly analysis by comprehensively collecting thread pool running status, server resource utilization, and external dependent service call chain data. This overcomes the limitations of relying solely on thread pool metrics and provides comprehensive data support for accurate attribution. Secondly, a preset anomaly threshold triggering mechanism ensures that analysis actions are initiated only when there are definite abnormal signs, avoiding resource waste from continuous monitoring and improving the efficiency and targeting of the handling system. Furthermore, a preset three-layer decision tree model is used for collaborative analysis: the first judgment layer compares real-time resource utilization with a baseline range determined based on historical data to achieve precise quantification and qualitative analysis of server resource occupancy, identifying different scenarios such as resource abundance, scarcity, or competition; the second judgment layer adaptively adopts different strategies (such as analyzing failure rate, response time, or asynchronous call completion rate) based on resource occupancy status to address the issues of dependent services. The system diagnoses service call chain data to accurately distinguish service quality categories such as offline service anomalies, performance degradation, or resource contention, effectively isolating the impact of external dependencies on the thread pool state. The third judgment layer combines the thread pool's own runtime status data (such as full load and rejection frequency) with the aforementioned service quality categories to make a final logical judgment, accurately identifying different fundamental anomaly types such as systemic resource exhaustion, external dependency blocking pseudo-saturation, resource contention-related mixed saturation, and computing resource exhaustion-related true saturation, achieving precise location from phenomenon to root cause. Finally, based on the accurately identified anomaly types, a matching handling strategy is generated and executed, enabling handling actions (such as scaling, circuit breaking, and parameter tuning) to directly address the core issues, avoiding ineffective or harmful operations due to misjudgment, thereby significantly improving the accuracy, automation level, and overall system stability of thread pool anomaly handling under the microservice architecture.

[0007] Further, the resource utilization baseline range includes a low occupancy baseline range, a medium occupancy baseline range, and a high occupancy baseline range; the resource occupancy status judgment result includes a low occupancy status, a medium occupancy status, and a high occupancy status; and the step of comparing the resource utilization rate with the resource utilization baseline range through the first judgment layer in the decision tree model to determine the resource occupancy status judgment result includes: The target indicator value of the currently collected resource utilization rate is extracted through the first judgment layer in the decision tree model; The target index value is compared with the low occupancy baseline area, the medium occupancy baseline area, and the high occupancy baseline area; If the target index value falls within the low occupancy baseline area, the resource occupancy status judgment result is determined to be the low occupancy status; If the target index value falls into the high occupancy baseline area, the resource occupancy status judgment result is determined to be the high occupancy status; If the target indicator value falls within the medium occupancy baseline area, the resource occupancy status judgment result is determined to be the medium occupancy status.

[0008] The first judgment layer compares the real-time resource utilization rate with the baseline range determined based on historical data to achieve accurate quantification and qualitative analysis of the server resource occupancy status, and identify different scenarios such as resource abundance, shortage, or competition.

[0009] Furthermore, the baseline range for resource utilization is determined based on historical normal operation data and includes: Obtain time-series data of resource utilization rate of the target service within a historical preset period, as the historical normal operation data; The historical normal operation data is statistically distributed to obtain the first quantile value and the second quantile value, wherein the first quantile value is lower than the second quantile value. The interval below the first quantile value is defined as the low occupancy baseline region, the interval above the second quantile value is defined as the high occupancy baseline region, and the interval between the first quantile value and the second quantile value is defined as the medium occupancy baseline region.

[0010] The second judgment layer adaptively adopts different strategies (such as analyzing failure rate, response time, or asynchronous call completion rate) to diagnose the call chain data of dependent services based on the resource occupancy status, thereby accurately distinguishing service quality categories such as offline service anomalies, performance degradation, or resource contention, and effectively removing the influence of external dependency factors on the thread pool state.

[0011] Furthermore, the step of analyzing the call chain data based on the resource occupancy status judgment result through the second judgment layer in the decision tree model to determine the service quality category of the dependent service includes: If the resource occupancy status judgment result is a low occupancy status, the second judgment layer in the decision tree model will statistically analyze the call failure rate and average response time of the target dependent service within a preset analysis window from the call link data. If the call failure rate is greater than the first failure rate threshold, or the average response time is greater than the first response time threshold, then the service quality category of the target dependent service is determined to be the dependent service anomaly category. Otherwise, the service quality category of the target dependent service is determined to be the normal category of dependent services.

[0012] Furthermore, the step of analyzing the call chain data based on the resource occupancy status judgment result through the second judgment layer in the decision tree model to determine the service quality category of the dependent service includes: If the resource occupancy status judgment result is a high occupancy status, the second judgment layer in the decision tree model will statistically analyze the call success rate and response time of the target dependent service within a preset analysis window from the call link data. If the success rate of the call is greater than the success rate threshold and the response time is less than the second response time threshold, then the service quality category of the target dependent service is determined to be the normal category of the dependent service. Otherwise, the service quality category of the target dependent service is determined to be the dependent service anomaly category.

[0013] Furthermore, the step of analyzing the call chain data based on the resource occupancy status judgment result through the second judgment layer in the decision tree model to determine the service quality category of the dependent service includes: If the resource occupancy status judgment result is medium occupancy status, the second judgment layer in the decision tree model calculates the asynchronous call completion rate based on the call link data; Based on the running status data, calculate the difference between the task submission rate and the task completion rate; If the asynchronous call completion rate is between the lower limit and the upper limit of the asynchronous call completion rate, and the difference is positive for multiple consecutive sampling periods, then the service quality category of the target dependent service is determined to be the resource contention category.

[0014] Furthermore, the thread pool exception types are obtained by analyzing the running status data and the service quality category through the third judgment layer in the decision tree model, including: The service quality category and the thread pool full load and task rejection frequency in the running status data are obtained through the third judgment layer in the decision tree model, and the judgment is made in the following order; If the thread pool load is higher than the load threshold and the task rejection frequency continues to exceed the rejection frequency threshold, then the thread pool exception type is determined to be systemic resource exhaustion. Otherwise, if the service quality category is the dependent service exception category and the thread pool full load exceeds the full load threshold, then the thread pool exception type is determined to be external dependency blocking pseudo saturation. Otherwise, if the service quality category is the resource contention category, then the thread pool exception type is determined to be resource contention-type mixed saturation; Otherwise, if the service quality category is the normal category of the dependent service, the thread pool full load exceeds the full load threshold, and the task rejection frequency exceeds the rejection frequency threshold, then the thread pool exception type is determined to be true saturation due to exhaustion of computing resources.

[0015] By combining the thread pool's own operational status data (such as load factor and rejection frequency) with the aforementioned service quality categories, the third judgment layer makes a final logical judgment, accurately identifying different fundamental anomaly types such as systemic resource exhaustion, external dependency blocking pseudo-saturation, resource contention-related mixed saturation, and computing resource depletion-related true saturation, thus achieving precise localization from phenomenon to root cause.

[0016] Furthermore, the step of generating a handling strategy matching the thread pool exception type based on the thread pool exception type includes: Based on the thread pool exception type, a preset handling strategy rule library is queried to match the corresponding target handling rule. The handling strategy rule library stores handling rules corresponding to different thread pool exception types. Based on the target handling rules, a handling strategy containing specific handling actions and parameters is generated.

[0017] This approach, which generates and executes matching handling strategies based on accurately identified exception types, enables handling actions (such as scaling up, circuit breaking, and parameter tuning) to directly address the core issues, avoiding ineffective or harmful operations due to misjudgments. This significantly improves the accuracy, automation level, and overall system stability of thread pool exception handling in a microservice architecture.

[0018] Another embodiment of the present invention also provides an exception handling system for a thread pool, comprising: The first acquisition module is used to collect the running status data of the thread pool of the target service; The second acquisition module is used to acquire, if the running status data exceeds a preset abnormal threshold, the call chain data corresponding to the target dependent service of the target service and the resource utilization rate of the server where the target service is located. The analysis module is used to input the running status data, the call chain data, and the resource utilization rate into a preset decision tree model. The first judgment layer in the decision tree model compares the resource utilization rate with the resource utilization rate baseline range to determine the resource occupancy status judgment result. The second judgment layer in the decision tree model analyzes the call chain data based on the resource occupancy status judgment result to determine the service quality category of the dependent service. The third judgment layer in the decision tree model analyzes the running status data and the service quality category in combination to obtain the thread pool exception type. The resource utilization rate baseline range is determined based on historical normal operation data. The handling module is used to generate a handling strategy that matches the thread pool exception type based on the thread pool exception type, and to handle the thread pool according to the handling strategy.

[0019] Another embodiment of the present invention provides a terminal device, including: a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein when the processor executes the computer program, it implements the steps of the exception handling method for the thread pool as described in the present invention. Attached Figure Description

[0020] To more clearly illustrate the technical solution of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0021] Figure 1 This is a flowchart illustrating one embodiment of the exception handling method for the thread pool provided in this application; Figure 2 This is a flowchart illustrating one embodiment of steps S201 to S205 provided in this application; Figure 3 This is a flowchart illustrating one embodiment of steps S301 to S305 provided in this application; Figure 4 This is a schematic diagram of the structure of one embodiment of the exception handling system for the thread pool provided in this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0024] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0025] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0026] In the description of the embodiments in this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0027] In the description of the embodiments of this application, the term "multiple" refers to two or more (including two), similarly, "multiple sets" refers to two or more (including two sets), and "multiple pieces" refers to two or more (including two pieces).

[0028] In the description of the embodiments of this application, unless otherwise expressly specified and limited, technical terms such as "installation," "connection," "joining," and "fixing" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. For those skilled in the art, the specific meaning of the above terms in the embodiments of this application can be understood according to the specific circumstances.

[0029] Thread pool anomalies (such as task backlog or frequent rejections) are not isolated events. They can be a direct manifestation of internal system bottlenecks or a chain reaction triggered by sudden upstream traffic surges or downstream dependency failures. Therefore, automated and intelligent root cause diagnosis and precise handling of thread pool anomalies are crucial for ensuring the resilience of microservice architectures, achieving fault self-healing, and ensuring business continuity. Existing technologies typically rely on preset single-dimensional threshold alerts (such as thread pool queue length or task rejection count) to identify anomalies, and the handling methods are mostly fixed strategies based on experience, such as restarting the service or simple scaling, which have accuracy limitations.

[0030] See Figure 1 To accurately handle thread pool exceptions in a microservice architecture, an embodiment of the present invention provides a thread pool exception handling method, including steps S101 to S104. Step S101: Collect the running status data of the thread pool of the target service; In some embodiments, the running status data of the target service (e.g., order service) thread pool is first collected periodically by calling its monitoring interface. This running status data includes the current number of active threads. Then, the current number of active threads is divided by the maximum number of threads pre-configured in the thread pool to obtain the percentage of active threads. Simultaneously, the cumulative number of task rejections within the most recent statistical time window (e.g., 5 minutes) is obtained from the thread pool's rejection policy processor. Finally, the percentage of active threads collected at a fixed frequency (e.g., every 10 seconds) and the total number of task rejections for each time window are stored together with timestamps as time-series data.

[0031] Step S102: If the running status data exceeds a preset abnormal threshold, then collect the call chain data corresponding to the target dependent service of the target service and the resource utilization rate of the server where the target service is located. In some embodiments, if the proportion of active threads continues to rise over several consecutive collection periods and the cumulative increase exceeds a first threshold (e.g., 20%), while the current proportion exceeds a second threshold (e.g., 85%), and the number of task rejections within the same time period shows an increasing trend and the absolute value exceeds a third threshold, then the thread pool is determined to be in an abnormally high-pressure state. At this time, the system performs two parallel collection operations: First, through a distributed tracing system, it queries the asynchronous call records initiated by the target service (e.g., order service) to the specified target dependent service (e.g., payment gateway). Based on the call record table, it calculates the total number of calls and the number of calls that have successfully returned responses within a preset analysis time window, obtaining the asynchronous call completion rate as key call chain data. Second, by accessing the operating system performance interface of the server where the target service resides (e.g., the / proc / stat file on a Linux system), it reads the cumulative CPU time value and calculates the average CPU idle rate within a specified time interval using the difference method between two adjacent samples, serving as the core resource utilization indicator.

[0032] Step S103: Input the running status data, the call chain data, and the resource utilization rate into a preset decision tree model. The first judgment layer in the decision tree model compares the resource utilization rate with the resource utilization baseline interval to determine the resource occupancy status judgment result. The second judgment layer in the decision tree model analyzes the call chain data based on the resource occupancy status judgment result to determine the service quality category of the dependent service. The third judgment layer in the decision tree model analyzes the running status data and the service quality category in combination to obtain the thread pool exception type. The resource utilization baseline interval is determined based on historical normal operation data.

[0033] In some embodiments, the resource utilization baseline interval is determined based on historical normal operation data, including: obtaining time-series data of the resource utilization of the target service within a historical preset period as the historical normal operation data; calculating the statistical distribution of the historical normal operation data to obtain a first quantile value and a second quantile value, wherein the first quantile value is lower than the second quantile value; defining the interval lower than the first quantile value as the low occupancy baseline region, defining the interval higher than the second quantile value as the high occupancy baseline region, and defining the interval between the first quantile value and the second quantile value as the medium occupancy baseline region.

[0034] In some embodiments, firstly, within a preset historical period (e.g., the past 30 days), the CPU idle rate of the service instance is calculated and recorded periodically (e.g., every minute) by accessing the operating system performance interface of the server where the target service resides, using the interpolation method. This forms a historical CPU idle rate time-series dataset, which serves as the historical normal operation data. Subsequently, for the collected historical dataset, after excluding known abnormal period data, the statistical distribution of all CPU idle rate sample values ​​is calculated. Based on this statistical distribution, the 25th percentile (P25) and 75th percentile (P75) are calculated, with the P25 value used as the first quantile value and the P75 value used as the second quantile value. Finally, based on the calculated first and second quantile values, the interval where the CPU idle rate is lower than the first quantile value is defined as the low occupancy baseline region (indicating high CPU activity), the interval where the CPU idle rate is higher than the second quantile value is defined as the high occupancy baseline region (indicating high CPU idleness), and the interval between the first and second quantile values ​​is defined as the medium occupancy baseline region (indicating CPU occupancy within a normal fluctuation range).

[0035] It should be noted that, in order to exclude the impact of historical sporadic failures or maintenance periods on the baseline, the historical dataset will be cleaned first based on the operation and maintenance event logs or simple threshold filtering (such as periods when the CPU idle rate is consistently below 5% or above 95%), and then the statistical distribution will be calculated.

[0036] In some embodiments, the decision tree model includes a first decision layer, a second decision layer, and a third decision layer.

[0037] In some embodiments, the training process of the preset decision tree model is as follows: First, historical training data is collected. This data includes the running status data of the target service thread pool (such as the percentage of active threads and the number of task rejections), the call chain data of the target dependent services (such as the asynchronous call completion rate and response time), and the server resource utilization rate (such as the CPU idle rate) during historical normal operation periods and various labeled abnormal periods. Each data record is labeled with its true abnormal type label (such as "external dependency blocking pseudo-saturation", "computational resource exhaustion true saturation", etc.). Subsequently, the C4.5 decision tree algorithm is used to construct the model: the algorithm recursively selects the best splitting attribute from the above features based on the information gain rate. During training, the algorithm prioritizes features with the highest discriminative power as the root or internal nodes of the decision tree. For example, resource utilization (CPU idle rate) is often selected as a high-level node (corresponding to the logic of the first judgment layer) due to its direct indication of resource occupancy status. Based on this, according to different paths of resource occupancy status, key indicators in the call chain data (such as call failure rate and response time) are selected as the next-level nodes (corresponding to the logic of the second judgment layer). Finally, at levels close to the leaf nodes, a joint judgment is made by combining runtime status data (such as thread pool full load and task rejection frequency) with the service quality category derived from the upper layer (corresponding to the logic of the third judgment layer), thereby classifying the samples to specific anomaly type leaf nodes. To improve the model's generalization ability and prevent overfitting, pessimistic error pruning and other methods are used to prune and optimize the decision tree after the tree structure is generated. The trained decision tree model then solidifies the hierarchical decision rules from resource status judgment and dependency service analysis to comprehensive judgment, and can be used for real-time data processing.

[0038] Please refer to Figure 2 In some embodiments, the resource utilization baseline range includes a low occupancy baseline range, a medium occupancy baseline range, and a high occupancy baseline range, and the resource occupancy status judgment result includes a low occupancy status, a medium occupancy status, and a high occupancy status. The step of comparing the resource utilization rate with the resource utilization baseline range through the first judgment layer in the decision tree model to determine the resource occupancy status judgment result includes steps S201 to S205: Step S201: Extract the target indicator value from the currently collected resource utilization rate through the first judgment layer in the decision tree model; In some embodiments, after the initial determination of the triggered anomaly, the input processing unit of the decision tree model locates and extracts the resource utilization data from the real-time collected multidimensional data. Then, by reading the operating system performance interface (e.g., the / proc / stat file of a Linux system) of the server where the target service is located and using the difference method between two adjacent samples, the target index value is calculated to represent the proportion of time the CPU is idle in the most recent sampling period.

[0039] Step S202: Compare the target index value with the low occupancy baseline area, the medium occupancy baseline area, and the high occupancy baseline area; In some embodiments, the current target indicator value is received and compared with three baseline interval thresholds pre-calculated and stored in the model parameters. The value relationship determines which threshold interval the current CPU idle rate falls into: whether it is less than or equal to the upper limit of the low occupancy baseline area, whether it is greater than or equal to the lower limit of the high occupancy baseline area, or whether it is between the two.

[0040] It should be noted that the upper limit of the low occupancy baseline region is the first quantile value (e.g., the 25th percentile of CPU idle rate, P25), and the lower limit of the high occupancy baseline region is the second quantile value (e.g., the 75th percentile of CPU idle rate, P75).

[0041] Step S203: If the target index value falls into the low occupancy baseline area, the resource occupancy status judgment result is determined to be the low occupancy status; In some embodiments, when the current CPU idle rate is less than or equal to the first percentile value (P25), it indicates that the value falls into the low occupancy baseline region. At this time, the first judgment layer outputs the resource occupancy status judgment result as low occupancy status.

[0042] It should be noted that this state indicates that the server's CPU resources are currently at a high level of busy, computationally intensive load, with very little idle resources. This usually corresponds to the system processing a large number of computationally intensive tasks.

[0043] Step S204: If the target index value falls into the high occupancy baseline area, the resource occupancy status judgment result is determined to be the high occupancy status; In some embodiments, when the current CPU idle rate is greater than or equal to the second quantile value (P75), it indicates that the value falls into the high occupancy baseline region. At this time, the first judgment layer outputs a resource occupancy status judgment result of high occupancy status.

[0044] It should be noted that this state indicates that the server's CPU resources are currently highly idle and the computing load is very light, with a large amount of computing power spared. This suggests that the busy thread pool may not be due to the computing tasks themselves, but rather to other factors.

[0045] Step S205: If the target index value falls within the medium occupancy baseline area, the resource occupancy status judgment result is determined to be the medium occupancy status.

[0046] In some embodiments, if the current CPU idle rate is greater than the first quantile (P25) and less than the second quantile (P75), it indicates that the value falls within the medium occupancy baseline region. In this case, the first judgment layer outputs a resource occupancy status judgment result as medium occupancy. This state indicates that the current CPU resource occupancy level of the server is in the middle of its historical normal fluctuation range; it is neither extremely busy nor extremely idle, but rather a relatively balanced state or a state with complex competition. This judgment result provides crucial intermediate state input for the subsequent second and third judgment layers.

[0047] In some embodiments, the second judgment layer in the decision tree model analyzes the call chain data based on the resource occupancy status judgment result to determine the service quality category of the dependent service: if the resource occupancy status judgment result is a low occupancy status, the second judgment layer in the decision tree model statistically analyzes the call failure rate and average response time of the target dependent service within a preset analysis window from the call chain data; if the call failure rate is greater than a first failure rate threshold, or the average response time is greater than a first response time threshold, then the service quality category of the target dependent service is determined to be the dependent service abnormal category; otherwise, the service quality category of the target dependent service is determined to be the dependent service normal category.

[0048] In some embodiments, firstly, when the resource occupancy status judgment result is a low occupancy status, the second judgment layer in the decision tree model is activated. This judgment layer first locates all asynchronous call records of the target dependent service (such as a payment gateway) within a preset analysis window (e.g., the last 5 minutes) from the input call chain data. Then, the processing unit of the second judgment layer counts the number of calls marked as failed within this window and divides it by the total number of calls to obtain the call failure rate; simultaneously, for all calls marked as successful, its response time is extracted and its arithmetic mean is calculated to obtain the average response time. Subsequently, the calculated call failure rate is compared with a preset first failure rate threshold (e.g., 20%), and the average response time is compared with a preset first response time threshold (e.g., 800 milliseconds). If the call failure rate is greater than the first failure rate threshold, or the average response time is greater than the first response time threshold, the second judgment layer outputs a judgment result, determining the service quality category of the target dependent service as an abnormal dependent service category; otherwise, its service quality category is determined as a normal dependent service category.

[0049] It should be noted that the asynchronous call records come from the call record table stored in the distributed tracing system, which contains the status (success / failure) and response time of each call.

[0050] In some embodiments, the step of analyzing the call chain data based on the resource occupancy status judgment result through the second judgment layer in the decision tree model to determine the service quality category of the dependent service includes: if the resource occupancy status judgment result is a high occupancy status, the second judgment layer in the decision tree model calculates the call success rate and response time of the target dependent service within a preset analysis window from the call chain data; if the call success rate is greater than a success rate threshold and the response time is less than a second response time threshold, then the service quality category of the target dependent service is determined to be the normal dependent service category; otherwise, the service quality category of the target dependent service is determined to be the abnormal dependent service category.

[0051] In some embodiments, when the resource occupancy status judgment result is a high occupancy status, the second judgment layer in the decision tree model is activated and executes another set of analysis logic. This judgment layer first filters all asynchronous call records of the target dependent service (such as a payment gateway) within a preset analysis window from the input call chain data. It then calculates the call success rate based on all asynchronous call records, that is, it counts the number of times the call result status is marked as successful within the window and divides it by the total number of calls to obtain the call success rate. Simultaneously, it sorts the response time values ​​of all successful calls within the window from smallest to largest and extracts the value located at the 99th percentile to obtain the response time. Subsequently, the second judgment layer compares the calculated call success rate with a preset success rate threshold (e.g., 95%), and simultaneously compares the response time with a preset second response time threshold (e.g., 1500 milliseconds). If the success rate of the call is greater than the success rate threshold and the response time is less than the second response time threshold, then the downstream dependent service is determined to be timely and stable, and the second judgment layer outputs the judgment result, determining the service quality category of the target dependent service as the normal category of dependent services; otherwise, it indicates that even if CPU resources are idle, the downstream service may have performance degradation or abnormality, and its service quality category is determined to be the abnormal category of dependent services.

[0052] In some embodiments, the step of analyzing the call chain data based on the resource occupancy status judgment result through the second judgment layer in the decision tree model to determine the service quality category of the dependent service includes: if the resource occupancy status judgment result is medium occupancy, the second judgment layer in the decision tree model calculates the asynchronous call completion rate based on the call chain data; calculates the difference between the task submission rate and the task completion rate based on the running status data; if the asynchronous call completion rate is between the lower limit and the upper limit of the asynchronous call completion rate, and the difference is continuously positive within multiple consecutive sampling periods, then the service quality category of the target dependent service is determined to be a resource contention category.

[0053] In some embodiments, when the resource occupancy status judgment result is "medium occupancy," the second judgment layer in the decision tree model is activated and performs a specific analysis for potential resource contention. This judgment layer first calculates the asynchronous call completion rate by dividing the number of calls marked as completed in the asynchronous call records of the target dependent service (such as a payment gateway) within a preset analysis window based on the input call chain data. Simultaneously, the second judgment layer calculates the task submission rate of newly added pending tasks per unit time (e.g., per minute) and the task completion rate of completed tasks per unit time based on the input running status data, and calculates the difference between the two (task submission rate - task completion rate). If the calculated asynchronous call completion rate is between a preset lower limit (e.g., 60%) and an upper limit (e.g., 80%), it indicates that external calls are partially blocked but not completely interrupted; furthermore, if the calculated difference between the task submission and completion rates remains positive for multiple consecutive sampling periods, it indicates that tasks are continuously accumulating. When both conditions are met, the second judgment layer determines that there may be intense contention for shared resources (such as database connections and locks) within the system, causing some threads to execute slowly. It then outputs the judgment result, determining that the service quality category of the target dependent service is the category of resource contention.

[0054] Please refer to Figure 3 In some embodiments, the step of analyzing the running status data and the service quality category through the third judgment layer in the decision tree model to obtain the thread pool exception type includes steps S301 to S305: Step S301: Obtain the service quality category and the thread pool full load and task rejection frequency in the running status data through the third judgment layer in the decision tree model, and make judgments in the following order; In some embodiments, the third judgment layer, as the final classification node of the decision tree, receives the service quality category output from the second judgment layer and extracts the thread pool load and task rejection frequency from the runtime status data. Then, the third judgment layer incorporates a preset, prioritized logical judgment sequence, which sequentially compares the current indicator with the judgment conditions for various anomaly types according to the order of steps S302 to S305 described below.

[0055] It should be noted that thread pool fullness is calculated by dividing the current number of active threads by the maximum number of threads configured in the thread pool. Task rejection frequency is obtained by counting the number of times the task rejection policy is triggered within a unit time window (e.g., per minute) or by analyzing the density of rejection event timestamps.

[0056] Step S302: If the thread pool full load is higher than the full load threshold and the task rejection frequency continues to exceed the rejection frequency threshold, then the thread pool abnormality type is determined to be systemic resource exhaustion. In some embodiments, if the thread pool load is higher than the load threshold, such as 85%, the time interval between adjacent rejection events is calculated by analyzing the timestamp sequence of rejection events. If all intervals are less than a preset value (e.g., 10 seconds), it is considered to be a continuous high-frequency occurrence with no mitigation trend. When both conditions are met simultaneously, it indicates that the thread pool resources have been exhausted and requests are continuously being dropped, and the system determines that there is systemic resource exhaustion.

[0057] Step S303: Otherwise, if the service quality category is the dependent service exception category and the thread pool full load exceeds the full load threshold, then the thread pool exception type is determined to be external dependency blocking pseudo saturation. In some embodiments, the determination is made after excluding the aforementioned exhaustion conditions. When the service quality category is a dependent service exception category (i.e., the downstream service responds slowly or fails), and the thread pool full load exceeds a full load threshold indicating resource scarcity (e.g., 85%), it indicates that the high load is not caused by its own computation, but by a large number of threads being blocked waiting for responses from external dependent services. In this case, the system determines it to be an external dependency blocking pseudo-saturation.

[0058] Step S304: Otherwise, if the service quality category is the resource contention category, then the thread pool exception type is determined to be resource contention-type mixed saturation. In some embodiments, when the quality of service category is "resource contention exists," it indicates a complex system state, with both external call latency and internal task backlog. CPU resource usage is at a moderate level, reflecting potential resource contention issues such as database lock contention and slow queries within the system, causing some threads to execute slowly and others to be waiting. This mixed state, involving both external and internal factors, is classified as resource contention-driven mixed saturation.

[0059] Step S305: Otherwise, if the service quality category is the normal category of the dependent service, the thread pool full load exceeds the full load threshold, and the task rejection frequency exceeds the rejection frequency threshold, then the thread pool exception type is determined to be true saturation due to exhaustion of computing resources.

[0060] In some embodiments, when the service quality category is the normal category of dependent services (downstream services respond promptly and stably), but the thread pool full load exceeds the full load threshold indicating resource scarcity, and the task rejection frequency also exceeds the threshold, it indicates that all threads are busy executing real business calculation logic, and the actual processing capacity of the system has reached a bottleneck. At this time, the high load is a true saturation caused by its own computationally intensive tasks (such as order business logic processing), and the system determines it to be a true saturation due to exhaustion of computing resources.

[0061] Step S104: Based on the thread pool exception type, generate a handling strategy that matches the thread pool exception type, and handle the thread pool according to the handling strategy.

[0062] In some embodiments, generating a handling strategy that matches the thread pool exception type based on the thread pool exception type includes: Based on the thread pool exception type, a preset handling strategy rule base is queried to obtain the corresponding target handling rule. This handling strategy rule base stores handling rules corresponding to different thread pool exception types. Based on the target handling rule, a handling strategy containing specific handling actions and parameters is generated. Specifically, upon receiving a thread pool exception type, it is used as a key to query the handling strategy rule base to obtain the corresponding target handling rule. Subsequently, the strategy generator, based on the target handling rule and combined with the current real-time monitoring context (e.g., specific thread pool identifier, current connection pool size, timeout configuration value, etc.), generates a handling strategy containing specific handling actions and parameters. For example, for "external dependency blocking pseudo-saturation," the generated strategy text might be specified as: "Adjust the payment gateway call timeout from the current value to 5 seconds and increase the connection pool size by 50%."

[0063] It should be noted that the aforementioned handling strategy rule base is a data structure (such as a key-value table or rule engine) that stores the mapping relationship between exception types and handling rules. Its content is based on operation and maintenance experience and fault modes and is predefined. For example, the rule base may map "external dependency blocking pseudo saturation" to rules such as "implementing circuit breaking and degradation for downstream payment gateway calls, adjusting the size of the payment gateway connection pool and timeout parameters"; map "computation resource exhaustion true saturation" to rules such as "triggering elastic scaling based on CPU indicators, adjusting the maximum number of threads in the thread pool, and enabling request rate limiting"; and map "systemic resource exhaustion" to rules such as "immediately restarting the faulty instance for isolation".

[0064] In some embodiments, the thread pool is processed according to the processing strategy. Specifically, after receiving the generated processing strategy, it is processed according to the execution mode (automatic or manual confirmation) defined in the strategy. For processing actions that can be automatically executed (such as adjusting thread pool parameters or triggering service scaling up or down), the engine parses the strategy into specific operation and maintenance instructions or calls pre-set automated scripts, and executes them by interacting with the configuration management center, container orchestration platform, or the application's own governance interface. For example, for the scaling strategy of "computing resource exhaustion type true saturation", the engine will call the cloud platform's API to increase the number of order service instances to the specified number and simultaneously adjust the load balancing configuration. For processing that requires manual intervention or review (such as payment link fault investigation), the engine encapsulates the processing strategy containing specific operation steps and parameters into a structured alarm ticket or operation guide, and pushes it to the designated operation and maintenance personnel in real time through pre-configured alarm receiving endpoints (such as HTTP callbacks, message middleware, email, or operation and maintenance ticket system), and tracks the processing status.

[0065] It should be noted that after the strategy is executed, the engine will continuously monitor the changes in relevant metrics to verify the effect of the action, and record the context, execution actions and results of this action in the case library for subsequent strategy optimization and model training.

[0066] like Figure 4 As shown, based on the above method embodiments, corresponding apparatus embodiments are provided; An embodiment of the present invention provides an exception handling system for a thread pool, comprising: The first module 100 is used to collect the running status data of the thread pool of the target service; The second module 200 is used to collect the call chain data corresponding to the target dependent service of the target service and the resource utilization rate of the server where the target service is located if the running status data exceeds a preset abnormal threshold. The third module 300 is used to input the running status data, the call chain data, and the resource utilization rate into a preset decision tree model. The first judgment layer in the decision tree model compares the resource utilization rate with the resource utilization rate baseline interval to determine the resource occupancy status judgment result. The second judgment layer in the decision tree model analyzes the call chain data based on the resource occupancy status judgment result to determine the service quality category of the dependent service. The third judgment layer in the decision tree model analyzes the running status data and the service quality category in combination to obtain the thread pool exception type. The resource utilization rate baseline interval is determined based on historical normal operation data. In some embodiments, the third module 300 includes a first processing unit, which is used to process: The target indicator value of the currently collected resource utilization rate is extracted through the first judgment layer in the decision tree model; The target index value is compared with the low occupancy baseline area, the medium occupancy baseline area, and the high occupancy baseline area; If the target index value falls within the low occupancy baseline area, the resource occupancy status judgment result is determined to be the low occupancy status; If the target index value falls into the high occupancy baseline area, the resource occupancy status judgment result is determined to be the high occupancy status; If the target indicator value falls within the medium occupancy baseline area, the resource occupancy status judgment result is determined to be the medium occupancy status.

[0067] In some embodiments, the resource utilization baseline range is determined based on historical normal operation data, including: Obtain time-series data of resource utilization rate of the target service within a historical preset period, as the historical normal operation data; The historical normal operation data is statistically distributed to obtain the first quantile value and the second quantile value, wherein the first quantile value is lower than the second quantile value. The interval below the first quantile value is defined as the low occupancy baseline region, the interval above the second quantile value is defined as the high occupancy baseline region, and the interval between the first quantile value and the second quantile value is defined as the medium occupancy baseline region.

[0068] In some embodiments, the third module 300 includes a second processing unit, which is used to process: If the resource occupancy status judgment result is a low occupancy status, the second judgment layer in the decision tree model will statistically analyze the call failure rate and average response time of the target dependent service within a preset analysis window from the call link data. If the call failure rate is greater than the first failure rate threshold, or the average response time is greater than the first response time threshold, then the service quality category of the target dependent service is determined to be the dependent service anomaly category. Otherwise, the service quality category of the target dependent service is determined to be the normal category of dependent services.

[0069] In some embodiments, the third module 300 includes a third processing unit, which is used to process: If the resource occupancy status judgment result is a high occupancy status, the second judgment layer in the decision tree model will statistically analyze the call success rate and response time of the target dependent service within a preset analysis window from the call link data. If the success rate of the call is greater than the success rate threshold and the response time is less than the second response time threshold, then the service quality category of the target dependent service is determined to be the normal category of the dependent service. Otherwise, the service quality category of the target dependent service is determined to be the dependent service anomaly category.

[0070] In some embodiments, the third module 300 includes a fourth processing unit, which is used to process: If the resource occupancy status judgment result is medium occupancy status, the second judgment layer in the decision tree model calculates the asynchronous call completion rate based on the call link data; Based on the running status data, calculate the difference between the task submission rate and the task completion rate; If the asynchronous call completion rate is between the lower limit and the upper limit of the asynchronous call completion rate, and the difference is positive for multiple consecutive sampling periods, then the service quality category of the target dependent service is determined to be the resource contention category.

[0071] In some embodiments, the third module 300 includes a fifth processing unit, which is used to process: The service quality category and the thread pool full load and task rejection frequency in the running status data are obtained through the third judgment layer in the decision tree model, and the judgment is made in the following order; If the thread pool load is higher than the load threshold and the task rejection frequency continues to exceed the rejection frequency threshold, then the thread pool exception type is determined to be systemic resource exhaustion. Otherwise, if the service quality category is the dependent service exception category and the thread pool full load exceeds the full load threshold, then the thread pool exception type is determined to be external dependency blocking pseudo saturation. Otherwise, if the service quality category is the resource contention category, then the thread pool exception type is determined to be resource contention-type mixed saturation; Otherwise, if the service quality category is the normal category of the dependent service, the thread pool full load exceeds the full load threshold, and the task rejection frequency exceeds the rejection frequency threshold, then the thread pool exception type is determined to be true saturation due to exhaustion of computing resources.

[0072] The fourth module 400 is used to generate a handling strategy that matches the thread pool exception type based on the thread pool exception type, and to handle the thread pool according to the handling strategy.

[0073] In some embodiments, the fourth module 300 includes a sixth processing unit and a seventh processing unit: The sixth processing unit is used to query a preset handling strategy rule library according to the thread pool exception type and match the corresponding target handling rule, wherein the handling strategy rule library stores handling rules corresponding to different thread pool exception types. The seventh processing unit is used to generate a handling strategy that includes specific handling actions and parameters based on the target handling rules.

[0074] It is understood that the above-described device embodiments correspond to the method embodiments of the present invention, and can implement the thread pool exception handling method provided by any of the above-described method embodiments of the present invention.

[0075] It should be noted that the device embodiments described above are merely illustrative, and some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the device embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can specifically be implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0076] Based on the above embodiments of the thread pool exception handling method, another embodiment of the present invention provides a terminal device, which includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor. When the processor executes the computer program, it implements the thread pool exception handling method of any embodiment of the present invention.

[0077] For example, in this embodiment, the computer program can be divided into one or more modules, which are stored in the memory and executed by the processor to complete the present invention. The one or more modules may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the terminal device.

[0078] The terminal device may be a desktop computer, laptop, handheld computer, or cloud server, etc. The terminal device may include, but is not limited to, a processor and a memory.

[0079] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor. The processor is the control center of the terminal device, connecting all parts of the terminal device via various interfaces and lines.

[0080] In some embodiments, the processor is configured to implement: The target indicator value of the currently collected resource utilization rate is extracted through the first judgment layer in the decision tree model; The target index value is compared with the low occupancy baseline area, the medium occupancy baseline area, and the high occupancy baseline area; If the target index value falls within the low occupancy baseline area, the resource occupancy status judgment result is determined to be the low occupancy status; If the target index value falls into the high occupancy baseline area, the resource occupancy status judgment result is determined to be the high occupancy status; If the target indicator value falls within the medium occupancy baseline area, the resource occupancy status judgment result is determined to be the medium occupancy status.

[0081] In some embodiments, the processor is configured to implement: Obtain time-series data of resource utilization rate of the target service within a historical preset period, as the historical normal operation data; The historical normal operation data is statistically distributed to obtain the first quantile value and the second quantile value, wherein the first quantile value is lower than the second quantile value. The interval below the first quantile value is defined as the low occupancy baseline region, the interval above the second quantile value is defined as the high occupancy baseline region, and the interval between the first quantile value and the second quantile value is defined as the medium occupancy baseline region.

[0082] In some embodiments, the processor is configured to implement: If the resource occupancy status judgment result is a low occupancy status, the second judgment layer in the decision tree model will statistically analyze the call failure rate and average response time of the target dependent service within a preset analysis window from the call link data. If the call failure rate is greater than the first failure rate threshold, or the average response time is greater than the first response time threshold, then the service quality category of the target dependent service is determined to be the dependent service anomaly category. Otherwise, the service quality category of the target dependent service is determined to be the normal category of dependent services.

[0083] In some embodiments, the processor is configured to implement: If the resource occupancy status judgment result is a high occupancy status, the second judgment layer in the decision tree model will statistically analyze the call success rate and response time of the target dependent service within a preset analysis window from the call link data. If the success rate of the call is greater than the success rate threshold and the response time is less than the second response time threshold, then the service quality category of the target dependent service is determined to be the normal category of the dependent service. Otherwise, the service quality category of the target dependent service is determined to be the dependent service anomaly category.

[0084] In some embodiments, the processor is configured to implement: If the resource occupancy status judgment result is medium occupancy status, the second judgment layer in the decision tree model calculates the asynchronous call completion rate based on the call link data; Based on the running status data, calculate the difference between the task submission rate and the task completion rate; If the asynchronous call completion rate is between the lower limit and the upper limit of the asynchronous call completion rate, and the difference is positive for multiple consecutive sampling periods, then the service quality category of the target dependent service is determined to be the resource contention category.

[0085] In some embodiments, the processor is configured to implement: The service quality category and the thread pool full load and task rejection frequency in the running status data are obtained through the third judgment layer in the decision tree model, and the judgment is made in the following order; If the thread pool load is higher than the load threshold and the task rejection frequency continues to exceed the rejection frequency threshold, then the thread pool exception type is determined to be systemic resource exhaustion. Otherwise, if the service quality category is the dependent service exception category and the thread pool full load exceeds the full load threshold, then the thread pool exception type is determined to be external dependency blocking pseudo saturation. Otherwise, if the service quality category is the resource contention category, then the thread pool exception type is determined to be resource contention-type mixed saturation; Otherwise, if the service quality category is the normal category of the dependent service, the thread pool full load exceeds the full load threshold, and the task rejection frequency exceeds the rejection frequency threshold, then the thread pool exception type is determined to be true saturation due to exhaustion of computing resources.

[0086] In some embodiments, the processor is configured to implement: Based on the thread pool exception type, a preset handling strategy rule library is queried to match the corresponding target handling rule. The handling strategy rule library stores handling rules corresponding to different thread pool exception types. Based on the target handling rules, a handling strategy containing specific handling actions and parameters is generated.

[0087] Based on the above-described method embodiments, another embodiment of the present invention provides a computer-readable storage medium including a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to execute the thread pool exception handling method described in any of the above-described method embodiments of the present invention.

[0088] The modules / units integrated in the device / terminal equipment, if implemented as software functional units and sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the above embodiments of the present invention can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0089] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A method for handling exceptions in a thread pool, characterized in that, include: Collect runtime status data of the target service's thread pool; If the running status data exceeds the preset abnormal threshold, the call chain data corresponding to the target dependent service of the target service and the resource utilization rate of the server where the target service is located are collected. The running status data, the call chain data, and the resource utilization rate are input into a preset decision tree model. The first judgment layer in the decision tree model compares the resource utilization rate with the resource utilization rate baseline range to determine the resource occupancy status judgment result. The second judgment layer in the decision tree model analyzes the call chain data based on the resource occupancy status judgment result to determine the service quality category of the dependent service. The third judgment layer in the decision tree model analyzes the running status data and the service quality category in combination to obtain the thread pool exception type. The resource utilization rate baseline range is determined based on historical normal operation data. Based on the thread pool exception type, a handling strategy matching the thread pool exception type is generated, and the thread pool is handled according to the handling strategy.

2. The exception handling method for a thread pool according to claim 1, characterized in that, The resource utilization baseline range includes a low occupancy baseline range, a medium occupancy baseline range, and a high occupancy baseline range. The resource occupancy status judgment result includes a low occupancy status, a medium occupancy status, and a high occupancy status. The step of comparing the resource utilization rate with the resource utilization baseline range through the first judgment layer in the decision tree model to determine the resource occupancy status judgment result includes: The target indicator value of the currently collected resource utilization rate is extracted through the first judgment layer in the decision tree model; The target index value is compared with the low occupancy baseline area, the medium occupancy baseline area, and the high occupancy baseline area; If the target index value falls within the low occupancy baseline area, the resource occupancy status judgment result is determined to be the low occupancy status; If the target index value falls into the high occupancy baseline area, the resource occupancy status judgment result is determined to be the high occupancy status; If the target indicator value falls within the medium occupancy baseline area, the resource occupancy status judgment result is determined to be the medium occupancy status.

3. The exception handling method for thread pools according to claim 2, characterized in that, The baseline range for resource utilization is determined based on historical normal operation data and includes: Obtain time-series data of resource utilization rate of the target service within a historical preset period, as the historical normal operation data; The historical normal operation data is statistically distributed to obtain the first quantile value and the second quantile value, wherein the first quantile value is lower than the second quantile value. The interval below the first quantile value is defined as the low occupancy baseline region, the interval above the second quantile value is defined as the high occupancy baseline region, and the interval between the first quantile value and the second quantile value is defined as the medium occupancy baseline region.

4. The exception handling method for a thread pool according to claim 2, characterized in that, The step of analyzing the call chain data based on the resource occupancy status judgment result through the second judgment layer in the decision tree model to determine the service quality category of dependent services includes: If the resource occupancy status judgment result is a low occupancy status, the second judgment layer in the decision tree model will statistically analyze the call failure rate and average response time of the target dependent service within a preset analysis window from the call link data. If the call failure rate is greater than the first failure rate threshold, or the average response time is greater than the first response time threshold, then the service quality category of the target dependent service is determined to be the dependent service anomaly category. Otherwise, the service quality category of the target dependent service is determined to be the normal category of dependent services.

5. The exception handling method for a thread pool according to claim 2, characterized in that, The step of analyzing the call chain data based on the resource occupancy status judgment result through the second judgment layer in the decision tree model to determine the service quality category of dependent services includes: If the resource occupancy status judgment result is a high occupancy status, the second judgment layer in the decision tree model will statistically analyze the call success rate and response time of the target dependent service within a preset analysis window from the call link data. If the success rate of the call is greater than the success rate threshold and the response time is less than the second response time threshold, then the service quality category of the target dependent service is determined to be the normal category of the dependent service. Otherwise, the service quality category of the target dependent service is determined to be the dependent service anomaly category.

6. The exception handling method for a thread pool according to claim 2, characterized in that, The step of analyzing the call chain data based on the resource occupancy status judgment result through the second judgment layer in the decision tree model to determine the service quality category of dependent services includes: If the resource occupancy status judgment result is medium occupancy status, the second judgment layer in the decision tree model calculates the asynchronous call completion rate based on the call link data; Based on the running status data, calculate the difference between the task submission rate and the task completion rate; If the asynchronous call completion rate is between the lower limit and the upper limit of the asynchronous call completion rate, and the difference is positive for multiple consecutive sampling periods, then the service quality category of the target dependent service is determined to be the resource contention category.

7. The exception handling method for a thread pool according to claim 4, 5, or 6, characterized in that, The process involves analyzing the runtime status data and service quality categories through the third judgment layer of the decision tree model to determine thread pool exception types, including: The service quality category and the thread pool full load and task rejection frequency in the running status data are obtained through the third judgment layer in the decision tree model, and the judgment is made in the following order; If the thread pool load is higher than the load threshold and the task rejection frequency continues to exceed the rejection frequency threshold, then the thread pool exception type is determined to be systemic resource exhaustion. Otherwise, if the service quality category is the dependent service exception category and the thread pool full load exceeds the full load threshold, then the thread pool exception type is determined to be external dependency blocking pseudo saturation. Otherwise, if the service quality category is the resource contention category, then the thread pool exception type is determined to be resource contention-type mixed saturation; Otherwise, if the service quality category is the normal category of the dependent service, the thread pool full load exceeds the full load threshold, and the task rejection frequency exceeds the rejection frequency threshold, then the thread pool exception type is determined to be true saturation due to exhaustion of computing resources.

8. The exception handling method for a thread pool according to claim 1, characterized in that, The step of generating a handling strategy that matches the thread pool exception type based on the thread pool exception type includes: Based on the thread pool exception type, a preset handling strategy rule library is queried to match the corresponding target handling rule. The handling strategy rule library stores handling rules corresponding to different thread pool exception types. Based on the target handling rules, a handling strategy containing specific handling actions and parameters is generated.

9. An exception handling system for a thread pool, characterized in that, include; The first acquisition module is used to collect the running status data of the thread pool of the target service; The second acquisition module is used to acquire, if the running status data exceeds a preset abnormal threshold, the call chain data corresponding to the target dependent service of the target service and the resource utilization rate of the server where the target service is located. The analysis module is used to input the running status data, the call chain data, and the resource utilization rate into a preset decision tree model. The first judgment layer in the decision tree model compares the resource utilization rate with the resource utilization rate baseline range to determine the resource occupancy status judgment result. The second judgment layer in the decision tree model analyzes the call chain data based on the resource occupancy status judgment result to determine the service quality category of the dependent service. The third judgment layer in the decision tree model analyzes the running status data and the service quality category in combination to obtain the thread pool exception type. The resource utilization rate baseline range is determined based on historical normal operation data. The handling module is used to generate a handling strategy that matches the thread pool exception type based on the thread pool exception type, and to handle the thread pool according to the handling strategy.

10. A terminal device, characterized in that, include: One or more processors; A memory, coupled to the processor, 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 steps of the exception handling method for the thread pool as described in any one of claims 1-8.

Images