A method for detecting infinite loops in server application threads

Abstract

The present invention discloses a method for detecting infinite loops in server - side application threads, comprising the following steps: obtaining the CPU occupancy ratio of server - side application threads, and screening out application thread A whose CPU occupancy is not less than a first preset value; obtaining all server - side application thread objects and traversing the server - side application thread list; if the name of the server - side application thread matches application thread A, continue with stack comparison: comparing the stack similarity, and screening out application thread A whose stack similarity is not less than a second preset value, that is, obtaining the application thread suspected of having an infinite loop. The present invention aims to overcome the limitations of the prior art by converting the stack path into a method call graph and using the graph edit distance to accurately calculate the stack similarity. The present invention can not only more accurately locate the infinite - loop thread, but also significantly improve the detection accuracy, reduce the false - alarm rate, and enhance the system performance and stability by retaining the complete stack call context and order information.

Description

Technical Field

[0001] The present invention relates to the field of computers, and particularly to a method for detecting infinite loops in server - side application threads. Background Art

[0002] In modern Internet and enterprise applications, server - side applications developed based on programming languages such as Java usually encounter high - concurrency operating environments, especially when dealing with a large number of user requests, data calculations, or complex system integrations. Reasonable scheduling and management of threads are important technical means to ensure the stable operation of applications, but the problem of infinite loops in threads occurs from time to time, directly leading to excessive consumption of CPU resources, and ultimately causing system performance degradation or crashes.

[0003] Existing methods for detecting infinite loops in threads (such as performance monitoring, static code analysis, stack similarity calculation, etc.) have certain limitations in complex concurrent environments and are difficult to accurately identify infinite - loop threads without affecting performance.

[0004] Among them, performance monitoring tools are widely used in detecting infinite loops in threads. They mainly identify potential infinite - loop threads by monitoring the runtime performance metrics of the system, such as CPU usage and memory consumption. When the CPU usage of a certain thread exceeds a set threshold for a long time, the monitoring tool will issue an alarm. However, this type of method has obvious limitations: high CPU usage does not necessarily mean that the thread has fallen into an infinite loop, and it may also be caused by normal computationally intensive tasks, resulting in a high false - alarm rate.

[0005] Predicting potential thread infinite loops through static code analysis, this method is executed during the code development stage or compilation stage, and attempts to predict possible infinite loops by analyzing the code structure and logic. The advantage of static analysis is that it can identify some problems before the system runs, avoiding performance problems caused by runtime infinite loops. However, the coverage of this method is limited and it is difficult to accurately predict infinite loops that may be triggered in complex runtime environments, especially in scenarios driven by dynamic data.

[0006] Existing stack similarity calculation methods are widely used in the detection of thread deadlocks. The core idea is to analyze the stack information of threads, search for similar or duplicate stack patterns, and identify threads that have fallen into deadlocks. In existing methods, function call information is usually extracted from the stack recorded at the time of the failure, and a simplified stack is generated. Subsequently, the similarity between the simplified stacks or their sub-stacks is compared to determine the relevance between the failures. Although this method based on simplified stacks reduces the noise information in the stack to a certain extent, since it mainly relies on function names for comparison, it fails to fully preserve the call order and context information of the stack, resulting in low accuracy in similarity calculation. In a complex multi-threaded environment, the false alarm rate is high, and it is unable to accurately distinguish between similar but essentially different thread behaviors. In addition, this method processes the stack relatively simply, lacking in-depth analysis of complex stack relationships. Especially when facing applications with large-scale concurrency or cross-module calls, its efficiency is insufficient.

[0007] Generally speaking, existing performance monitoring, static analysis, and stack similarity calculation methods all have certain deficiencies in detecting thread deadlock problems. Performance monitoring methods can quickly detect problems, but with low accuracy and a high false alarm rate; static analysis methods are difficult to cover all running scenarios in a dynamic environment; the similarity calculation method based on simplified stacks fails to preserve the complete stack call order and context information, resulting in insufficient accuracy in complex scenarios. Therefore, existing technologies cannot balance efficiency and accuracy when detecting thread deadlock problems and urgently need improvement and optimization. Summary of the Invention

[0008] The purpose of the present invention is to overcome the deficiencies of the prior art and provide a method for detecting thread deadlocks in server-side applications. This method converts the stack path into a method call graph and uses the graph edit distance to accurately calculate the stack similarity, aiming to overcome the limitations of the prior art. The present invention can not only more accurately locate the deadlock thread, but also significantly improve the detection accuracy, reduce the false alarm rate, and enhance the system performance and stability by preserving the complete stack call context and order information.

[0009] The purpose of the present invention is achieved through the following technical solutions:

[0010] A method for detecting thread deadlocks in server-side applications, comprising the following steps:

[0011] S1. Obtain the CPU occupancy ratio of the server-side application threads, and filter out the application thread A whose CPU occupancy is not less than the first preset value;

[0012] S2. After filtering out the application thread A, obtain all server-side application thread objects and traverse the server-side application thread list;

[0013] If the server application thread name does not match the application thread A, remove it;

[0014] If the server application thread name matches the application thread A, continue with the stack comparison: within the time period T, capture the stack information of the application thread multiple times, compare the stack similarity, and filter out the application thread A with a stack similarity not less than the second preset value, that is, obtain the application thread suspected of having an infinite loop.

[0015] The stack similarity is calculated by the graph-based stack similarity algorithm:

[0016] Extract the method call sequences of the first stack and the second stack of the application thread A, and construct the method call graphs of the first stack and the second stack;

[0017] Calculate the edit distance and node similarity of the method call graphs of the first stack and the second stack;

[0018] Weightedly average the edit distance and node similarity of the method call graphs of the first stack and the second stack to obtain the stack similarity.

[0019] When constructing the method call graphs of the first stack and the second stack, convert the extracted method call sequences of the first stack and the second stack into directed graphs, with each method call as a vertex and the sequential relationship of the method calls as directed edges.

[0020] The edit distance of the method call graphs of the first stack and the second stack is defined as follows:

[0021]

[0022] Among them, G S1 and G S2 are the method call graphs of the first stack and the second stack, e i represents the i-th edit operation, c(e i ) represents the cost of the edit operation e i , and k is the total number of edit operations.

[0023] The node similarity sim(N1,N2) of the method call graphs of the first stack and the second stack is defined as:

[0024]

[0025] Among them, N1 and N2 are the node sets of the method call graph G S1 of the first stack and the method call graph G S2 of the second stack, respectively.

[0026] At the same time, the present invention provides:

[0027] A server, the server includes a processor and a memory, and at least one segment of program is stored in the memory, and the program is loaded and executed by the processor to implement the method for detecting the infinite loop of the server-side application thread as described above.

[0028] A computer-readable storage medium, at least one segment of program is stored in the storage medium, and the program is loaded and executed by a processor to implement the method for detecting the infinite loop of the server-side application thread as described above.

[0029] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0030] 1. The present invention can accurately locate the thread and code position where the infinite loop occurs, reducing the debugging time of developers.

[0031] 2. The present invention uses an efficient data processing algorithm to quickly process and analyze a large amount of thread information, improving the detection efficiency and reducing resource consumption.

[0032] 3. The present invention combines the method of CPU occupancy ratio and stack comparison, reducing false alarms caused by single-index judgment and improving the accuracy of problem diagnosis.

[0033] 4. By timely discovering and solving the thread infinite loop problem, the present invention avoids problems such as application lag and high CPU usage rate, thus significantly improving the computing efficiency or the experience of end users.

[0034] 5. The present invention is not only applicable to the application platform developed in Java language, but can also be extended and applied to other platforms and applications that require thread management and performance optimization. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 It is a flowchart of a method for detecting the infinite loop of the server-side application thread.

[0036] Figure 2 It is a flowchart of calculating the stack similarity based on the graph-based stack similarity algorithm.

[0037] Figure 3 It is a screenshot of the stat information of the process.

[0038] Figure 4 It is a screenshot of the stat information of the main thread.

[0039] Figure 5 It is a screenshot of the stat information of the child thread.

[0040] Figure 6 It is a screenshot of the first thread capture.

[0041] Figure 7 It is a screenshot of the second thread capture.

[0042] Figure 8 It is a screenshot of the third fetching thread. Specific implementation mode

[0043] The present invention will be further described in detail below in conjunction with embodiments and the accompanying drawings, but the implementation modes of the present invention are not limited thereto.

[0044] A method for detecting infinite loops in server - side application threads, and the complete steps are as follows:

[0045] 1. Obtaining the CPU occupancy ratio of threads.

[0046] By reading the stat file in the system proc directory, obtain the CPU time consumption of the process and threads. Calculate the user - mode CPU occupancy ratio of the threads to identify threads that may have performance problems.

[0047] (1) The stat information of the process.

[0048] By reading the stat file in the system proc directory, the CPU time consumption of the process and threads can be obtained, as Figure 3 .

[0049] The process ID is: 15315. The user - mode CPU time consumption of the process is 260958, and the kernel - mode CPU time consumption is 30749. For an infinite loop, the CPU occupancy is mainly reflected in the user - mode, so only focus on the user - mode CPU occupancy ratio.

[0050] (2) The stat information of the main thread.

[0051] Such as Figure 4 , the process ID is: 15315, which is the same as the process ID. The user - mode CPU time consumption of the main thread is 1, and the kernel - mode CPU time consumption is 0. Then the user - mode CPU occupancy ratio of the main thread can be considered to use very little or almost no CPU at the system level.

[0052] (3) The stat information of the child threads.

[0053] Such as Figure 5 , the child - thread ID is: 15625. The user - mode CPU time consumption of the thread is 17, and the kernel - mode CPU time consumption is 1. The user - mode CPU occupancy ratio of the child thread is 17 / 1 = 17%.

[0054] Calculate the CPU occupancy ratio of each thread within a certain time range, which can be obtained only by calculating according to the difference in CPU time consumption of the process and threads. Usually, threads with a CPU occupancy ratio exceeding 10% can be marked as high - time - consumption threads.

[0055] 2. Comparing thread stacks.

[0056] Another characteristic of an infinite loop thread is that when a loop point appears, the bottom of the thread stack is always the same. For example:

[0057] Such as Figure 6 , the first capture.

[0058] Such as Figure 7 , the second capture.

[0059] Such as Figure 8 , the third capture.

[0060] Such as Figures 6 to 8 , for the three stacks captured by this thread within a certain time interval, it can be found that the similarity of the stacks is very high, so it can be regarded as a key suspect for an infinite loop.

[0061] 3. Integration of CPU occupancy and stack comparison

[0062] CPU occupancy solution: Through the stat file, threads with high CPU occupancy can be identified. However, the stat file only provides limited information such as the thread name and is difficult to directly correspond to the specific code, so it is impossible to accurately analyze the root cause of high CPU occupancy.

[0063] Stack comparison solution: Stack information can be obtained, but when the thread is blocked (such as reading IO or cross-process communication), the stack similarity is also very high, so the false alarm rate is relatively high. Therefore, only by combining the two solutions can the stack information of threads with high CPU occupancy be obtained more accurately, thus greatly improving the analyzability of the detection results.

[0064] Integration solution: To improve the accuracy of the detection results, it is crucial to combine CPU occupancy analysis with stack comparison. The core of the combination lies in using the thread name. Since the thread name is included in the outputs of both solutions, they can be associated and matched through the thread name to accurately locate the stack information of threads with high CPU occupancy. This combination method can significantly improve the effectiveness and accuracy of problem analysis.

[0065] Such as Figure 1 , the detailed description of the complete version of the infinite loop thread detection mechanism is as follows:

[0066] (1) Start monitoring: Start monitoring the CPU usage rate.

[0067] (2) Obtain CPU time: Obtain the CPU time of the process and threads from the stat file.

[0068] (3) Wait and obtain CPU time again: After waiting for a period of time, obtain the CPU time of the process and threads again.

[0069] (4) Calculate and judge CPU time: Calculate the CPU time of all threads and judge whether it exceeds the threshold.

[0070] If it exceeds the threshold, mark it as a high CPU thread and save the information.

[0071] (5) Obtain and traverse thread objects: Obtain all application thread objects and traverse the thread list.

[0072] If the thread name matches a high CPU thread, continue with the stack comparison.

[0073] If it does not match, remove the thread from consideration.

[0074] (6) Stack comparison: Continuously obtain the stacks of the remaining threads within a certain time and compare the stack similarity.

[0075] If the similarity is lower than the threshold, remove the thread from consideration.

[0076] (7) Output results: Output the detection results, combine the CPU usage rate and thread stack information, and finally output the threads suspected of having infinite loops.

[0077] 4. Graph-based stack similarity algorithm.

[0078] The present invention provides an innovative algorithm for calculating the similarity of stack connection graphs - a graph-based stack similarity algorithm. By converting the stack into a method call graph based on the graph-based stack similarity algorithm and using the graph edit distance to calculate the similarity of the graphs, the precise comparison of the stack path graphs is realized.

[0079] Figure 2 Describes the process of the graph-based stack similarity algorithm. By extracting the method call sequence, constructing the method call graph, and calculating the graph edit distance, the similarity score of the stack path graph is finally output.

[0080] (1) Extract method call sequence:

[0081] Extract the method call sequences of stack 1 and stack 2.

[0082] (2) Construct method call graph:

[0083] According to the extracted method call sequences, construct the method call graphs of stack 1 and stack 2 respectively.

[0084] (3) Calculate graph edit distance:

[0085] Calculate the edit distance of the method call graphs of stack 1 and stack 2.

[0086] (4) Judge whether there are the same nodes:

[0087] If there are identical nodes, calculate the edit distance, and the result is x.

[0088] If there are no identical nodes, calculate the edit distance, and the result is y.

[0089] (5) Calculate the similarity score:

[0090] Calculate the similarity score based on the edit distance result.

[0091] (6) Output the similarity score:

[0092] Output the final similarity score.

[0093] Calculate the stack similarity based on the graph-based stack similarity algorithm, which specifically includes the following steps:

[0094] Step 1: Extract the method call sequence;

[0095] For each stack path, extract the method call sequence therein. Given the stack path S, the extracted method call sequence is denoted as:

[0096] M S = m1, m2,..., m n ;

[0097] where m i represents the i-th method call.

[0098] Example: Stack path 1:

[0099] com.text.sqlite.SQLiteCursor.fill(SourceFile:77);

[0100] com.text.AbstractCursor.getMoveToPosition(SourceFile:23);

[0101] com.text.AbstractCursor.moveToNext(Unknown source:4);

[0102] data.queryHistory(SourceFile:106);

[0103] kj$3.run(SourceFile:189);

[0104] java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:428);

[0105] java.util.concurrent.FutureTask.runAndReset(FutureTask.java:278);

[0106] java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133);

[0107] java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607);

[0108] java.lang.Thread.run(Thread.java:761).

[0109] Extracted method call sequence:

[0110] M S1 ={com.newtext.sqlite.SQLiteCursor.fill, com.newtext.AbstractCursor.getMoveToPosition, com.newtext.AbstractCursor.moveToNext, data.queryHistory, kj$3.run, java.util.concurrent.Executors$RunnableAdapter.call, java.util.concurrent.FutureTask.runAndReset, java.util.concurrent.ThreadPoolExecutor.runWorker, java.util.concurrent.ThreadPoolExecutor$Worker.run, java.lang.Thread.run};

[0111] Example: Stack trace 2:

[0112] com.text.sqlite.SQLiteCursor.getColumnNames(SourceFile:196);

[0113] com.text.AbstractCursor.getColumnCount(SourceFile:146);

[0114] b3k.fillWithCursor(SourceFile:59);

[0115] data.queryHistory(SourceFile:107);

[0116] kj$3.run(SourceFile:189);

[0117] java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:428);

[0118] java.util.concurrent.FutureTask.runAndReset(FutureTask.java:278);

[0119] java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133);

[0120] java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607);

[0121] java.lang.Thread.run(Thread.java:761).

[0122] Extracted method call sequence:

[0123] M S2={com.text.sqlite.SQLiteCursor.getColumnNames, com.text.AbstractCursor.getColumnCount, b3k.fillWithCursor, data.queryHistory, kj$3.run, java.util.concurrent.Executors$RunnableAdapter.call, java.util.concurrent.FutureTask.runAndReset, java.util.concurrent.ThreadPoolExecutor.runWorker, java.util.concurrent.ThreadPoolExecutor$Worker.run, java.lang.Thread.run}。

[0124] Step 2: Construct a method call graph

[0125] Convert the extracted method call sequence into a directed graph. Each method call is a vertex, and the sequential relationship of method calls is a directed edge.

[0126] Given a method call sequence:

[0127] M S = m1, m2,..., m n ;

[0128] The constructed directed graph is represented as:

[0129] G S = (V, E);

[0130] Where:

[0131] V = υ1, υ2,..., υ n υ i v i represents the method call m i .

[0132] E = (υ i υ i+1 ) | 1 ≤ i < n, representing the sequential relationship of method calls.

[0133] Example:

[0134] Method call sequence:

[0135] M S1 = {com.text.sqlite.SQLiteCursor.fill,...};

[0136] M S2 = {com.text.sqlite.SQLiteCursor.getColumnNames,…};

[0137] Directed graph constructed:

[0138] V S1 = {υ com.text.sqlite.SQLiteCursor.fillWindow，...};

[0139] E S1 = {(υ com.text.sqlite.SQLiteCursor.fillWindow，...};

[0140] V S2 = {υ com.text.sqlite.SQLiteCursor.getColumnNames，...};

[0141] E S2 = {(υ com.text.sqlite.SQLiteCursor.getColumnNames，... )};

[0142] Step 3: Calculate the graph edit distance

[0143] Compare the call graphs of two stack paths and calculate the graph edit distance (GED) to measure the minimum number of edit operations (additions, deletions, replacements of vertices and edges) required to transform one graph into another.

[0144] Given two graphs G S1 = (V S1 , E S1 ) and G S2 = (V S2 , E S2 ), the graph edit distance is defined as:

[0145]

[0146] where e i represents the i-th edit operation, and c(e i ) represents the cost of the edit operation e i , and k is the total number of edit operations.

[0147] Assume that the costs of addition, deletion, and replacement operations are all 1:

[0148] (1) Replace the vertex com.text.sqlite.SQLiteCursor.fill with the vertex com.text.sqlite.SQLiteCursor.getColumnNames.

[0149] (2) Replace the vertex com.text.AbstractCursor.getMoveToPosition with the vertex com.text.AbstractCursor.getColumnCount.

[0150] (3) Replace the vertex com.text.AbstractCursor.moveToNext with the vertex b3k.fillWithCursor.

[0151] There are 3 operations in total, GED = 3. In the example, both the method call graphs of stack 1 and stack 2 contain 10 method calls (vertices), so |V S1 | = 10, |V S2 | = 10, resulting in the normalized edit distance

[0152] Step 4: Calculate node similarity

[0153] Calculate the similarity of nodes in two graphs G S1 and G S2 . Let N1 and N2 be the node sets of graphs G S1 and G S2 respectively. The node similarity sim(N1, N2) can be defined as:

[0154]

[0155] Get the node similarity

[0156] Step 5: Calculate the comprehensive similarity score;

[0157] Taking into account the graph edit distance and node similarity, calculate the final similarity score S. We use the weighted average method to combine these two metrics:

[0158]

[0159] where α and β are weight coefficients, satisfying α + β = 1.

[0160] The normalized value of the graph edit distance is 0.7, and the node similarity is 0.7. According to the rule of thumb, we choose α = 0.5 and β = 0.5:

[0161] S = 0.5(1 - 0.3) + 0.5 * 0.7 = 0.7;

[0162] The comprehensive similarity score is 0.7, indicating that the similarity of the stack trace diagram is 70%. By adjusting the values of α and β, the result of similarity calculation can be optimized according to specific requirements and application scenarios. The higher the comprehensive similarity score, the greater the probability that the thread is in an infinite loop.

[0163] The present invention obtains the CPU consumption time of processes and threads by reading the stat file in the system proc directory, calculates the user-mode CPU occupancy ratio of threads, and identifies threads that may have performance problems.

[0164] The present invention continuously obtains the stack information of threads at regular time intervals, compares the similarity of the stacks, and identifies infinite loop threads.

[0165] The present invention combines CPU occupancy analysis with stack comparison, performs association matching through thread names, and accurately locates the stack information of high CPU occupancy threads.

[0166] The present invention proposes an innovative algorithm for calculating the similarity of stack paths. By converting the stack paths into method call graphs and using graph edit distance to calculate the similarity of the graphs, the accurate comparison of stack paths is realized.

[0167] A server, the server includes a processor and a memory, and at least one segment of program is stored in the memory. The program is loaded and executed by the processor to implement the above method for detecting infinite loops in server application threads.

[0168] A computer-readable storage medium, at least one segment of program is stored in the storage medium. The program is loaded and executed by a processor to implement the above method for detecting infinite loops in server application threads.

[0169] The method and algorithm of the present invention are not limited to a programming language. Whether using programming languages such as Python, Java, C++, Go, Rust, etc., as long as the above methods and algorithms are implemented, they all fall within the protection scope of the present invention.

[0170] The above embodiments are preferred embodiments of the present invention, but the embodiments of the present invention are not limited by the above embodiments. Any other changes, modifications, substitutions, combinations, and simplifications made without departing from the spirit and principle of the present invention shall be equivalent replacement methods and are all included in the protection scope of the present invention.

Claims

1. A method for detecting infinite loops in server application threads, characterized in that, It includes the following steps: S1. Obtain the CPU occupancy ratio of the server - side application threads, and filter out the application thread A whose CPU occupancy is not less than the first preset value; S2. After filtering out the application thread A, obtain all server - side application thread objects and traverse the server - side application thread list; If the server - side application thread name does not match the application thread A, remove it; If the server - side application thread name matches the application thread A, continue with the stack comparison: within the time period T, grab the stack information of the application thread several times, compare the stack similarity, and filter out the application thread A whose stack similarity is not less than the second preset value, that is, obtain the application thread suspected of having an infinite loop; The stack similarity is calculated by the graph - based stack similarity algorithm: Extract the method call sequences of the first stack and the second stack of the application thread A, and construct the method call graphs of the first stack and the second stack; Calculate the edit distance and node similarity of the method call graphs of the first stack and the second stack; Perform weighted averaging on the edit distance and node similarity of the method call graphs of the first stack and the second stack to obtain the stack similarity.

2. The method for detecting the infinite loop of the server application thread according to claim 1, characterized in that, When constructing the method call graphs of the first stack and the second stack, convert the extracted method call sequences of the first stack and the second stack into directed graphs, with each method call as a vertex and the order relationship of the method calls as directed edges.

3. The method for detecting infinite loops in server application threads according to claim 1, wherein The edit distance of the method call graphs of the first stack and the second stack is defined as follows: Among them, G S1 and G S2 are the method call graphs of the first stack and the second stack, e i represents the i-th edit operation, and c(e i ) represents the cost of the edit operation e i . k is the total number of edit operations.

4. The method for detecting the infinite loop of the server application thread according to claim 1, wherein The node similarity sim(N1,N2) of the method call graphs of the first stack and the second stack is defined as: where N1 and N2 are the node sets of the method call graph G of the first stack S1 and the method call graph G S2 of the second stack, respectively.

5. A server, the server comprising a processor and a memory, characterized in that, At least one segment of program is stored in the memory, and the program is loaded and executed by the processor to implement the method for detecting infinite loops of server - side application threads described in any one of claims 1 to 4.

6. A computer-readable storage medium storing at least one program, characterized in that, The program is loaded and executed by the processor to implement the method for detecting infinite loops of server - side application threads described in any one of claims 1 to 4.

Images