An analysis method and device for connection leakage, electronic equipment and storage medium

Abstract

Embodiments of the present application provide a kind of analysis method, device, electronic equipment and storage medium of connection leakage, it is related to computer technical field.Therein, method is: obtaining the connection data of each potential leakage connection respectively;Based on the call stack information of each potential leakage connection, generate the call stack signature of each potential leakage connection, and from the call stack signature obtained, determine out suspicious call stack signature;Extract the multiple classes of the call stack information corresponding to suspicious call stack signature, the byte code corresponding to multiple classes is decompiled, obtains the source code of multiple classes;Based on suspicious call stack signature, the source code of multiple classes and the connection data corresponding to suspicious call stack signature, determine source code analysis result, source code analysis result is used to indicate whether there is the code and the position of code that lead to connection leakage.Such, can accurately locate the root of connection leakage problem, to improve the stability and performance of system.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, electronic device, and storage medium for analyzing connection leaks. Background Technology

[0002] With the advent of the internet and the era of big data, databases have become a core component of many applications. Applications need to frequently interact with databases to store and retrieve data. To improve performance and efficiency, many applications use database connection pools to manage the creation and release of database connections.

[0003] A database connection pool is a technical component used to efficiently manage database connections. By pre-creating and maintaining a certain number of connections for applications to reuse, it reduces the overhead of connection establishment and closure, improves performance, and optimizes resource utilization.

[0004] However, during the use of database connection pools, connection leaks may occur, leading to the exhaustion of connection resources or performance bottlenecks. A connection leak refers to the application's failure to properly release a database connection after use, resulting in the connection resources not being reclaimed and reused.

[0005] Therefore, accurately locating the root cause of connection leakage is an urgent problem that needs to be solved. Summary of the Invention

[0006] This application provides a method, apparatus, electronic device, and storage medium for analyzing connection leaks, which can accurately locate the root cause of connection leak problems, thereby improving the stability and performance of the system.

[0007] In a first aspect, embodiments of this application provide a method for analyzing connection leaks, the method comprising:

[0008] Obtain the connection data for each potential leaked connection. The connection usage duration of each potential leaked connection is greater than the usage duration threshold. The connection data includes: call stack information.

[0009] Based on the call stack information of each potential leaked connection, a call stack signature for each potential leaked connection is generated, and suspicious call stack signatures are identified from the obtained call stack signatures.

[0010] Extract multiple classes corresponding to the call stack information of suspicious call stack signatures, decompile the bytecode of multiple classes to obtain the source code of multiple classes;

[0011] Based on suspicious call stack signatures, the source code of multiple classes, and the connection data corresponding to the suspicious call stack signatures, the source code analysis results are determined. The source code analysis results are used to indicate whether there is code that leads to connection leakage and the location of the code.

[0012] In one optional embodiment, the connection data further includes: a connection identifier, connection acquisition time, connection usage duration, and thread information.

[0013] In one optional embodiment, a call stack signature for each potentially leaking connection is generated based on the call stack information of each potentially leaking connection, including:

[0014] For each potentially leaked connection, perform the following operations:

[0015] Normalize the call stack information of a potentially leaky connection;

[0016] Extract core information from the call stack information of a potentially leaky connection, and generate a call stack signature for the potentially leaky connection based on the core information.

[0017] In one alternative embodiment, the call stack information of a potentially leaky connection is normalized, including:

[0018] Filter irrelevant stack frames from the call stack information of a potentially leaking connection. Irrelevant stack frames are those that are not related to the application code.

[0019] In one alternative embodiment, suspicious call stack signatures are identified from the obtained call stack signatures, including:

[0020] Based on the occurrence frequency of each call stack signature and the uniformity measure of the time distribution of multiple potential leaked connections corresponding to each call stack signature, the suspicious value of each call stack signature is determined.

[0021] Based on the suspicious values ​​of each call stack signature, suspicious call stack signatures that meet the preset suspicious conditions are selected from each call stack signature.

[0022] In one optional embodiment, the suspicious value of each call stack signature is determined based on the occurrence frequency of each call stack signature and a uniformity measure of the time distribution of multiple potentially leaky connections corresponding to each call stack signature, including:

[0023] For each call stack signature, perform the following operations: obtain and analyze the time series of a call stack signature to obtain a uniformity measure of the time distribution corresponding to a call stack signature, wherein the time series includes the time points of multiple potential leaking connections corresponding to a call stack signature;

[0024] The occurrence counts and corresponding time distribution uniformity measures of each call stack signature are normalized and weighted to obtain the suspicious values ​​of each call stack signature.

[0025] In one optional embodiment, the bytecode corresponding to multiple classes is decompiled to obtain the source code of the multiple classes, including:

[0026] Filter irrelevant classes from multiple classes; and / or, select multiple classes belonging to the upper-level stack frame from multiple classes; wherein, irrelevant classes are classes that are not related to the connection leakage event, and the upper-level stack frame is the stack frame whose stack frame depth in the call stack information corresponding to the suspicious call stack signature meets the preset depth condition.

[0027] By using decompilation tools, the bytecode corresponding to multiple classes can be decompiled to obtain the source code of multiple classes.

[0028] In an optional embodiment, before determining the source code analysis result based on the suspicious call stack signature, the source code of multiple classes, and the connection data corresponding to the suspicious call stack signature, the method further includes:

[0029] Irrelevant code is filtered out from the source code of multiple classes. Irrelevant code is code that is not related to the core business logic.

[0030] In one optional embodiment, the source code analysis results are determined based on the suspicious call stack signature, the source code of multiple classes, and the connection data corresponding to the suspicious call stack signature, including:

[0031] The suspicious call stack signature, the source code of multiple classes, and the connection data corresponding to the suspicious call stack signature are input into the code analysis model to obtain the source code analysis results output by the code analysis model. When the source code analysis result indicates the existence of code that causes connection leakage, the source code analysis result includes: an exception report, which includes: the class, method, and line number that caused the connection leakage, as well as the corresponding code snippet.

[0032] In an optional embodiment, the method further includes:

[0033] When the connection pool is in an abnormal running state or the source code analysis results indicate the presence of code that could lead to connection leakage, the running state and source code analysis results are input into the optimization model to obtain configuration optimization suggestions output by the optimization model.

[0034] In an optional embodiment, the method further includes:

[0035] When the usage rate of the connection pool exceeds the usage rate threshold, or when the time required for an application to obtain a connection from the connection pool exceeds the acquisition time threshold, the connection pool is determined to be in an abnormal operating state.

[0036] Secondly, embodiments of this application also provide a connection leakage analysis device, the device comprising:

[0037] The acquisition module is used to acquire the connection data of each potential leaked connection, wherein the connection usage time of each potential leaked connection is greater than the usage time threshold, and the connection data includes: call stack information;

[0038] The first processing module is used to generate call stack signatures for each potential leaked connection based on the call stack information of each potential leaked connection, and to determine suspicious call stack signatures from the obtained call stack signatures.

[0039] The second processing module is used to extract multiple classes of call stack information corresponding to the suspicious call stack signature, decompile the bytecode corresponding to the multiple classes, and obtain the source code of the multiple classes.

[0040] The analysis module is used to determine the source code analysis results based on the suspicious call stack signature, the source code of the multiple classes, and the connection data corresponding to the suspicious call stack signature. The source code analysis results are used to indicate whether there is code that causes connection leakage and the location of the code.

[0041] In one optional embodiment, the connection data further includes: a connection identifier, connection acquisition time, connection usage duration, and thread information.

[0042] In an optional embodiment, when generating the call stack signature of each potential leaked connection based on the call stack information of each potential leaked connection, the first processing module is further configured to:

[0043] For each potentially leaked connection, perform the following operations:

[0044] Normalize the call stack information of a potentially leaky connection;

[0045] Extract core information from the call stack information of a potentially leaky connection, and generate a call stack signature for the potentially leaky connection based on the core information.

[0046] In an optional embodiment, when normalizing the call stack information of a potentially leaky connection, the first processing module is further configured to:

[0047] Filter irrelevant stack frames from the call stack information of a potentially leaking connection. Irrelevant stack frames are those that are not related to the application code.

[0048] In an optional embodiment, when a suspicious call stack signature is identified from the obtained call stack signatures, the first processing module is further configured to:

[0049] Based on the occurrence frequency of each call stack signature and the uniformity measure of the time distribution of multiple potential leaked connections corresponding to each call stack signature, the suspicious value of each call stack signature is determined.

[0050] Based on the suspicious values ​​of each call stack signature, suspicious call stack signatures that meet the preset suspicious conditions are selected from each call stack signature.

[0051] In an optional embodiment, when determining the suspicious value of each call stack signature based on the occurrence frequency of each call stack signature and the uniformity measure of the time distribution of multiple potentially leaking connections corresponding to each call stack signature, the first processing module is further configured to:

[0052] For each call stack signature, perform the following operations: obtain and analyze the time series of a call stack signature to obtain a uniformity measure of the time distribution corresponding to a call stack signature, wherein the time series includes the time points of multiple potential leaking connections corresponding to a call stack signature;

[0053] The occurrence counts and corresponding time distribution uniformity measures of each call stack signature are normalized and weighted to obtain the suspicious values ​​of each call stack signature.

[0054] In one optional embodiment, when decompiling the bytecode corresponding to multiple classes to obtain the source code of multiple classes, the second processing module is further configured to:

[0055] Filter irrelevant classes from multiple classes; and / or, select multiple classes belonging to the upper-level stack frame from multiple classes; wherein, irrelevant classes are classes that are not related to the connection leakage event, and the upper-level stack frame is the stack frame whose stack frame depth in the call stack information corresponding to the suspicious call stack signature meets the preset depth condition.

[0056] By using decompilation tools, the bytecode corresponding to multiple classes can be decompiled to obtain the source code of multiple classes.

[0057] In an optional embodiment, before determining the source code analysis result based on the suspicious call stack signature, the source code of multiple classes, and the connection data corresponding to the suspicious call stack signature, the second processing module is further configured to:

[0058] Irrelevant code is filtered out from the source code of multiple classes. Irrelevant code is code that is not related to the core business logic.

[0059] In an optional embodiment, when determining the source code analysis result based on the suspicious call stack signature, the source code of multiple classes, and the connection data corresponding to the suspicious call stack signature, the analysis module is further used to:

[0060] The suspicious call stack signature, the source code of multiple classes, and the connection data corresponding to the suspicious call stack signature are input into the code analysis model to obtain the source code analysis results output by the code analysis model. When the source code analysis result indicates the existence of code that causes connection leakage, the source code analysis result includes: an exception report, which includes: the class, method, and line number that caused the connection leakage, as well as the corresponding code snippet.

[0061] In an optional embodiment, the apparatus further includes a configuration optimization module, wherein the configuration optimization model is used for:

[0062] When the connection pool is in an abnormal running state or the source code analysis results indicate the presence of code that could lead to connection leakage, the running state and source code analysis results are input into the optimization model to obtain configuration optimization suggestions output by the optimization model.

[0063] In an optional embodiment, the configuration optimization model is further used for:

[0064] When the usage rate of the connection pool exceeds the usage rate threshold, or when the time required for an application to obtain a connection from the connection pool exceeds the acquisition time threshold, the connection pool is determined to be in an abnormal operating state.

[0065] Thirdly, embodiments of this application also provide an electronic device, including:

[0066] Processor; and

[0067] Stored program memory,

[0068] The program includes instructions that, when executed by the processor, cause the processor to perform the connection leakage analysis method as described in the first aspect.

[0069] Fourthly, embodiments of this application also provide a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to execute the connection leakage analysis method as described in the first aspect.

[0070] Fifthly, this application provides a computer program product that, when invoked by a computer, causes the computer to execute the connection leakage analysis method steps as described in the first aspect.

[0071] The beneficial effects of this application are as follows:

[0072] In the connection leakage analysis method provided in this application embodiment, after obtaining the connection data of each potentially leaking connection, a call stack signature for each potentially leaking connection can be generated based on the call stack information of each potential leaking connection. Suspicious call stack signatures are then identified from the obtained call stack signatures. Multiple classes corresponding to the call stack information of the suspicious call stack signatures are extracted, and the bytecode corresponding to these multiple classes is decompiled to obtain the source code of these multiple classes. Based on the suspicious call stack signatures, the source code of the multiple classes, and the connection data corresponding to the suspicious call stack signatures, the source code analysis results are determined. These results indicate whether there is code causing connection leakage and the location of that code. In this way, analyzing the connection data and source code of potentially leaking connections can accurately locate the code location where the connection is not closed, i.e., locate the code causing the connection leakage, thus obtaining the root cause of the connection pool leakage problem. This effectively avoids performance degradation or system failure caused by connection pool resource exhaustion, significantly improving the stability and operating efficiency of the application. Furthermore, it avoids manual investigation and allows for more timely identification of the code causing connection leakage.

[0073] Furthermore, other features and advantages of this application will be set forth in the following description and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0074] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described herein are used to provide a further understanding of this application, constitute a part of this application, and do not constitute an improper limitation of this application. In the accompanying drawings:

[0075] Figure 1 This is a schematic diagram of an optional system architecture applicable to the embodiments of this application;

[0076] Figure 2 A schematic diagram illustrating the implementation process of a connection leakage analysis method provided in this application embodiment;

[0077] Figure 3 A logical diagram illustrating the determination of potential leaky connections provided in this application embodiment;

[0078] Figure 4 A logical diagram illustrating connection leakage analysis provided in an embodiment of this application;

[0079] Figure 5 A schematic diagram of a connection leakage analysis device provided in an embodiment of this application;

[0080] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0081] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While some embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this application. It should be understood that the drawings and embodiments of this application are for illustrative purposes only and are not intended to limit the scope of protection of this application.

[0082] It should be understood that the steps described in the method embodiments of this application may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this application is not limited in this respect.

[0083] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description. It should be noted that the concepts of "first", "second", etc., mentioned in this application are used only to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0084] It should be noted that the terms "a" and "a plurality of" used in this application are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0085] The names of the messages or information exchanged between multiple devices in the embodiments of this application are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0086] The following explanations of some terms used in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

[0087] (1) Java Agent: This is a mechanism provided by the Java Virtual Machine (JVM) that allows the bytecode of an application to be modified or enhanced through an agent when the application starts. This mechanism is often used to implement various types of code injection, performance monitoring, logging, Aspect-Oriented Programming (AOP), and other functions.

[0088] (2) Bytecode manipulation: Java Agents allow developers to intercept and modify the bytecode of classes during the application's class loading process. This requires analyzing, modifying, and regenerating the bytecode. To achieve this, bytecode manipulation libraries such as ASM and ByteBuddy are typically used. These libraries provide high-level Application Programming Interfaces (APIs), making bytecode-level manipulation relatively easy.

[0089] (3) Database connection pool: is a technology for efficient management of database connections. By pre-creating and maintaining a certain number of connections for application reuse, it reduces the overhead of connection establishment and closure, improves performance and optimizes resource utilization.

[0090] (4) Large Language Model (LLM): This represents a significant technological breakthrough in the field of artificial intelligence in recent years. Based on deep learning and neural network architecture, it generates complex language models through training on massive amounts of data. Its core advantage lies in its powerful language understanding and generation capabilities, enabling it to handle various tasks in Natural Language Processing (NLP), such as text generation, translation, and question answering. By learning patterns and relationships in large amounts of text, large models can generate coherent and accurate text content, demonstrating broad application potential in multiple fields.

[0091] With the advent of the internet and the era of big data, databases have become a core component of many applications. Applications need to frequently interact with databases to store and retrieve data. To improve performance and efficiency, many applications use database connection pools to manage the creation and release of database connections.

[0092] A database connection pool is a technical component used to efficiently manage database connections. By pre-creating and maintaining a certain number of connections for applications to reuse, it reduces the overhead of connection establishment and closure, improves performance, and optimizes resource utilization.

[0093] However, database connection pools may experience connection leaks during use, leading to connection resource exhaustion or performance bottlenecks, especially in high-concurrency scenarios. A connection leak refers to an application failing to properly release a database connection after use, resulting in the connection resource not being reclaimed and reused.

[0094] Existing monitoring tools often struggle to effectively detect and locate the root causes of connection leaks, resulting in poor system stability and performance.

[0095] In view of this, this application provides a method, apparatus, electronic device, and storage medium for analyzing connection leaks. The method involves acquiring connection data for each potentially leaking connection, where the connection usage duration of each potentially leaking connection exceeds a usage duration threshold. The connection data includes call stack information. Then, based on the call stack information of each potentially leaking connection, a call stack signature is generated for each connection. Suspicious call stack signatures are identified from the obtained call stack signatures. Multiple classes corresponding to the suspicious call stack signatures are extracted, and the bytecode corresponding to these classes is decompiled to obtain their source code. Finally, based on the suspicious call stack signatures, the source code of the multiple classes, and the connection data corresponding to the suspicious call stack signatures, a source code analysis result is determined. This source code analysis result indicates whether there is code causing connection leaks and its location. By analyzing the connection data and source code of potentially leaking connections, the location of code that has not closed the connection can be accurately pinpointed, i.e., the location of code causing connection leaks. This reveals the root cause of connection pool leaks, effectively preventing performance degradation or system failures due to connection pool resource exhaustion, significantly improving application stability and operating efficiency. Furthermore, it avoids manual investigation and allows for more timely identification of the code causing connection leaks.

[0096] In particular, the preferred embodiments of this application will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit this application. Furthermore, the embodiments of this application and the features in the embodiments can be combined with each other without conflict.

[0097] See Figure 1The diagram illustrates an optional system architecture applicable to an embodiment of this application. This system architecture may include: terminal devices (101a, 101b) and server 102. The terminal devices (101a, 101b) and server 102 can interact via a communication network. The communication network can employ wireless communication and wired communication methods. For example, the terminal devices (101a, 101b) can access the network and communicate with server 102 via cellular mobile communication technology. This cellular mobile communication technology may include, for example, 5G (5th generation mobile networks) or next-generation mobile communication technology. Optionally, the terminal devices (101a, 101b) can access the network and communicate with server 102 via short-range wireless communication. This short-range wireless communication method may include, for example, Wi-Fi (wireless fidelity) technology.

[0098] This application embodiment does not impose any limitation on the number of communication devices involved in the above system architecture. For example, the above system architecture may include more terminal devices, or it may include fewer terminal devices, or it may also include other network devices. Figure 1 As shown, only terminal devices (101a, 101b) and server 102 are described as examples. The following is a brief introduction to the above communication devices and their respective functions.

[0099] The terminal devices (101a, 101b) and the server 102 can communicate through a communication network.

[0100] In one alternative implementation, the communication network can be a wired network or a wireless network. Therefore, the terminal devices (101a, 101b) and the server 102 can be connected directly or indirectly via wired or wireless communication. For example, the terminal devices (101a, 101b) can be indirectly connected to the server 102 via a wireless access point, or the terminal devices (101a, 101b) can be directly connected to the server 102 via the Internet; this application does not impose any limitations on this.

[0101] For example, the terminal device (101a, 101b) may include, but is not limited to: mobile phone, tablet computer, laptop computer, desktop computer, e-book reader, smart voice interaction device, smart home appliance, vehicle terminal and other devices; various clients may be installed on the terminal device, which may be an application (such as a browser, game software, etc.) or a webpage, mini program, etc.

[0102] Server 102 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0103] It is worth mentioning that the server 102 in this embodiment can obtain the connection data of each potentially leaking connection; then, based on the call stack information of each potentially leaking connection, it generates a call stack signature for each potentially leaking connection, and determines a suspicious call stack signature from the obtained call stack signatures; it extracts multiple classes from the call stack information corresponding to the suspicious call stack signatures, decompiles the bytecode corresponding to the multiple classes, and obtains the source code of the multiple classes; finally, based on the suspicious call stack signatures, the source code of the multiple classes, and the connection data corresponding to the suspicious call stack signatures, it determines the source code analysis results, which are used to indicate whether there is code that causes connection leakage and the location of the code.

[0104] Optionally, a pre-trained large language model can be deployed on server 102. After obtaining the suspicious call stack signature, the source code of multiple classes, and the connection data corresponding to the suspicious call stack signature, server 102 can input the suspicious call stack signature, the source code of multiple classes, and the connection data corresponding to the suspicious call stack signature into the large language model to analyze the source code and thus determine the source code analysis results.

[0105] The connection leakage analysis method provided by the exemplary embodiments of this application is described below in conjunction with the above system architecture and with reference to the accompanying drawings. It should be noted that the above system architecture is only shown for the purpose of understanding the spirit and principles of this application, and the embodiments of this application are not limited in any way.

[0106] See Figure 2 The diagram shown illustrates the implementation flow of a connection leakage analysis method provided in this application embodiment. Taking a server as an example, the specific implementation flow of this method is as follows:

[0107] S20: Obtain the connection data for each potentially leaked connection.

[0108] In this embodiment, the connection usage time of each potentially leaked connection is greater than the usage time threshold. The connection data includes: call stack information, connection identifier, connection acquisition time, connection usage time, and thread information, etc. This application does not impose any restrictions on this.

[0109] In this embodiment, the connection usage duration of each connection is obtained, and the following operations are performed for each connection: if the connection usage duration of a connection exceeds a usage duration threshold, the connection is determined to be a potentially leaky connection, meaning that the connection may be at risk of leakage. In this case, the connection data of that connection is also reported to the monitoring system and stored in a log file or a distributed storage system.

[0110] For example, the connection usage time is determined based on the connection acquisition time and the connection return time, and the usage time threshold is 10 seconds. This application embodiment does not impose any limitation on this.

[0111] Optionally, in this embodiment, each connection can also be monitored in real time. If a connection is not returned within a usage time threshold, then the connection is determined to be a potentially leaked connection.

[0112] For example, if a connection is not returned within 10 seconds of being acquired, it is identified as a potentially leaked connection.

[0113] Optionally, in this embodiment of the application, the connection usage time of each connection is determined by monitoring the acquisition and return of connections, and the following operations are performed:

[0114] S200: When acquiring a connection, a unique connection identifier is generated and bound to the current thread information, call stack information and acquisition time, and stored in the corresponding connection pool open record storage.

[0115] In this embodiment, during the application deployment phase, an integrated bytecode embedding tool (such as ASM and ByteBuddy) dynamically modifies the application's bytecode and installs a Java Agent, thereby inserting monitoring code at key locations for database connection acquisition and return.

[0116] For example, monitoring code can be embedded in the database connection acquisition method (e.g., getConnection()) to record the time the connection is acquired, call stack information, the unique identifier of the connection, and the current thread information.

[0117] S201: When returning the connection, record the time of the connection's return and look up the corresponding acquisition record using the connection identifier. Calculate the connection usage duration based on the connection's return and acquisition times.

[0118] For example, monitoring code can be embedded in the connection return method (e.g., close() or returnConnection()) to record the moment the connection is returned.

[0119] Furthermore, in this embodiment of the application, when returning a connection, after calculating the connection usage duration, the corresponding data in the connection pool open record storage is cleaned up.

[0120] In this way, through dynamic bytecode embedding and real-time monitoring, database connection leaks can be automatically detected, connection pool exhaustion can be prevented, and the risk of system failure can be reduced.

[0121] See Figure 3 The diagram shown is a logical schematic diagram of determining a potential leaky connection provided in an embodiment of this application.

[0122] S21: Generate call stack signatures for each potential leaked connection based on the call stack information of each potential leaked connection, and identify suspicious call stack signatures from the obtained call stack signatures.

[0123] Optionally, in this embodiment of the application, a possible implementation is provided for generating call stack signatures for each potentially leaked connection based on the call stack information of each potentially leaked connection, specifically by performing the following operations:

[0124] For each potentially leaked connection, perform the following operations:

[0125] S210: Normalize the call stack information of a potentially leaky connection.

[0126] In this application embodiment, the normalization process includes, but is not limited to, the following: filtering irrelevant stack frames in the call stack information of a potentially leaking connection.

[0127] Among them, unrelated stack frames are stack frames that are not related to application code.

[0128] For example, remove stack frames related to connection pool frameworks or bytecode embedding tools (such as proxy classes of java.sql.DriverManager or ByteBuddy) from the call stack information of a potentially leaking connection, and retain only stack frames related to application code.

[0129] This standardization process ensures that the call stack signature is generated accurately and definitively, thereby identifying the call stack signature that can be generated.

[0130] S211: Extract core information from the call stack information of a potentially leaky connection, and generate a call stack signature of a potentially leaky connection based on the core information.

[0131] The core information includes, but is not limited to: class name, method name, and line number.

[0132] For example, extract the class name, method name, and line number from the call stack to generate a unique call stack signature: com.example.MyService.getData:42.

[0133] Optionally, in this embodiment of the application, a possible implementation is provided for determining suspicious call stack signatures from the obtained call stack signatures, specifically by performing the following operations:

[0134] S212: Determine the suspicious value of each call stack signature based on the occurrence frequency of each call stack signature and the uniformity measure of the time distribution of multiple potential leaked connections corresponding to each call stack signature.

[0135] In this embodiment of the application, suspicious values ​​in each call stack signature are determined by performing the following operations:

[0136] S2120: For each call stack signature, perform the following operations: obtain and analyze the time series of a call stack signature to obtain a uniformity measure of the time distribution corresponding to a call stack signature.

[0137] The time series includes the time points of multiple potentially leaky connections corresponding to a call stack signature, with the time points determined by the connection acquisition time.

[0138] In this embodiment of the application, the standard deviation of the time interval and the time span in a time series are calculated, and based on the standard deviation of the time interval and the time span, a uniformity measure of the time distribution corresponding to a call stack signature is determined.

[0139] The formula for calculating the uniformity metric of the time distribution corresponding to the aforementioned call stack signature can be specifically expressed as follows:

[0140]

[0141] Where, σ i The standard deviation of the time interval is represented by ∈, where ∈ represents a small constant to prevent division by zero, and ∈ = 10. -6 , span i The span represents the time span of the time series corresponding to the i-th call stack signature. max The span represents the maximum time span among the time series corresponding to each call stack signature. i =t ni -t1,t ni t1 is the last time point in the time sequence corresponding to the i-th call stack signature, and t1 is the first time point in the time sequence corresponding to the i-th call stack signature.

[0142] Where, σ i The calculation formula can be expressed as follows:

[0143]

[0144] Where, Δt j =t j+1 -t j ,

[0145] S2121: Normalize and weight the occurrence counts and corresponding time distribution uniformity measures of the obtained call stack signatures to obtain the suspicious values ​​of each call stack signature.

[0146] In this embodiment of the application, the formula for calculating the suspicious value of the i-th call stack signature can be specifically expressed as follows:

[0147]

[0148] Where, n i Let n be the number of times the i-th call stack signature appears. max D is the maximum number of occurrences among the signatures of each call stack. max The maximum value among the uniformity measures of the time distribution corresponding to each call stack signature is w1, which is the weight of the occurrence frequency, and w2 is the weight of the uniformity of the time distribution. w1 can be 0.7 and w2 can be 0.3. This application embodiment does not impose any restrictions on this.

[0149] S213: Based on the suspicious values ​​of each call stack signature, filter out suspicious call stack signatures whose suspicious values ​​meet the preset suspicious conditions.

[0150] In this embodiment of the application, the suspicious values ​​of each call stack signature are sorted from largest to smallest to obtain a sorted list of call stack signatures, and the call stack signature with the largest suspicious value is selected as the suspicious call stack signature.

[0151] In addition, it is worth noting that in this embodiment of the application, after analyzing the first call stack signature in the call stack signature list as a suspicious call stack signature, other call stack signatures in the call stack signature list can also be analyzed as suspicious call stack signatures in sequence.

[0152] By taking into account both the uniformity of time distribution and the frequency of occurrence, we can accurately identify suspicious call stack signatures.

[0153] For example, suppose there are 3 call stack signatures: call stack signature 1: n1 = 10, time series T1 = {1, 1.2, 1.4, 1.6, 1.8, 2.0, 2.2, 2.4, 2.6, 2.8}; call stack signature 2: n2 = 9, time series T2 = {1, 11, 21, 31, 41, 51, 61, 71, 81}; call stack signature 3: n3 = 8, time series T3 = {1, 3, 6, 10, 15, 22, 30, 40}.

[0154] The time series T1 has intervals of {0.2, 0.2, ..., 0.2}, σ 1＝ 0, span1=2.8-1=1.8, D1=(1 / (0+10 -6 ))*(1.8 / 80)≈10 6 *0.0225=22500.

[0155] The time series T2 has intervals of {10, 10, ..., 10}, σ² = 0, span² = 81 - 1 = 80, and D² = (1 / (0 + 10)). -6 ))*(80 / 80)=10 6 .

[0156] The time series T3 has intervals of {2, 3, 4, 5, 7, 8, 10}, σ3≈2.927, span3=40-1=39, D3≈(1 / 2.927)*(39 / 80)≈0.166.

[0157] Where, n max =10, D max =10 6 Then the suspicious value S1 of call stack signature 1 is 0.7*(10 / 10) + 0.3*(22500 / 10). 6 =0.70675, the suspicious value S2 of call stack signature 2 is 0.7*(9 / 10)+0.3*(10) 6 / 10 6 =0.93, the suspicious value S3 of call stack signature 3 = 0.7*(8 / 10)+0.3*(0.166 / 10) 6 )≈0.56. The final sorted list of call stack signatures is: [Call stack signature 2, call stack signature 1, call stack signature 3].

[0158] Furthermore, in this embodiment of the application, after obtaining the suspicious call stack signature, an alarm is sent through the monitoring system (alarm form, such as email, Slack, and WeChat Work, etc.), and / or the information associated with the suspicious call stack signature is stored in the distributed storage system for subsequent querying.

[0159] Furthermore, in this embodiment of the application, a flame graph or call chain graph corresponding to the suspicious call stack signature is generated to visually display the leaked code path.

[0160] S22: Extract multiple classes corresponding to the call stack information of the suspicious call stack signature, decompile the bytecode of the multiple classes, and obtain the source code of the multiple classes.

[0161] For example, extract call stack information corresponding to suspicious call stack signatures from multiple classes, such as com.example.MyService.

[0162] In this embodiment of the application, a Java Agent is loaded when the application starts, and the bytecode (.class files) of multiple classes is obtained through the Instrumentation API.

[0163] Optionally, in this embodiment of the application, a possible implementation is provided for decompiling the bytecode corresponding to multiple classes to obtain the source code of multiple classes, specifically by performing the following operations:

[0164] S220: Filter multiple classes to obtain the filtered classes.

[0165] This reduces the amount of bytecode data and improves efficiency.

[0166] Optionally, in this embodiment of the application, the screening process includes the following two processes:

[0167] Process 1: Filter out irrelevant classes from multiple classes to obtain the filtered classes.

[0168] Among them, irrelevant classes are those that are unrelated to the connection leakage event.

[0169] In this embodiment of the application, classes that are not related to the connection leakage event are filtered out from multiple classes to obtain multiple filtered classes.

[0170] For example, filtering authoritative Java classes from multiple classes.

[0171] Process 2: Select multiple classes that belong to the upper stack frame from multiple classes.

[0172] Among them, the upper-level stack frame is the stack frame whose depth in the call stack information corresponding to the suspicious call stack signature meets the preset depth condition.

[0173] For example, if the depth condition is 10, then the upper stack frames are the top 10 stack frames from top to bottom in the call stack information corresponding to the suspicious call stack signature.

[0174] In addition, it is worth noting that in the embodiments of this application, one of the two processes can be selected, or the two processes can be combined. This embodiment of the application does not impose any restrictions on this.

[0175] Optionally, in this embodiment, a possible implementation is provided to combine two processes to filter multiple classes and obtain filtered classes. Specifically, the following operations are performed: irrelevant classes are filtered from the multiple classes to obtain filtered classes; stack frames containing irrelevant classes in the call stack information corresponding to suspicious call stack signatures are filtered; and then, multiple classes belonging to the upper-level stack frames are selected from the filtered classes. Since stack frames containing irrelevant classes in the call stack information corresponding to suspicious call stack signatures have been filtered, the upper-level stack frames are those whose depth meets the preset depth condition among the stack frames that do not contain irrelevant classes.

[0176] For example, suppose the top-down stack frame order in the call stack information corresponding to the suspicious call stack signature is: stack frame 1, stack frame 2, stack frame 3, stack frame 4, stack frame 5, stack frame 6, stack frame 7, stack frame 8, stack frame 9, stack frame 10, stack frame 11, stack frame 12, stack frame 13, stack frame 14, stack frame 15. Assuming the depth condition is 10, and stack frames 2, 7, and 9 contain irrelevant classes, then the upper-level stack frames are: stack frame 1, stack frame 3, stack frame 4, stack frame 5, stack frame 6, stack frame 8, stack frame 10, stack frame 11, stack frame 12, stack frame 13. From the filtered classes, select the classes belonging to the upper-level stack frames.

[0177] This approach ensures the accuracy of the multiple classes used for decompilation while reducing the amount of bytecode data and improving efficiency.

[0178] S221: By using a decompilation tool, the bytecode corresponding to multiple classes is decompiled to obtain the source code of multiple classes.

[0179] The decompilation tools include CFR, JD-Core, or FernFlower.

[0180] In this embodiment, a decompilation tool that supports modern Java features (such as Lambda and Stream) is selected to ensure source code readability.

[0181] Furthermore, in this embodiment of the application, after obtaining the source code of multiple classes, irrelevant code in the source code of multiple classes can be filtered out in order to improve the conciseness of the source code.

[0182] Among them, irrelevant code refers to code that is not related to the core business logic.

[0183] For example, remove irrelevant code (such as bridging methods) from the source code of multiple classes, and retain the code related to the core business logic.

[0184] Furthermore, in this embodiment of the application, the decompiled source code can also be associated with the class name and call stack signature and stored in a temporary database or file system.

[0185] S23: Based on the suspicious call stack signature, the source code of multiple classes, and the connection data corresponding to the suspicious call stack signature, determine the source code analysis results.

[0186] The source code analysis results are used to indicate whether there is code that leads to connection leakage and the location of the code. Since there may be multiple potential leaked connections with the same call stack signature, the connection data corresponding to the suspicious call stack signature may be the connection data of multiple potential leaked connections.

[0187] In this embodiment of the application, the suspicious call stack signature, the source code of multiple classes, and the connection data corresponding to the suspicious call stack signature are input into the code analysis model to obtain the source code analysis results output by the code analysis model.

[0188] When the source code analysis results indicate the presence of code that leads to connection leakage, the source code analysis results include: an exception report, which includes: the class, method, and line number that caused the connection leakage, as well as the corresponding code snippet.

[0189] Additionally, it is worth noting that the code analysis model in this application embodiment is a large language model, such as Grok3 or other large language models that can be used for code analysis.

[0190] For example, in this embodiment of the application, a code analysis model is invoked to perform contextual analysis on the source code of multiple classes to obtain source code analysis results. The input to the code analysis model is: suspicious call stack signatures (e.g., method name and line number), the source code of multiple classes, and connection data (connection identifier and connection acquisition time, etc.) corresponding to the suspicious call stack signatures. The analysis logic of the code analysis model is as follows: 1. Search for operations related to database connection (e.g., getConnection(), close()); 2. Check the resource management mode to identify missing close() calls or improper exception handling (e.g., try-catch swallowing exceptions); 3. Analyze the call chain to confirm whether the connection is not released due to asynchronous tasks, thread pools, or loop logic. The code analysis model outputs code that causes connection leakage and outputs an exception report. The exception report includes: the class, method, and line number that caused the connection leakage (e.g., MyService.getData:42), and the corresponding code snippet.

[0191] In this way, automated analysis of call stack information and decompiled source code can accurately locate the code where the connection is not closed, reducing the time spent on manual investigation.

[0192] Furthermore, in this embodiment of the application, after obtaining the source code analysis results, an alarm is sent through the monitoring system (alarm form, such as email, Slack, and WeChat Work, etc.), and / or the source code analysis results are stored in a distributed storage system for subsequent querying.

[0193] Furthermore, in this embodiment of the application, the operating status of the connection pool can also be monitored to detect whether there may be connection pool performance problems or connection leakage risks. When the operating status of the connection pool is abnormal, the connection pool may have connection pool performance problems or connection leakage risks.

[0194] In this way, the analysis of connection leaks not only considers the abnormal code in the source code, but also the operating state of the connection pool itself, and conducts a comprehensive analysis of connection leaks, preventing connection pool exhaustion and reducing the risk of system failure.

[0195] Specifically, in this embodiment of the application, when the utilization rate of the connection pool is greater than the utilization rate threshold, or when the time required for the application to obtain a connection from the connection pool is greater than the acquisition time threshold, the connection pool is determined to be in an abnormal operating state.

[0196] The utilization rate of the connection pool is calculated as the number of currently used connections / the maximum number of connections. The utilization rate threshold can be 90%, and the acquisition time threshold can be 5 seconds. However, this embodiment does not impose any restrictions on these parameters.

[0197] Additionally, it is worth noting that when the connection pool's running state is determined to be abnormal, an alarm will be triggered and the current connection pool's state information will be recorded. For example, when the time required for an application to obtain a connection from the connection pool exceeds the acquisition time threshold, the thread information, call stack information, and current connection pool state information of that connection will be recorded.

[0198] The status information includes: the number of connections currently in use, the number of idle connections, the maximum number of connections in the connection pool, and the connection acquisition time. The number of connections currently in use is the number of connections currently being used by the application. The number of idle connections is the number of connections currently in an idle state. The maximum number of connections in the connection pool is the maximum number of connections allowed in the connection pool. The connection acquisition time is the average time and the longest waiting time required for the application to acquire a connection from the connection pool.

[0199] In this embodiment of the application, a monitoring function is integrated into the connection pool management module to collect the status information of the connection pool in real time.

[0200] Furthermore, in this embodiment of the application, when the connection pool is in an abnormal operating state or the source code analysis result indicates the presence of code that leads to connection leakage, the operating state and the source code analysis result are input into the optimization model to obtain the configuration optimization suggestions output by the optimization model.

[0201] The optimization model is a large language model.

[0202] For example, in this embodiment of the application, an optimization model is invoked to analyze and generate connection pool configuration optimization suggestions. The input to the optimization model is: source code analysis results or the running status of the connection pool (e.g., connection pool utilization rate is greater than 90% or connection acquisition time is greater than 5 seconds). The analysis logic of the optimization model is as follows: 1. If the utilization rate is greater than the utilization threshold, it is recommended to reduce the maximum number of connections or increase the frequency of idle connection recycling; 2. If the connection acquisition time is greater than the duration threshold, it is recommended to shorten the connection timeout or optimize the connection pool allocation strategy (e.g., prioritize the allocation of idle connections); 3. If the leakage is concentrated in specific business logic, it is recommended to add automatic closing logic (e.g., try-with-resources) in the source code. The output of the optimization model is as follows: 1. Specific configuration parameters (e.g., maxPoolSize = 50, connectionTimeout = 3000ms); 2. Optimization strategy (e.g., enabling the automatic leakage detection mechanism of the connection pool); 3. Code repair suggestions (e.g., adding close() in specific methods or using try-with-resources).

[0203] In this way, based on the running status and source code analysis results, configuration optimization and repair suggestions are generated, realizing automatic feedback, intelligent generation of connection pool configuration optimization suggestions, dynamic adjustment of parameters, reducing resource waste, and improving database performance.

[0204] Furthermore, in this embodiment of the application, after obtaining configuration optimization suggestions, the source code analysis results and configuration optimization suggestions are integrated into a comprehensive report for reference by the development and operation and maintenance teams.

[0205] The report includes: 1. The location of the code causing the connection leak (class, method, line number, code snippet); 2. Connection pool configuration optimization suggestions (parameter adjustments and strategy improvements, etc.); and visualizations (e.g., call chain diagrams of the leaked code and trend charts of the connection pool status). The comprehensive report will be sent to the development and operations teams via the monitoring system (in the form of notifications such as email and Slack) and stored in a distributed storage system for subsequent querying and auditing.

[0206] In this way, by integrating source code analysis results and configuration optimization suggestions, a comprehensive report is generated, which supports visualization and report notifications, automatic configuration push and code repair, and shortens the problem response cycle.

[0207] See Figure 4 The diagram shown is a logical schematic of a connection leakage analysis provided in an embodiment of this application.

[0208] Furthermore, based on the same technical concept, embodiments of this application provide a connection leakage analysis apparatus, which is used to implement the above-described method flow of embodiments of this application. For example, see [link to relevant documentation]. Figure 5 As shown, the connection leakage analysis device 500 may include: an acquisition module 501, a first processing module 502, a second processing module 503, an analysis module 504, and a configuration optimization module 505, wherein:

[0209] The acquisition module 501 is used to acquire the connection data of each potential leaked connection, wherein the connection usage time of each potential leaked connection is greater than the usage time threshold, and the connection data includes: call stack information;

[0210] The first processing module 502 is used to generate a call stack signature for each potential leaked connection based on the call stack information of each potential leaked connection, and to determine a suspicious call stack signature from the obtained call stack signatures.

[0211] The second processing module 503 is used to extract multiple classes of call stack information corresponding to the suspicious call stack signature, decompile the bytecode corresponding to the multiple classes, and obtain the source code of the multiple classes.

[0212] Analysis module 504 is used to determine source code analysis results based on the suspicious call stack signature, the source code of the multiple classes, and the connection data corresponding to the suspicious call stack signature. The source code analysis results are used to indicate whether there is code that causes connection leakage and the location of the code.

[0213] In one optional embodiment, the connection data further includes: a connection identifier, connection acquisition time, connection usage duration, and thread information.

[0214] In an optional embodiment, when generating the call stack signature of each potential leaked connection based on the call stack information of each potential leaked connection, the first processing module 502 is further configured to:

[0215] For each potentially leaked connection, perform the following operations:

[0216] Normalize the call stack information of a potentially leaky connection;

[0217] Extract core information from the call stack information of a potentially leaky connection, and generate a call stack signature for the potentially leaky connection based on the core information.

[0218] In an optional embodiment, when normalizing the call stack information of a potentially leaky connection, the first processing module 502 is further configured to:

[0219] Filter irrelevant stack frames from the call stack information of a potentially leaking connection. Irrelevant stack frames are those that are not related to the application code.

[0220] In an optional embodiment, when a suspicious call stack signature is determined from the obtained call stack signatures, the first processing module 502 is further configured to:

[0221] Based on the occurrence frequency of each call stack signature and the uniformity measure of the time distribution of multiple potential leaked connections corresponding to each call stack signature, the suspicious value of each call stack signature is determined.

[0222] Based on the suspicious values ​​of each call stack signature, suspicious call stack signatures that meet the preset suspicious conditions are selected from each call stack signature.

[0223] In an optional embodiment, when determining the suspicious value of each call stack signature based on the occurrence count of each call stack signature and the uniformity measure of the time distribution of multiple potentially leaking connections corresponding to each call stack signature, the first processing module 502 is further configured to:

[0224] For each call stack signature, perform the following operations: obtain and analyze the time series of a call stack signature to obtain a uniformity measure of the time distribution corresponding to a call stack signature, wherein the time series includes the time points of multiple potential leaking connections corresponding to a call stack signature;

[0225] The occurrence counts and corresponding time distribution uniformity measures of each call stack signature are normalized and weighted to obtain the suspicious values ​​of each call stack signature.

[0226] In an optional embodiment, when decompiling the bytecode corresponding to multiple classes to obtain the source code of multiple classes, the second processing module 503 is further configured to:

[0227] Filter irrelevant classes from multiple classes; and / or, select multiple classes belonging to the upper-level stack frame from multiple classes; wherein, irrelevant classes are classes that are not related to the connection leakage event, and the upper-level stack frame is the stack frame whose stack frame depth in the call stack information corresponding to the suspicious call stack signature meets the preset depth condition.

[0228] By using decompilation tools, the bytecode corresponding to multiple classes can be decompiled to obtain the source code of multiple classes.

[0229] In an optional embodiment, before determining the source code analysis result based on the suspicious call stack signature, the source code of multiple classes, and the connection data corresponding to the suspicious call stack signature, the second processing module 503 is further configured to:

[0230] Irrelevant code is filtered out from the source code of multiple classes. Irrelevant code is code that is not related to the core business logic.

[0231] In an optional embodiment, when determining the source code analysis result based on the suspicious call stack signature, the source code of multiple classes, and the connection data corresponding to the suspicious call stack signature, the analysis module 504 is further configured to:

[0232] The suspicious call stack signature, the source code of multiple classes, and the connection data corresponding to the suspicious call stack signature are input into the code analysis model to obtain the source code analysis results output by the code analysis model. When the source code analysis result indicates the existence of code that causes connection leakage, the source code analysis result includes: an exception report, which includes: the class, method, and line number that caused the connection leakage, as well as the corresponding code snippet.

[0233] In an optional embodiment, the apparatus further includes a configuration optimization module, wherein the configuration optimization model 505 is used for:

[0234] When the connection pool is in an abnormal running state or the source code analysis results indicate the presence of code that could lead to connection leakage, the running state and source code analysis results are input into the optimization model to obtain configuration optimization suggestions output by the optimization model.

[0235] In an optional embodiment, the configuration optimization model 505 is further used for:

[0236] When the usage rate of the connection pool exceeds the usage rate threshold, or when the time required for an application to obtain a connection from the connection pool exceeds the acquisition time threshold, the connection pool is determined to be in an abnormal operating state.

[0237] Based on the description of the method and apparatus embodiments above, an exemplary embodiment of the present invention also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, which, when executed by the at least one processor, causes the electronic device to perform the method according to an embodiment of the present invention.

[0238] This application also provides a non-transitory computer-readable storage medium storing a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of this application.

[0239] This application also provides a computer program product, including a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of this application.

[0240] See Figure 6The diagram illustrates a structural block diagram of an electronic device 600 that can serve as a server or client in this application, serving as an example of hardware devices applicable to various aspects of this application. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.

[0241] like Figure 6 As shown, the electronic device 600 includes a computing unit 601, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 602 or a computer program loaded from a storage unit 608 into a random access memory (RAM) 603. The RAM 603 may also store various programs and data required for the operation of the device 600. The computing unit 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0242] Multiple components in electronic device 600 are connected to I / O interface 605, including: input unit 606, output unit 607, storage unit 608, and communication unit 609. Input unit 606 can be any type of device capable of inputting information to electronic device 600. Input unit 606 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of electronic device. Output unit 607 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 608 may include, but is not limited to, disks and optical discs. Communication unit 609 allows electronic device 600 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers and / or chipsets, such as Bluetooth devices, WiFi devices, worldwide interoperability for microwave access (WiMax) devices, cellular communication devices, and / or the like.

[0243] The computing unit 601 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above. For example, in some embodiments, the above-described connection leakage analysis method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 600 via ROM 602 and / or communication unit 609. In some embodiments, the computing unit 601 can be configured to perform the above-described connection leakage analysis method by any other suitable means (e.g., by means of firmware).

[0244] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0245] In the context of this application, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, RAM, ROM, erasable programmable read-only memory (EPROM) or flash memory, optical fibers, compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0246] As used in this application, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device, PLD) used to provide machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal used to provide machine instructions and / or data to a programmable processor.

[0247] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0248] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0249] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other.

[0250] Furthermore, it should be understood that the above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of the invention. Therefore, any equivalent variations made in accordance with the claims of this invention are still within the scope of this application.

Claims

1. A method for analyzing connection leakage, characterized in that, include: Obtain the connection data for each potential leaked connection, wherein the connection usage duration of each potential leaked connection is greater than the usage duration threshold, and the connection data includes: call stack information; Based on the call stack information of each potential leaked connection, a call stack signature is generated for each potential leaked connection. For each call stack signature, the following operations are performed: The time series of a call stack signature is acquired and analyzed to obtain a uniformity measure of the time distribution corresponding to the call stack signature, wherein the time series includes the time points of multiple potential leaking connections corresponding to the call stack signature; the occurrence frequency and corresponding uniformity measure of the time distribution of each call stack signature are normalized and weighted to obtain a suspicious value for each call stack signature; based on the suspicious values ​​of each call stack signature, suspicious call stack signatures whose suspicious values ​​meet preset suspicious conditions are selected from the call stack signatures. Extract multiple classes corresponding to the call stack information of the suspicious call stack signature, decompile the bytecode corresponding to the multiple classes, and obtain the source code of the multiple classes; Based on the suspicious call stack signature, the source code of the multiple classes, and the connection data corresponding to the suspicious call stack signature, the source code analysis result is determined. The source code analysis result is used to indicate whether there is code that causes connection leakage and the location of the code.

2. The method as described in claim 1, characterized in that, The connection data also includes: connection identifier, connection acquisition time, connection usage duration, and thread information.

3. The method as described in claim 1, characterized in that, The step of generating call stack signatures for each potentially leaked connection based on the call stack information of each potentially leaked connection includes: For each of the aforementioned potentially leaky connections, perform the following operations respectively: Normalize the call stack information of a potentially leaky connection; Extract core information from the call stack information of the potentially leaking connection, and generate a call stack signature for the potentially leaking connection based on the core information.

4. The method as described in claim 3, characterized in that, The normalization process for the call stack information of a potentially leaky connection includes: The irrelevant stack frames in the call stack information of the potentially leaking connection are filtered out, wherein the irrelevant stack frames are stack frames that are not related to the application code.

5. The method as described in claim 1, characterized in that, The step of decompiling the bytecode corresponding to the plurality of classes to obtain the source code of the plurality of classes includes: Filter out irrelevant classes from the plurality of classes; and / or, select multiple classes belonging to the upper-level stack frame from the plurality of classes; wherein, the irrelevant classes are classes that are not related to the connection leakage event, and the upper-level stack frame is a stack frame whose stack frame depth in the call stack information corresponding to the suspicious call stack signature meets the preset depth condition; By using a decompilation tool, the bytecode corresponding to the multiple classes is decompiled to obtain the source code of the multiple classes.

6. The method as described in claim 1, characterized in that, Before determining the source code analysis result based on the suspicious call stack signature, the source code of the multiple classes, and the connection data corresponding to the suspicious call stack signature, the process also includes: Irrelevant code is filtered out from the source code of the multiple classes, where irrelevant code is code that is not related to the core business logic.

7. The method as described in claim 2, characterized in that, The determination of source code analysis results based on the suspicious call stack signature, the source code of the multiple classes, and the connection data corresponding to the suspicious call stack signature includes: The suspicious call stack signature, the source code of the multiple classes, and the connection data corresponding to the suspicious call stack signature are input into the code analysis model to obtain the source code analysis result output by the code analysis model. When the source code analysis result indicates the existence of code that causes connection leakage, the source code analysis result includes: an exception report, which includes: the class, method, and line number that caused the connection leakage, as well as the corresponding code snippet.

8. The method as described in claim 1, characterized in that, The method further includes: When the connection pool is in an abnormal operating state or the source code analysis results indicate the presence of code that could lead to connection leakage, the operating state and the source code analysis results are input into the optimization model to obtain configuration optimization suggestions output by the optimization model.

9. The method as described in claim 8, characterized in that, The method further includes: When the usage rate of the connection pool exceeds the usage rate threshold, or when the time required for an application to obtain a connection from the connection pool exceeds the acquisition time threshold, the connection pool is determined to be in an abnormal operating state.

10. An analytical device for connecting leaks, characterized in that, include: The acquisition module is used to acquire the connection data of each potential leaked connection, wherein the connection usage time of each potential leaked connection is greater than the usage time threshold, and the connection data includes: call stack information; The first processing module is configured to generate call stack signatures for each potential leaking connection based on the call stack information of each potential leaking connection; and to perform the following operations on each call stack signature: acquire and analyze the time series of a call stack signature to obtain a uniformity measure of the time distribution corresponding to the call stack signature, wherein the time series includes the time points of multiple potential leaking connections corresponding to the call stack signature; normalize and weight the obtained occurrence counts and corresponding uniformity measures of the time distribution of each call stack signature to obtain a suspicious value for each call stack signature; and, based on the suspicious values ​​of each call stack signature, filter out suspicious call stack signatures whose suspicious values ​​meet preset suspicious conditions. The second processing module is used to extract multiple classes of call stack information corresponding to the suspicious call stack signature, decompile the bytecode corresponding to the multiple classes, and obtain the source code of the multiple classes. The analysis module is used to determine the source code analysis results based on the suspicious call stack signature, the source code of the multiple classes, and the connection data corresponding to the suspicious call stack signature. The source code analysis results are used to indicate whether there is code that causes connection leakage and the location of the code.

11. An electronic device, comprising: processor; as well as Stored program memory, The program includes instructions that, when executed by the processor, cause the processor to perform the method as described in any one of claims 1-9.

12. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-9.

Images