Memory leak detection method and device, electronic equipment and storage medium

Abstract

The invention discloses a memory leak detection method and device, electronic equipment and a storage medium, and relates to the technical field of big data or other related fields, and the method comprises the steps that in the execution process of a target process, a memory event of the target process is monitored, and a monitoring result is obtained, the memory event is used for indicating the change conditions of the virtual memory and the physical memory; establishing a virtual memory allocation table and a physical memory allocation table based on a monitoring result; based on a preset detection rule, the virtual memory allocation table and the physical memory allocation table are compared to obtain a comparison result, and the comparison result is used for recording R stack identifiers; and taking R call stacks corresponding to the R stack identifiers as suspected leak memories, and generating a memory leak detection result. According to the method and the device, the technical problem that the memory leak cannot be effectively detected when the Java program runs due to the fact that the monitoring and analysis capability on the Java memory object is insufficient in the related technology is solved.

Description

Technical Field

[0001] The present invention relates to the field of big data technology or other related fields, and in particular to a memory leak detection method and device, electronic device, and storage medium. Background Art

[0002] In modern software development, especially in scenarios involving large amounts of data processing and multi-threaded operations, memory management has become a key link in ensuring program stability and performance. Java, as a widely used programming language, has a complex memory model consisting of on-heap memory, off-heap memory, and direct memory. Among them, on-heap memory is managed by the JVM's automatic garbage collection mechanism (GC), while off-heap memory and direct memory are not directly controlled by GC, which makes the latter more challenging to manage, especially direct memory. Since its allocation and release mechanism is out of the JVM's sight, it is easy to cause memory leaks, which in turn affects system performance and stability.

[0003] In the related technologies, although memory management tools and technologies can provide a certain degree of memory usage analysis, they are often limited to monitoring heap memory, and the real-time monitoring and analysis capabilities of off-heap and direct memory are relatively limited. For example, some tools need to be pre-configured when the program starts and cannot be dynamically enabled during operation, which not only limits flexibility but may also have a significant impact on program performance. In addition, some tools rely on specific memory allocators, which greatly reduces the ability to detect memory allocations that use other memory management strategies or directly call the underlying functions of the operating system. Moreover, when some tools provide in-depth memory usage details, they require the program to be restarted and the default memory management functions to be replaced, which makes the analysis process extremely invasive and difficult to implement in a production environment.

[0004] Therefore, existing technologies have obvious limitations in direct memory management and leak detection, especially the lack of dynamic monitoring capabilities during program runtime, dependence on specific memory allocators, and intrusive analysis methods, which bring challenges to solving direct memory leak problems.

[0005] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0006] The main purpose of the present application is to provide a memory leak detection method and its device, electronic device, and storage medium, so as to at least solve the technical problem in the related art that memory leaks cannot be effectively detected when a Java program is running due to insufficient monitoring and analysis capabilities of Java memory objects.

[0007] In order to achieve the above-mentioned purpose, according to one aspect of the present application, a memory leak detection method is provided, the method comprising: during the execution of a target process, monitoring the memory events of the target process to obtain monitoring results, wherein the memory events are used to indicate changes in virtual memory and physical memory; establishing a virtual memory allocation table and a physical memory allocation table based on the monitoring results; based on preset detection rules, comparing the virtual memory allocation table and the physical memory allocation table to obtain a comparison result, wherein the comparison result is used to record R stack identifiers, R being a preset value; and using R call stacks corresponding to the R stack identifiers as suspected leaked memory to generate a memory leak detection result.

[0008] Furthermore, the step of monitoring the memory events of the target process and obtaining monitoring results includes: determining a target kernel probe based on an event type of the memory event, wherein the event type includes: a virtual memory allocation event, a virtual memory release event, and a system page fault event; locating an execution program of the target process, and inserting the target kernel probe into a specified position of the execution program; during the execution of the execution program, receiving a detection result of the target kernel probe, wherein the detection result is used to record call information of a call function corresponding to the event type; and generating the monitoring result based on the call information indicated by the detection result.

[0009] Furthermore, the step of receiving the detection result of the target kernel probe includes: when the event type is a virtual memory allocation event, determining the memory request function called by the execution program, wherein the target kernel probe is inserted in the memory request function; obtaining a first type of input parameter and a first type of return value of the memory request function through the target kernel probe, wherein the first type of input parameter is used to indicate a first virtual memory range applied for allocation by the target process; when the first type of return value indicates that the memory allocation is successful, parsing the first type of return value to obtain a first virtual memory address allocated to the target process; and generating the detection result based on the first virtual memory range and the first virtual memory address.

[0010] Furthermore, the step of receiving the detection result of the target kernel probe also includes: when the event type is a virtual memory release event, determining the memory release function called by the execution program, wherein the target kernel probe is inserted in the memory release function; obtaining the second type of input parameters and the second type of return value of the memory release function through the target kernel probe, wherein the second type of input parameters are used to indicate the second virtual memory range applied for release by the target process; when the second type of return value indicates that the memory release is successful, parsing the return value to obtain the second virtual memory address of the successful release; generating the detection result based on the second virtual memory range and the second virtual memory address.

[0011] Furthermore, the step of receiving the detection result of the target kernel probe also includes: when the event type is a system page fault interrupt event, determining the page fault handling function called by the execution program, wherein the target kernel probe is inserted in the page fault handling function; obtaining the third type of input parameters and the third type of return value of the page fault handling function through the target kernel probe, wherein the third type of input parameters are used to indicate the third virtual memory address accessed by the target process; when the third type of return value indicates that the memory access is successful, generating the detection result based on the third virtual memory address.

[0012] Furthermore, the step of establishing a virtual memory allocation table and a physical memory allocation table based on the monitoring results includes: when the event type is a virtual memory allocation event, using the process ID of the target process, the first virtual memory address, the allocated virtual memory capacity and the first time point as table fields to generate the virtual memory allocation table, wherein the first time point refers to the time point when the virtual memory is allocated to the target process; when the event type is a virtual memory release event, searching the virtual memory allocation table based on the second virtual memory address, and deleting the found table entry to obtain the updated virtual memory allocation table; when the event type is a system page fault interrupt event, using the third virtual memory address and the second time point as table fields to generate the physical memory allocation table, wherein the second time point refers to the time point when the physical memory is associated with the target process.

[0013] Furthermore, based on preset detection rules, the step of comparing the virtual memory allocation table and the physical memory allocation table to obtain a comparison result includes: traversing the physical memory allocation table, wherein the physical memory allocation table contains S physical memory allocation records, each of which includes at least the following content: an associated virtual memory address and an associated time point in the physical memory, where S is an integer greater than R; for each of the physical memory allocation records, querying the virtual memory allocation table based on the virtual memory address to obtain a query result; based on the preset detection rules, when the query result indicates that the virtual memory allocation table does not contain a memory application record for the virtual memory address, or contains a memory release record corresponding to the virtual memory address, or the memory is not released for an expected time period, determining that the virtual memory address is an abnormal memory; after the traversal is completed, integrating all the abnormal memories, and determining the stack identifiers corresponding to the abnormal memories in the physical memory one by one, to obtain R stack identifiers in the comparison result.

[0014] In order to achieve the above-mentioned purpose, according to another aspect of the present application, a memory leak detection device is also provided, which includes: a monitoring unit, used to monitor the memory events of the target process during the execution of the target process, and obtain monitoring results, wherein the memory events are used to indicate changes in virtual memory and physical memory; an establishment unit, used to establish a virtual memory allocation table and a physical memory allocation table based on the monitoring results; a comparison unit, used to compare the virtual memory allocation table and the physical memory allocation table based on preset detection rules to obtain a comparison result, wherein the comparison result is used to record R stack identifiers, R is a preset value; a generation unit, used to use R call stacks corresponding to the R stack identifiers as suspected leaked memory to generate a memory leak detection result.

[0015] Furthermore, the monitoring unit includes: a first determination module, used to determine the target kernel probe based on the event type of the memory event, wherein the event type includes: virtual memory allocation event, virtual memory release event and system page fault event; a positioning module, used to locate the execution program of the target process and insert the target kernel probe into a specified position of the execution program; a receiving module, used to receive the detection result of the target kernel probe during the execution of the execution program, wherein the detection result is used to record the calling information of the calling function corresponding to the event type; a first generating module, used to generate the monitoring result based on the calling information indicated by the detection result.

[0016] Furthermore, the receiving module includes: a first determination submodule, used to determine the memory request function called by the execution program when the event type is a virtual memory allocation event, wherein the target kernel probe is inserted in the memory request function; a first acquisition submodule, used to obtain the first type of input parameters and the first type of return value of the memory request function through the target kernel probe, wherein the first type of input parameters are used to indicate the first virtual memory range applied for allocation by the target process; a first parsing submodule, used to parse the first type of return value when the first type of return value indicates that the memory allocation is successful, and obtain the first virtual memory address allocated to the target process; a first generation submodule, used to generate the detection result based on the first virtual memory range and the first virtual memory address.

[0017] Furthermore, the receiving module also includes: a second determination submodule, used to determine the memory release function called by the execution program when the event type is a virtual memory release event, wherein the target kernel probe is inserted in the memory release function; a second acquisition submodule, used to obtain the second type of input parameters and the second type of return value of the memory release function through the target kernel probe, wherein the second type of input parameters are used to indicate the second virtual memory range applied for release by the target process; a second parsing submodule, used to parse the return value when the second type of return value indicates that the memory release is successful, and obtain the second virtual memory address that is successfully released; a second generation submodule, used to generate the detection result based on the second virtual memory range and the second virtual memory address.

[0018] Furthermore, the receiving module also includes: a third determination submodule, used to determine the page fault handling function called by the execution program when the event type is a system page fault interrupt event, wherein the target kernel probe is inserted in the page fault handling function; a third acquisition submodule, used to obtain the third type of input parameters and the third type of return value of the page fault handling function through the target kernel probe, wherein the third type of input parameters are used to indicate the third virtual memory address accessed by the target process; a third generation submodule, used to generate the detection result based on the third virtual memory address when the third type of return value indicates that the memory access is successful.

[0019] Furthermore, the establishment unit includes: a second generation module, which is used to generate the virtual memory allocation table with the process ID of the target process, the first virtual memory address, the allocated virtual memory capacity and the first time point as table fields when the event type is a virtual memory allocation event, wherein the first time point refers to the time point when the virtual memory is allocated to the target process; a deletion module, which is used to search the virtual memory allocation table based on the second virtual memory address when the event type is a virtual memory release event, and delete the found table entries to obtain the updated virtual memory allocation table; a third generation module, which is used to generate the physical memory allocation table with the third virtual memory address and the second time point as table fields when the event type is a system page fault interrupt event, wherein the second time point refers to the time point when the physical memory is associated with the target process.

[0020] Furthermore, the comparison unit includes: a traversal module, used to traverse the physical memory allocation table, wherein the physical memory allocation table contains S physical memory allocation records, and each of the physical memory allocation records includes at least the following contents: an associated virtual memory address and an associated time point in the physical memory, where S is an integer greater than R; a query module, used to query the virtual memory allocation table based on the virtual memory address for each of the physical memory allocation records to obtain a query result; a second determination module, used to determine, based on the preset detection rule, that the virtual memory allocation table does not contain a memory application record for the virtual memory address, or contains a memory release record corresponding to the virtual memory address, or the memory has not been released for an expected time period, that the virtual memory address is an abnormal memory; an integration module, used to integrate all the abnormal memories after the traversal is completed, and determine the stack identifiers corresponding to the abnormal memories in the physical memory one by one to obtain the R stack identifiers in the comparison result.

[0021] In order to achieve the above-mentioned purpose, according to another aspect of the present application, a computer-readable storage medium is further provided, wherein the computer-readable storage medium includes a stored computer program, wherein when the computer program is running, the device where the computer-readable storage medium is located is controlled to execute any one of the memory leak detection methods described above.

[0022] In order to achieve the above-mentioned purpose, according to another aspect of the present application, an electronic device is also provided, including one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement any one of the memory leak detection methods described above.

[0023] The present invention proposes a method for detecting memory leaks. First, during the execution of the target process, the memory events of the target process are monitored to obtain monitoring results, wherein the memory events are used to indicate changes in virtual memory and physical memory. A virtual memory allocation table and a physical memory allocation table are established based on the monitoring results. Then, based on preset detection rules, the virtual memory allocation table and the physical memory allocation table are compared to obtain comparison results, wherein the comparison results are used to record R stack identifiers, where R is a preset value. Finally, R call stacks corresponding to the R stack identifiers are used as suspected leaked memory to generate a memory leak detection result.

[0024] In the present invention, a dynamic monitoring method is adopted, and by tracking virtual memory and physical memory change events during the execution of the target process, the purpose of real-time recording and analyzing memory allocation and release is achieved, thereby achieving the technical effect of accurately locating the suspected memory leak call stack. Specifically, by real-time tracking and comparing memory events, the suspected leaked memory block is quickly located, and further traced back to the corresponding code path, so that the root cause of the problem can be quickly focused on, effectively shortening the time for problem location and repair, thereby improving the efficiency of software maintenance and development. At the same time, since the present invention directly monitors at the memory allocator and system levels, it can cover the memory area that the JVM cannot directly manage, for comprehensive monitoring of the memory usage of the Java program, ensuring its stability under large-scale data processing and long-term operation. Compared with the prior art, through the present invention, developers can implement memory leak detection when the Java program is running without restarting or modifying the program, which not only avoids the complexity and performance loss of opening traditional tools, but also can monitor the allocation and release of direct memory in real time, which has a significant effect on improving the robustness and maintenance efficiency of Java applications, thereby solving the technical problem in the related art that the monitoring and analysis capabilities of Java memory objects are insufficient, resulting in the inability to effectively detect memory leaks when the Java program is running. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The drawings constituting a part of the present application are used to provide a further understanding of the present application. The illustrative embodiments and descriptions of the present application are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0026] Figure 1 A hardware structure block diagram of a computer terminal (or mobile device) for implementing a method for detecting a memory leak is shown;

[0027] Figure 2 is a flow chart of an optional memory leak detection method according to an embodiment of the present invention;

[0028] Figure 3is a schematic diagram of an optional memory leak detection device according to an embodiment of the present invention;

[0029] Figure 4 The present invention is a structural block diagram of an electronic device for executing a method for detecting a memory leak according to an embodiment of the present invention. DETAILED DESCRIPTION

[0030] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0031] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0032] To facilitate those skilled in the art to understand the present invention, some terms or nouns involved in the embodiments of the present invention are explained below:

[0033] eBPF, Extended Berkeley Packet Filter, is a high-performance, secure and flexible programming technology running in the Linux kernel. It was originally designed for network packet filtering and later evolved into a general kernel event processing framework. eBPF allows users to execute customized programs at the kernel level without modifying or recompiling the kernel code, which greatly enhances its application scope and scenarios.

[0034] It should be noted that the memory leak detection method and device in the present application can be used in the field of big data technology when real-time processing and analysis of massive data is performed, and can also be used in any field other than the field of big data technology when real-time processing and analysis of massive data is performed. The application field of the memory leak detection method and device in the present application is not limited.

[0035] It should be noted that the relevant information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, storage, processing, transmission, provision, disclosure, use and processing of the relevant data comply with the laws, regulations and standards of the relevant regions, take necessary confidentiality measures, do not violate public order and good customs, and provide corresponding operation entrances for users to choose to authorize or refuse. For example, an interface is set up between this system and relevant users or organizations. Before obtaining relevant information, it is necessary to send an acquisition request to the aforementioned user or organization through the interface, and obtain relevant information after receiving the consent information fed back by the aforementioned user or organization.

[0036] The information collection (for example, user voice, video, and text collection) and analysis operations involved in this application have provided users with corresponding operation entrances when they are executed, allowing users to choose to agree or reject the automated decision-making results; if the user chooses to reject, the expert decision-making process will be entered.

[0037] The following embodiments of the present invention can be applied to various systems / applications / devices that require real-time processing and analysis of massive data, and can dynamically monitor direct memory operations of Java applications, detect and locate possible memory leaks in real time, and ensure the stability and performance of large data processing systems.

[0038] Specifically, in big data processing scenarios such as stream processing, batch processing or data mining, this method can accurately record and analyze memory usage without affecting the running efficiency of Java programs and data processing speed, effectively preventing system performance degradation or crashes caused by memory leaks, and providing solid technical support for big data applications.

[0039] The present invention is described in detail below in conjunction with various embodiments.

[0040] Embodiment 1

[0041] According to an embodiment of the present invention, an embodiment of a method for detecting a memory leak is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0042] The memory leak detection method embodiment provided in the first embodiment of the present invention may be executed in a mobile terminal, a computer terminal or a similar computing device. Figure 1The hardware structure block diagram of a computer terminal (or mobile device) for implementing a memory leak detection method is shown. Figure 1 As shown, the computer terminal 10 (or mobile device) may include one or more (102a, 102b, ..., 102n are used to illustrate) processors 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the BUS bus), a network interface, a power supply and / or a camera. It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations shown.

[0043] It should be noted that the one or more processors 102 and / or other data processing circuits described above may generally be referred to herein as "data processing circuits". The data processing circuits may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. In addition, the data processing circuit may be a single independent processing module, or may be incorporated in whole or in part into any of the other components in the computer terminal 10 (or mobile device). As described in the embodiments of the present application, the data processing circuit acts as a processor control (e.g., selection of a variable resistor terminal path connected to an interface).

[0044] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the memory leak detection method in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, the above-mentioned memory leak detection method is realized. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories may be connected to the computer terminal 10 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0045] The transmission device 106 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the computer terminal 10. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0046] The display may be, for example, a touch screen liquid crystal display (LCD) that enables a user to interact with a user interface of the computer terminal 10 (or mobile device).

[0047] Under the above operating environment, the present invention provides Figure 2 The memory leak detection method shown in the figure is implemented by the eBPF system, which is combined with Java memory management technology and is used in Java application running scenarios, especially for memory leaks caused by direct memory operations. It uses dynamic tracking and data structure synchronization to specifically monitor the memory application, release and page fault interruption events of the process in real time during the execution of the target process, establish and update the virtual memory allocation table and the physical memory mapping table, and then compare the two tables according to preset rules, count and analyze the most frequently occurring R stack identifiers, and then locate the suspected leaked call stack to achieve the purpose of accurate and non-invasive detection of Java program memory leaks.

[0048] The embodiment of the present invention is described in detail below in conjunction with various specific steps.

[0049] Figure 2 is a flowchart of an optional memory leak detection method according to an embodiment of the present invention, such as Figure 2 As shown, the method comprises the following steps:

[0050] Step S201, during the execution of the target process, the memory events of the target process are monitored to obtain monitoring results, wherein the memory events are used to indicate changes in virtual memory and physical memory.

[0051] The core of step S201 is to use the probe technology of the eBPF framework to dynamically track different types of memory events, thereby generating detailed monitoring results, aiming to monitor the memory operations of the target Java process at runtime in real time to capture signs of changes in virtual memory and physical memory.

[0052] Specifically, the target process refers to the Java application process that needs to be tested for memory leaks. In scenarios such as big data processing, the target process involves the processing of massive amounts of data, which places extremely high demands on the efficiency and accuracy of memory management. Memory events refer to various events related to memory allocation, release, and access during program execution. They are key clues for monitoring Java memory usage and can reveal potential problems in memory management.

[0053] Virtual memory refers to the address space allocated by the operating system to the Java process, which is generally larger than the total capacity of the system's physical memory. Physical memory refers to the physical RAM actually occupied by virtual memory. The allocation and release of virtual memory and the mapping and page fault exceptions of physical memory are all changes. The present invention aims to monitor and record these changes in order to analyze memory leaks.

[0054] Optionally, step S201 includes: determining the target kernel probe based on the event type of the memory event, wherein the event type includes: virtual memory allocation event, virtual memory release event and system page fault event; locating the execution program of the target process, and inserting the target kernel probe into a specified position of the execution program; during the execution of the execution program, receiving the detection result of the target kernel probe, wherein the detection result is used to record the calling information of the calling function corresponding to the event type; generating a monitoring result based on the calling information indicated by the detection result.

[0055] It should be noted that event types include virtual memory allocation events, virtual memory release events, and system page fault events. Among them, virtual memory allocation events occur when the Java process calls a memory allocation function; virtual memory release events occur when calling free and other functions to release memory; and system page fault events are triggered when the Java process attempts to access a virtual address that is not mapped to physical memory.

[0056] Specifically, virtual memory allocation events refer to memory events triggered when a Java application calls functions such as malloc, calloc, or realloc to apply for virtual memory. The present invention monitors the calls of these functions through eBPF probes and records information such as the thread ID, virtual address, memory size, and call stack of the application.

[0057] Virtual memory release events are memory events triggered when a Java application calls the free function to release virtual memory. The thread ID and virtual address of the release operation are recorded through the eBPF probe to match them with the allocation event to determine whether there is unreleased memory.

[0058] System page fault events refer to abnormal events triggered by the operating system when a Java process accesses an area in the virtual address space that is not mapped to physical memory. The present invention uses eBPF probes to track kernel functions that handle page fault events, such as handle_mm_fault, and records the virtual address and timestamp that triggers the page fault for subsequent analysis of the mapping of physical memory.

[0059] Target kernel probes refer to probe types such as KPROBE and UPROBE in the eBPF framework, which can be inserted into designated locations of kernel and user state to monitor specific function calls or kernel events. In the present invention, target kernel probes are used to track the above three memory events.

[0060] Inserting the target kernel probe into the specified position of the executing program refers to inserting it into the position of calling the memory allocation or release function (i.e., calling function) in the user-mode program, as well as the function entry of processing memory-related events in the kernel, so that the occurrence of memory events can be tracked in real time. Among them, the calling function refers to the memory management function called in the Java application, such as malloc, free, etc., and the function that processes memory management in the operating system kernel, such as handle_mm_fault. The calling information includes the parameter value, return value, calling time, and calling stack when calling the function, which is crucial for analyzing the specific context of memory operations and locating potential leaks.

[0061] When implementing the above steps, the present invention first selects and configures the corresponding eBPF probe (such as KPROBE, UPROBE) based on the memory event type to be monitored, and then locates the execution program of the target process, and inserts the probe into the function call related to the memory operation in the program, as well as the function entry for processing the page fault interrupt in the kernel. During the execution of the program, the eBPF probe will capture and record the call information of the calling function corresponding to the event type in real time, including the details of applying for and releasing virtual memory and the triggering time of the page fault interrupt, etc. All captured information will be stored in the eBPF map data structure, so that the user-mode program can synchronously obtain these data, and further analyze and determine whether there is a memory leak.

[0062] The embodiment of the present invention can effectively monitor the memory usage of the target process without affecting the performance of the target process through dynamic insertion and data recording of the eBPF probe, thereby providing powerful technical support for preventing and repairing memory leaks.

[0063] Optionally, the step of receiving the detection result of the target kernel probe includes: when the event type is a virtual memory allocation event, determining the memory request function called by the execution program, wherein the target kernel probe is inserted in the memory request function; obtaining the first type of input parameter and the first type of return value of the memory request function through the target kernel probe, wherein the first type of input parameter is used to indicate the first virtual memory range applied for allocation by the target process; when the first type of return value indicates that the memory allocation is successful, parsing the first type of return value to obtain the first virtual memory address allocated to the target process; and generating the detection result based on the first virtual memory range and the first virtual memory address.

[0064] It should be noted that the Java application calls the memory application function in the standard library in the user state, such as malloc, calloc or realloc, and completes the allocation of virtual memory by interacting with the operating system kernel at the bottom layer. The present invention uses the eBPF framework to insert probes (target kernel probes) into the call entry of these functions to capture the behavior of memory allocation in real time.

[0065] The first type of input parameters refers to the parameters when calling the memory allocation function, such as the requested memory size passed in when calling malloc; the first type of return value is the return result after the function call. If the return value is a valid memory address, it means that the memory allocation is successful; if the return value is empty (NULL) or a negative number, it means that the memory allocation failed.

[0066] The first virtual memory range is determined by the first type of input parameters, that is, the operating system virtual address space range requested by the Java process through the memory request function, including the starting address and size, which is used to record the specific requirements of the Java process when applying for memory; the first virtual memory address is obtained by parsing the first type of return value when the first type of return value indicates that the memory allocation is successful, and is the starting address of the virtual memory actually allocated to the Java process.

[0067] When the event type is a virtual memory allocation event, the target kernel probe is inserted into the memory allocation function, such as the call entry of malloc, calloc or realloc, to ensure that the memory allocation request can be monitored in real time. By executing the bpf_get_current_pid_tgid() function, the process ID and thread ID of the current call to the memory allocation function are obtained, and then the eBPF probe is used to obtain the first type of input parameter (memory size) and the first type of return value (allocated memory address) of the memory allocation function. If the first type of return value is valid, it means that the memory allocation is successful.

[0068] If the memory allocation is successful, the first type of return value is further parsed to obtain the allocated first virtual memory address, which indicates the starting position of the virtual memory accessible to the Java process. The detection result is generated based on the first virtual memory range (determined by the first type of input parameter) and the first virtual memory address, including: thread ID, first virtual memory address, memory size, application time, call stack id and other information, which is used for subsequent memory usage analysis and leak detection.

[0069] Through the above steps, the present invention can accurately capture the operations of the Java process on the virtual memory during operation, especially the behavioral details in the application allocation stage. The generated detection results provide the necessary data basis for subsequent memory usage analysis and leak detection, which helps to locate and repair memory leak problems more efficiently, especially in scenarios with high requirements for memory management such as big data processing.

[0070] The key to the above process is to use eBPF probes to monitor user-mode calls and kernel responses non-invasively, ensuring that the detection of Java processes is both accurate and does not affect their normal operation.

[0071] Optionally, the step of receiving the detection result of the target kernel probe also includes: when the event type is a virtual memory release event, determining the memory release function called by the execution program, wherein the target kernel probe is inserted in the memory release function; obtaining the second type of input parameters and the second type of return value of the memory release function through the target kernel probe, wherein the second type of input parameters are used to indicate the second virtual memory range applied for release by the target process; when the second type of return value indicates that the memory release is successful, parsing the return value to obtain the second virtual memory address that was successfully released; and generating the detection result based on the second virtual memory range and the second virtual memory address.

[0072] In the embodiment of the present invention, receiving the detection result of the target kernel probe not only includes monitoring of virtual memory allocation events, but also covers real-time tracking and analysis of virtual memory release events.

[0073] It should be noted that Java applications call free and other memory release functions in user mode to release memory previously allocated by malloc, calloc or realloc functions. The present invention inserts the target kernel probe into the entry of these release functions through the eBPF framework to monitor the behavior of memory release in real time.

[0074] The second type of input parameters refers to the parameters when calling the memory release function (usually the target virtual memory address), and the second type of return value is the result of the function call. If the return value indicates 0 or a successful release signal, it means that the memory has been successfully released. When tracking memory release events, this information is used to confirm whether the memory is correctly released and to verify the validity of the release operation at the kernel level.

[0075] The second virtual memory range is determined by the second type of input parameter, which refers to the virtual memory address range to be released by the Java process through the memory release function. Recording this range helps the kernel probe find and delete the corresponding entries from the virtual memory allocation table after the memory is successfully released, thereby ensuring the accuracy of memory management data.

[0076] The second virtual memory address refers to the virtual memory address passed to the kernel in the memory release function call, which is used to indicate the specific memory location that the Java process wants to release. When the second type of return value confirms that the memory release is successful, the address will be used for subsequent kernel data table update operations.

[0077] In the case of a virtual memory release event, the target kernel probe is inserted into the memory release function, such as the call entry of free, so as to monitor the request and response of memory release in real time. When the free function is called, the second type of input parameter (virtual memory address) and the second type of return value (release status) are obtained through the eBPF probe. If the second type of return value indicates that the memory release is successful (such as the return value is 0), it means that the Java process has successfully released the specified virtual memory.

[0078] When the memory release is confirmed to be successful, the second type of return value is further parsed to obtain the virtual memory address to be released (given by the second type of input parameter), which is the starting address of the virtual memory that the Java process once allocated and now releases. Based on the second virtual memory range (determined by the second type of input parameter) and the second virtual memory address, a detection result is generated, including: the operation thread ID of the memory release, the released virtual memory address, the release time, and possible call stack ID and other information, which is used for subsequent memory status updates and leak detection.

[0079] Through the above steps, the present invention can capture in real time the details of the Java process's virtual memory release operation during operation, especially the specific situation when the memory is released successfully. The generated detection results not only record the released memory address and time, but also help update the memory management data structure, such as the virtual memory allocation table and the physical memory mapping table, to reflect the actual usage status of the memory. The above process is crucial for detecting direct memory leaks and helps to identify memory that is allocated but not released, thereby providing a basis for repairing memory leaks and optimizing the memory management of Java programs.

[0080] The embodiment of the present invention utilizes the eBPF probe to perform non-intrusive monitoring on user-mode calls and kernel responses, thereby ensuring the accuracy of the data and avoiding the impact on the performance of the Java process.

[0081] Optionally, the step of receiving the detection result of the target kernel probe also includes: when the event type is a system page fault interrupt event, determining the page fault handling function called by the execution program, wherein the target kernel probe is inserted in the page fault handling function; obtaining the third type of input parameters and the third type of return value of the page fault handling function through the target kernel probe, wherein the third type of input parameters are used to indicate the third virtual memory address accessed by the target process; when the third type of return value indicates that the memory access is successful, generating the detection result based on the third virtual memory address.

[0082] The monitoring of the system page fault interruption event by the memory leak detection method of the present invention is an important link for understanding the actual use of physical memory by Java applications.

[0083] It should be noted that the page fault handling function refers to the page fault interrupt that is triggered when a Java process attempts to access a virtual page in its virtual address space that has not yet been mapped to physical memory. At this time, the page fault handling function (such as handle_mm_fault) in the operating system kernel is used to handle it. The present invention uses the eBPF framework to insert the target kernel probe into such a page fault handling function to track the mapping process from virtual memory to physical memory in real time.

[0084] The third type of input parameters contains the virtual memory address that triggers the page fault interrupt and other information related to the access request, such as the access type (read, write), the accessed process ID, etc. The third type of return value indicates the result of the kernel processing the page fault interrupt. If the return value is 0, it means that the physical memory page is successfully mapped to the virtual address space, that is, the memory access is successful.

[0085] The third virtual memory address refers to the virtual memory address that the Java process attempts to access when a page fault interrupt is triggered. This address will be mapped to the physical memory when it is processed at the kernel level, so that the Java process can actually access the required data.

[0086] When the event type is a system page fault interrupt event, the target kernel probe is located and inserted into the page fault handling function (such as handle_mm_fault) at the kernel level to ensure that the triggering and processing of the page fault interrupt can be captured in real time. When the Java process accesses a virtual page that has not yet been mapped to the physical memory, a system page fault interrupt is triggered, and then the kernel calls the page fault handling function.

[0087] At this time, the third type of input parameter (the virtual memory address that triggers the page fault) and the third type of return value (processing result) are obtained through the eBPF probe. If the third type of return value is 0, it means that the kernel has successfully processed the page fault interrupt, the physical memory page is mapped to the virtual memory address, and the memory access is successful.

[0088] Based on the third virtual memory address and the processing result, a detection result is generated, including the thread ID, the virtual memory address at the time of the page fault interrupt, the mapping time, and the original function information called (if available), which is used for subsequent physical memory mapping situation analysis and leak detection.

[0089] Through the above steps, the present invention can track in real time the actual access and use of physical memory by the Java process during operation, especially the page fault interrupt event when accessing physical memory through virtual memory. The generated detection result provides the mapping relationship between physical memory page and virtual memory address and the timestamp of the mapping operation, which is helpful to determine which virtual memory areas have been actually used and which unused areas may involve memory leaks.

[0090] The present invention ensures a comprehensive grasp of system page fault interruption events without interfering with the normal operation of Java processes through non-intrusive monitoring of the kernel level by eBPF probes, further enhancing the accuracy and real-time performance of memory leak detection. This process does not require modification of Java applications or restarting, and is suitable for various scenarios that are sensitive to memory management, especially in fields that require high memory efficiency, such as big data processing.

[0091] Step S202: establishing a virtual memory allocation table and a physical memory allocation table based on the monitoring result.

[0092] In the memory leak detection method of the present invention, establishing a virtual memory allocation table and a physical memory allocation table is a basic step for recording and analyzing memory usage based on monitoring results.

[0093] The virtual memory allocation table is a data structure that records the virtual memory allocation of the Java process. It can be implemented using eBPF's map to ensure efficient data reading and writing. The physical memory allocation table is a data structure that records the mapping of the Java process's virtual memory to the physical memory. It is also implemented using eBPF's map.

[0094] Optionally, step S202 includes: when the event type is a virtual memory allocation event, generating a virtual memory allocation table with the process ID of the target process, the first virtual memory address, the allocated virtual memory capacity and the first time point as table fields, wherein the first time point refers to the time point when the virtual memory is allocated to the target process; when the event type is a virtual memory release event, searching the virtual memory allocation table based on the second virtual memory address, and deleting the found table entry to obtain an updated virtual memory allocation table; when the event type is a system page fault interrupt event, generating a physical memory allocation table with the third virtual memory address and the second time point as table fields, wherein the second time point refers to the time point when the physical memory is associated with the target process.

[0095] The virtual memory allocation table contains the following fields: the process ID of the target process, which is used to identify the Java application process that performs memory operations; the first virtual memory address, which is the starting address of the virtual memory requested and allocated by the Java process; the allocated virtual memory capacity, which is the memory size allocated to the Java process through the virtual memory request function; the first time point, which is used to record the specific time of memory allocation, obtained through the kernel function bpf_ktime_get_ns, and used to analyze the time series of memory usage.

[0096] The physical memory allocation table contains the following fields: the third virtual memory address, which is the virtual memory address that the Java process attempts to access in the system page fault interrupt event. This address is mapped to the physical memory after the page fault interrupt is processed; the second time point, which is used to record the specific time when the physical memory is mapped to the virtual address, and is used to analyze the usage of physical memory and the mapping time series of virtual memory to physical memory.

[0097] When the monitoring result indicates a virtual memory allocation event, the eBPF probe is used to obtain the process ID, first virtual memory address, allocated virtual memory capacity, first time point and other information of the target process in real time, and store them in the virtual memory allocation table to form a memory allocation record. Each record identifies the entire situation of a memory allocation operation, which is convenient for subsequent memory usage analysis.

[0098] When the monitoring result indicates a virtual memory release event, the corresponding record in the virtual memory allocation table is searched according to the released second virtual memory address. If a matching entry is found, it means that the memory area has been allocated and is now released. The entry in the virtual memory allocation table is deleted and the table is updated to reflect the status after the memory is released. This helps to maintain the real-time accuracy of the virtual memory allocation table and facilitates subsequent analysis.

[0099] When the monitoring result indicates a system page fault interrupt event, the third virtual memory address and the second time point are recorded. This is because the page fault interrupt event indicates that the Java process attempts to access an area in the virtual address space that has not been mapped to the physical memory. The operating system kernel handles this interrupt, allocates physical memory and maps it to the virtual address, which helps to establish a mapping relationship between virtual memory and physical memory in the physical memory allocation table, which is of great significance for analyzing direct memory usage and detecting memory leaks.

[0100] Through the above steps, the present invention can dynamically establish and maintain a virtual memory allocation table and a physical memory allocation table when the Java process is running, thereby clearly recording each memory allocation and release and the mapping of virtual memory to physical memory. The establishment and update of the above data structure provides a solid data foundation for subsequent memory usage analysis and leak detection.

[0101] The embodiment of the present invention utilizes the high performance characteristics of the eBPF framework and can be performed almost imperceptibly without having a significant negative impact on the overall performance of the Java process or system. It is particularly suitable for applications in environments with extremely high performance requirements, such as network monitoring and big data processing.

[0102] The key to the above process is to ensure the accurate recording of virtual memory allocation and release and the real-time update of physical memory mapping. The joint action of the virtual memory allocation table and the physical memory allocation table can accurately track the entire life cycle of virtual memory to physical memory in the Java process, and then discover and locate potential memory leaks, which has a significant effect on improving the stability and performance of Java applications.

[0103] Step S203, based on the preset detection rule, compare the virtual memory allocation table and the physical memory allocation table to obtain a comparison result, wherein the comparison result is used to record R stack identifiers, where R is a preset value.

[0104] In the memory leak detection method of the present invention, step S203 is a key step of comparing the virtual memory allocation table with the physical memory allocation table to discover potential memory leaks.

[0105] It should be noted that the preset detection rules are a set of criteria used to determine whether memory allocation and release behaviors are abnormal. The preset detection rules mainly include the following aspects:

[0106] 1. Check whether each record in the physical memory allocation table can be mapped to the corresponding allocation record in the virtual memory allocation table. If it cannot be mapped, it means that the mapping of this part of the physical memory is not explicitly requested by the Java program, and there is an exception.

[0107] 2. Check whether the records in the virtual memory allocation table have corresponding mapping records in the physical memory allocation table. If there are mapping records but the memory release operation recorded in the virtual memory allocation table does not reflect the corresponding physical memory release (that is, the cancellation of the mapping) in the physical memory allocation table, it may involve a memory leak.

[0108] 3. Check whether the virtual memory is released within the expected time period after allocation. If the records in the virtual memory allocation table are not deleted within the time period, that is, this part of the memory is not released, it may constitute a memory leak.

[0109] Furthermore, the stack identifier refers to the call stack id (i.e., stackid) obtained by the eBPF probe during the monitoring process of memory allocation and release. The identifier is related to the specific function call path and helps to quickly trace back to the specific code location that caused the memory allocation or release behavior. The stack identifier corresponding to the abnormal memory is integrated in the present invention to help quickly locate the possible source of memory leaks.

[0110] Optionally, step S203 includes: traversing a physical memory allocation table, wherein the physical memory allocation table contains S physical memory allocation records, each physical memory allocation record includes at least the following contents: an associated virtual memory address in the physical memory and an associated time point, where S is an integer greater than R; for each physical memory allocation record, querying the virtual memory allocation table based on the virtual memory address to obtain a query result; based on a preset detection rule, when the query result indicates that the virtual memory allocation table does not contain a memory application record for the virtual memory address, or contains a memory release record corresponding to the virtual memory address, or the memory is not released for an expected time period, determining that the virtual memory address is abnormal memory; after the traversal is completed, integrating all abnormal memories, and determining the stack identifiers corresponding to the abnormal memories in the physical memory one by one, to obtain R stack identifiers in the comparison result.

[0111] It should be noted that the physical memory allocation record is each record in the physical memory allocation table, which contains the virtual memory address associated with the physical memory and the associated time point. By traversing the physical memory allocation record and comparing it with the virtual memory allocation table, it is possible to find virtual addresses that are mapped to the physical memory but do not find the corresponding allocation record in the virtual memory allocation table, or virtual addresses that have been released but are still mapped in the physical memory, which are important bases for judging memory leaks.

[0112] Specifically, start from the physical memory allocation table and traverse the S physical memory allocation records it contains, each record includes at least the associated virtual memory address in the physical memory and the associated time point; for each physical memory allocation record, query the virtual memory allocation table based on the virtual memory address to verify whether the virtual address has been allocated and whether it has been released after allocation. If no record related to the virtual address is found in the virtual memory allocation table, or the found record indicates that the memory has been released, it may mean that there is a memory leak.

[0113] Based on the query results, check whether the virtual address meets the preset detection rules. If the virtual address is not in the virtual memory allocation table, or is in the table but has been marked as released, or has not been released for a long time after allocation (beyond the expected time period), it will be marked as abnormal memory.

[0114] After traversing all physical memory allocation records, all memories marked as abnormal are integrated. The specific call path of each abnormal memory in the program is determined by querying the call stack id recorded in the virtual memory allocation table. Finally, the R most frequently appearing stack identifiers in the comparison results are integrated and obtained. The call paths corresponding to these R identifiers are the code locations that may cause memory leaks.

[0115] The key to the above process is to compare the virtual memory allocation table and the physical memory allocation table through preset detection rules, so as to find possible memory leaks in the Java program. Locating the specific code location through the stack identifier provides a clear direction for repairing the leak without the need for manual line-by-line code checking, which greatly improves efficiency.

[0116] The embodiments of the present invention are particularly suitable for complex big data processing scenarios and other application environments with high requirements for memory management. They can effectively prevent and repair memory leaks and improve system stability and performance.

[0117] Step S204: taking the R call stacks corresponding to the R stack identifiers as suspected leaked memory and generating a memory leak detection result.

[0118] In the memory leak detection method of the present invention, step S204 is a key step to identify the call stack suspected of involving memory leaks based on the comparison results and generate specific memory leak detection results. In the previous step, the virtual memory allocation table and the physical memory allocation table have been compared through the preset detection rules, and the R most frequent stack identifiers related to abnormal memory have been screened out, pointing to the call stack that may cause memory leaks in the Java program. At this stage, these identifiers are further processed to generate more detailed memory leak detection results.

[0119] Specifically, for the R selected stack identifiers, the stack tracing function provided by eBPF is used to convert them into specific call stack information, including the name of the called function, parameters, and the order of calls. Each stack identifier corresponds to a set of function call paths.

[0120] Analyze the call stack information to identify patterns or frequently occurring function call sequences, which are usually related to specific business logic or operation modes. By analyzing the call stack, we can have a deeper understanding of the context in which the memory leak occurred, providing a basis for subsequent repair work.

[0121] Finally, the R call stacks suspected of memory leaks and their analysis results are summarized to generate a memory leak detection result, which not only includes the specific information of the R call stacks, but also the type of memory leak (such as direct memory leak), the size of the leaked memory, the frequency of the leak, and the possible impact of the leak.

[0122] As an example, assume that during analysis it is found that the stack identifier StackID_1234 is related to multiple unreleased direct memory allocations, and through further stack conversion and analysis it is determined that StackID_1234 corresponds to the following call stack:

[0123] main()->setupEnvironment()->createNativeBuffer()->malloc().

[0124] Among them, the malloc() function is used for direct memory allocation, but there is no corresponding free() call to release this part of memory in the subsequent program execution, resulting in a memory leak. This analysis result is an instance of a suspected leaked memory call stack, which can be shown to developers or operation and maintenance personnel as part of the memory leak detection result.

[0125] The key to the above process is that by converting R stack identifiers into specific call stack information, it can provide a clear location reference and context analysis for the memory leak problem of the Java application, making the repair work more efficient and accurate. In addition, the generated detection results not only report the existence of the problem, but also provide a detailed description of the problem, which helps the development team understand the nature of the problem and adopt a more effective solution.

[0126] The embodiments of the present invention are particularly suitable for Java applications in a production environment, and can help timely discover and repair memory leaks without affecting application performance, thereby improving the overall stability and efficiency of the system.

[0127] Through the above steps S201 to S204, the memory events of the target process can be monitored during the execution of the target process to obtain monitoring results, wherein the memory events are used to indicate changes in virtual memory and physical memory, and then a virtual memory allocation table and a physical memory allocation table are established based on the monitoring results. Then, based on the preset detection rules, the virtual memory allocation table and the physical memory allocation table are compared to obtain comparison results, wherein the comparison results are used to record R stack identifiers, where R is a preset value, and finally the R call stacks corresponding to the R stack identifiers are used as suspected leaked memory to generate a memory leak detection result.

[0128] In the embodiment of the present invention, a dynamic monitoring method is adopted, and by tracking the virtual memory and physical memory change events during the execution of the target process, the purpose of real-time recording and analyzing the memory allocation and release is achieved, thereby achieving the technical effect of accurately locating the suspected memory leak call stack. Specifically, by real-time tracking and comparing memory events, the suspected leaked memory block is quickly located, and further traced back to the corresponding code path, so that the root cause of the problem can be quickly focused on, effectively shortening the time for problem location and repair, thereby improving the efficiency of software maintenance and development. At the same time, since the present invention directly monitors at the memory allocator and system levels, it can cover the memory area that the JVM cannot directly manage, for comprehensive monitoring of the memory usage of the Java program, ensuring its stability under large-scale data processing and long-term operation. Compared with the prior art, through the present invention, developers can implement memory leak detection without restarting or modifying the program when the Java program is running, which not only avoids the complexity and performance loss of opening traditional tools, but also can monitor the allocation and release of direct memory in real time, which has a significant effect on improving the robustness and maintenance efficiency of Java applications, thereby solving the technical problem in the related art that the memory leak cannot be effectively detected when the Java program is running due to insufficient monitoring and analysis capabilities of Java memory objects.

[0129] The present invention is described below in conjunction with another optional embodiment.

[0130] Embodiment 2

[0131] An embodiment of the present invention further provides a memory leak detection device. It should be noted that the memory leak detection device of the embodiment of the present invention includes multiple implementation units, which can be used to execute the memory leak detection method provided in the above-mentioned embodiment one, and each implementation unit corresponds to each implementation step in the above-mentioned embodiment one.

[0132] Figure 3 is a schematic diagram of an optional memory leak detection device according to an embodiment of the present invention, such as Figure 3As shown, the device may include: a monitoring unit 31 , an establishing unit 32 , a comparing unit 33 , and a generating unit 34 .

[0133] The monitoring unit 31 is used to monitor the memory events of the target process during the execution of the target process to obtain monitoring results, wherein the memory events are used to indicate changes in virtual memory and physical memory.

[0134] The establishing unit 32 is used to establish a virtual memory allocation table and a physical memory allocation table based on the monitoring result.

[0135] The comparison unit 33 is used to compare the virtual memory allocation table and the physical memory allocation table based on a preset detection rule to obtain a comparison result, wherein the comparison result is used to record R stack identifiers, where R is a preset value.

[0136] The generating unit 34 is configured to use the R call stacks corresponding to the R stack identifiers as suspected leaked memory to generate a memory leak detection result.

[0137] The above-mentioned memory leak detection device can first monitor the memory events of the target process during the execution of the target process through the monitoring unit 31 to obtain the monitoring results, wherein the memory events are used to indicate the changes in the virtual memory and the physical memory, and then establish the virtual memory allocation table and the physical memory allocation table based on the monitoring results through the establishment unit 32, and then compare the virtual memory allocation table and the physical memory allocation table based on the preset detection rules through the comparison unit 33 to obtain the comparison result, wherein the comparison result is used to record R stack identifiers, R is a preset value, and finally, the R call stacks corresponding to the R stack identifiers are used as suspected leaked memory through the generation unit 34 to generate the memory leak detection result.

[0138] In the embodiment of the present invention, a dynamic monitoring method is adopted, and by tracking the virtual memory and physical memory change events during the execution of the target process, the purpose of real-time recording and analyzing the memory allocation and release is achieved, thereby achieving the technical effect of accurately locating the suspected memory leak call stack. Specifically, by real-time tracking and comparing memory events, the suspected leaked memory block is quickly located, and further traced back to the corresponding code path, so that the root cause of the problem can be quickly focused on, effectively shortening the time for problem location and repair, thereby improving the efficiency of software maintenance and development. At the same time, since the present invention directly monitors at the memory allocator and system levels, it can cover the memory area that the JVM cannot directly manage, for comprehensive monitoring of the memory usage of the Java program, ensuring its stability under large-scale data processing and long-term operation. Compared with the prior art, through the present invention, developers can implement memory leak detection when the Java program is running without restarting or modifying the program, which not only avoids the complexity and performance loss of opening traditional tools, but also can monitor the allocation and release of direct memory in real time, which has a significant effect on improving the robustness and maintenance efficiency of Java applications, thereby solving the technical problem in the related art that the memory leak cannot be effectively detected when the Java program is running due to insufficient monitoring and analysis capabilities of Java memory objects.

[0139] Optionally, the monitoring unit includes: a first determination module, used to determine the target kernel probe based on the event type of the memory event, wherein the event types include: virtual memory allocation events, virtual memory release events, and system page fault events; a positioning module, used to locate the execution program of the target process and insert the target kernel probe into a specified position of the execution program; a receiving module, used to receive the detection result of the target kernel probe during the execution of the execution program, wherein the detection result is used to record the calling information of the calling function corresponding to the event type; a first generating module, used to generate the monitoring result based on the calling information indicated by the detection result.

[0140] Optionally, the receiving module includes: a first determination submodule, used to determine the memory request function called by the execution program when the event type is a virtual memory allocation event, wherein the target kernel probe is inserted in the memory request function; a first acquisition submodule, used to obtain the first type of input parameters and the first type of return value of the memory request function through the target kernel probe, wherein the first type of input parameters are used to indicate the first virtual memory range applied for allocation by the target process; a first parsing submodule, used to parse the first type of return value when the first type of return value indicates that the memory allocation is successful, and obtain the first virtual memory address allocated to the target process; a first generation submodule, used to generate a detection result based on the first virtual memory range and the first virtual memory address.

[0141] Optionally, the receiving module also includes: a second determination submodule, used to determine the memory release function called by the execution program when the event type is a virtual memory release event, wherein the target kernel probe is inserted in the memory release function; a second acquisition submodule, used to obtain the second type of input parameters and the second type of return value of the memory release function through the target kernel probe, wherein the second type of input parameters are used to indicate the second virtual memory range applied for release by the target process; a second parsing submodule, used to parse the return value when the second type of return value indicates that the memory release is successful, and obtain the second virtual memory address of the successful release; a second generation submodule, used to generate a detection result based on the second virtual memory range and the second virtual memory address.

[0142] Optionally, the receiving module also includes: a third determination sub-module, used to determine the page fault handling function called by the execution program when the event type is a system page fault interrupt event, wherein the target kernel probe is inserted in the page fault handling function; a third acquisition sub-module, used to obtain the third type of input parameters and the third type of return value of the page fault handling function through the target kernel probe, wherein the third type of input parameters are used to indicate the third virtual memory address accessed by the target process; a third generation sub-module, used to generate a detection result based on the third virtual memory address when the third type of return value indicates that the memory access is successful.

[0143] Optionally, the establishment unit includes: a second generation module, which is used to generate a virtual memory allocation table with the process ID of the target process, the first virtual memory address, the allocated virtual memory capacity and the first time point as table fields when the event type is a virtual memory allocation event, wherein the first time point refers to the time point when the virtual memory is allocated to the target process; a deletion module, which is used to search the virtual memory allocation table based on the second virtual memory address when the event type is a virtual memory release event, and delete the found table entries to obtain an updated virtual memory allocation table; a third generation module, which is used to generate a physical memory allocation table with the third virtual memory address and the second time point as table fields when the event type is a system page fault interrupt event, wherein the second time point refers to the time point when the physical memory is associated with the target process.

[0144] Optionally, the comparison unit includes: a traversal module, which is used to traverse a physical memory allocation table, wherein the physical memory allocation table contains S physical memory allocation records, and each physical memory allocation record includes at least the following content: an associated virtual memory address and an associated time point in the physical memory, where S is an integer greater than R; a query module, which is used to query the virtual memory allocation table based on the virtual memory address for each physical memory allocation record to obtain a query result; a second determination module, which is used to determine, based on a preset detection rule, that the virtual memory allocation table does not contain a memory application record for the virtual memory address, or contains a memory release record corresponding to the virtual memory address, or the memory has not been released for an expected time period, that the virtual memory address is an abnormal memory when the query result indicates that the virtual memory allocation table does not contain a memory application record for the virtual memory address, or contains a memory release record corresponding to the virtual memory address, or the memory has not been released for an expected time period; an integration module, which is used to integrate all abnormal memories after the traversal is completed, and determine the stack identifiers corresponding to the abnormal memories in the physical memory one by one, to obtain R stack identifiers in the comparison result.

[0145] It should be noted that the monitoring unit 31, the establishing unit 32, the comparing unit 33, and the generating unit 34 correspond to steps S201 to S204 in the first embodiment, and the examples and application scenarios implemented by the above units and the corresponding steps are the same, but are not limited to the contents disclosed in the first embodiment. It should be noted that the above modules or units can be hardware components or software components stored in a memory (e.g., the memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n), and the above modules or units can also be part of the device and can be run in the computer terminal 10 provided in the first embodiment.

[0146] The present invention is described below in conjunction with another optional embodiment.

[0147] Embodiment 3

[0148] An embodiment of the present invention may also provide an electronic device, Figure 4 is a structural block diagram of an electronic device for executing a memory leak detection method according to an embodiment of the present invention, such as Figure 4 As shown, the electronic device may include: one or more ( Figure 4 (only one is shown) processor 402, memory 404, storage controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0149] Among them, the memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the memory leakage detection method and device in the embodiment of the present application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, realizing the above-mentioned memory leakage detection method. The memory may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include a memory remotely arranged relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0150] The processor can call the information and application programs stored in the memory through the transmission device to perform the following steps: during the execution of the target process, monitor the memory events of the target process to obtain monitoring results, wherein the memory events are used to indicate changes in virtual memory and physical memory; establish a virtual memory allocation table and a physical memory allocation table based on the monitoring results; based on preset detection rules, compare the virtual memory allocation table and the physical memory allocation table to obtain a comparison result, wherein the comparison result is used to record R stack identifiers, where R is a preset value; use the R call stacks corresponding to the R stack identifiers as suspected leaked memory to generate a memory leak detection result.

[0151] The processor can also call the information and application programs stored in the memory through the transmission device to perform the following steps: determine the target kernel probe based on the event type of the memory event, wherein the event types include: virtual memory allocation events, virtual memory release events, and system page fault events; locate the execution program of the target process, and insert the target kernel probe into the specified position of the execution program; during the execution of the execution program, receive the detection result of the target kernel probe, wherein the detection result is used to record the call information of the calling function corresponding to the event type; generate monitoring results based on the call information indicated by the detection result.

[0152] The processor can also call the information and application stored in the memory through the transmission device to perform the following steps: when the event type is a virtual memory allocation event, determine the memory request function called by the execution program, wherein the target kernel probe is inserted in the memory request function; obtain the first type of input parameters and the first type of return value of the memory request function through the target kernel probe, wherein the first type of input parameters are used to indicate the first virtual memory range requested for allocation by the target process; when the first type of return value indicates that the memory allocation is successful, parse the first type of return value to obtain the first virtual memory address allocated to the target process; and generate a detection result based on the first virtual memory range and the first virtual memory address.

[0153] The processor can also call the information and application stored in the memory through the transmission device to perform the following steps: when the event type is a virtual memory release event, determine the memory release function called by the execution program, wherein the target kernel probe is inserted in the memory release function; obtain the second type of input parameters and the second type of return value of the memory release function through the target kernel probe, wherein the second type of input parameters are used to indicate the second virtual memory range requested for release by the target process; when the second type of return value indicates that the memory release is successful, parse the return value to obtain the second virtual memory address that was successfully released; and generate a detection result based on the second virtual memory range and the second virtual memory address.

[0154] The processor can also call the information and application stored in the memory through the transmission device to perform the following steps: when the event type is a system page fault interrupt event, determine the page fault handling function called by the execution program, wherein the target kernel probe is inserted in the page fault handling function; obtain the third type of input parameters and the third type of return value of the page fault handling function through the target kernel probe, wherein the third type of input parameters are used to indicate the third virtual memory address accessed by the target process; when the third type of return value indicates that the memory access is successful, generate a detection result based on the third virtual memory address.

[0155] The processor can also call the information and application stored in the memory through the transmission device to perform the following steps: when the event type is a virtual memory allocation event, a virtual memory allocation table is generated with the process ID of the target process, the first virtual memory address, the allocated virtual memory capacity and the first time point as table fields, wherein the first time point refers to the time point when the virtual memory is allocated to the target process; when the event type is a virtual memory release event, the virtual memory allocation table is searched based on the second virtual memory address, and the found table entry is deleted to obtain an updated virtual memory allocation table; when the event type is a system page fault interrupt event, a physical memory allocation table is generated with the third virtual memory address and the second time point as table fields, wherein the second time point refers to the time point when the physical memory is associated with the target process.

[0156] The processor can also call the information and application stored in the memory through the transmission device to perform the following steps: traverse the physical memory allocation table, wherein the physical memory allocation table contains S physical memory allocation records, and each physical memory allocation record includes at least the following content: the virtual memory address associated with the physical memory and the associated time point, S is an integer greater than R; for each physical memory allocation record, query the virtual memory allocation table based on the virtual memory address to obtain a query result; based on a preset detection rule, when the query result indicates that the virtual memory allocation table does not contain a memory application record of the virtual memory address, or contains a memory release record corresponding to the virtual memory address, or the memory is not released for an expected time period, determine that the virtual memory address is abnormal memory; after the traversal is completed, integrate all abnormal memories, and determine the stack identifiers corresponding to the abnormal memories in the physical memory one by one, and obtain R stack identifiers in the comparison result.

[0157] An embodiment of the present invention provides a memory leak detection solution. The invention adopts a dynamic monitoring method, and achieves the purpose of real-time recording and analyzing memory allocation and release by tracking virtual memory and physical memory change events during the execution of the target process, thereby achieving the technical effect of accurately locating the suspected memory leak call stack. Specifically, by real-time tracking and comparing memory events, the suspected leaked memory block is quickly located, and further traced back to the corresponding code path, so that the root cause of the problem can be quickly focused on, effectively shortening the time for problem location and repair, thereby improving the efficiency of software maintenance and development. At the same time, since the present invention directly monitors at the memory allocator and system levels, it can cover the memory area that the JVM cannot directly manage, and comprehensively monitors the memory usage of the Java program to ensure its stability under large-scale data processing and long-term operation. Compared with the prior art, the present invention allows developers to implement memory leak detection when the Java program is running without restarting or modifying the program, which not only avoids the complexity and performance loss of opening traditional tools, but also can monitor the allocation and release of direct memory in real time, which has a significant effect on improving the robustness and maintenance efficiency of Java applications, thereby solving the technical problem in the related art that the memory leak cannot be effectively detected when the Java program is running due to insufficient monitoring and analysis capabilities of Java memory objects.

[0158] It can be understood by those skilled in the art that Figure 4 The structure shown is for illustration only, and the electronic device may also be a smart phone, a tablet computer, a PDA, a mobile Internet device (MID), a PAD or other terminal device. Figure 4 The structure of the electronic device is not limited. Figure 4More or fewer components (such as network interfaces, display devices, etc.) shown in, or having Figure 4 Different configurations shown.

[0159] A person of ordinary skill in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing the hardware related to the terminal device through a program, and the program can be stored in a computer-readable storage medium, and the storage medium may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0160] The present invention is described below in conjunction with another optional embodiment.

[0161] Embodiment 4

[0162] The embodiment of the present invention further provides a computer-readable storage medium. Optionally, in the embodiment of the present invention, the computer-readable storage medium can be used to store the program code executed by the memory leak detection method provided in the first embodiment.

[0163] Optionally, in an embodiment of the present invention, the above-mentioned storage medium may be located in any computer terminal in a computer terminal group in a computer network, or in any mobile terminal in a mobile terminal group.

[0164] An embodiment of the present invention also provides a computer program product, which, when executed on a data processing device, is suitable for executing the steps of a memory leak detection method: during the execution of a target process, the memory events of the target process are monitored to obtain monitoring results, wherein the memory events are used to indicate changes in virtual memory and physical memory; a virtual memory allocation table and a physical memory allocation table are established based on the monitoring results; based on preset detection rules, the virtual memory allocation table and the physical memory allocation table are compared to obtain comparison results, wherein the comparison results are used to record R stack identifiers, where R is a preset value; and the R call stacks corresponding to the R stack identifiers are used as suspected leaked memory to generate a memory leak detection result.

[0165] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0166] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0167] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0168] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0169] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0170] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, disk or optical disk and other media that can store program codes.

[0171] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for detecting memory leaks, characterized in that: include: During the execution of the target process, the memory events of the target process are monitored to obtain monitoring results, wherein the memory events are used to indicate changes in virtual memory and physical memory; Establishing a virtual memory allocation table and a physical memory allocation table based on the monitoring result; Based on a preset detection rule, the virtual memory allocation table and the physical memory allocation table are compared to obtain a comparison result, wherein the comparison result is used to record R stack identifiers, where R is a preset value; The R call stacks corresponding to the R stack identifiers are used as suspected leaked memory to generate a memory leak detection result.

2. The detection method according to claim 1, characterized in that: The step of monitoring the memory events of the target process to obtain monitoring results includes: Determining a target kernel probe based on an event type of the memory event, wherein the event type includes: a virtual memory allocation event, a virtual memory release event, and a system page fault event; Locating the execution program of the target process and inserting the target kernel probe into a specified position of the execution program; During the execution of the execution program, receiving a detection result of the target kernel probe, wherein the detection result is used to record call information of a call function corresponding to the event type; The monitoring result is generated based on the calling information indicated by the detection result.

3. The detection method according to claim 2, characterized in that: The step of receiving the detection result of the target kernel probe comprises: In the case where the event type is a virtual memory allocation event, determining a memory request function called by the execution program, wherein the target kernel probe is inserted into the memory request function; Acquire a first type of input parameter and a first type of return value of the memory application function through the target kernel probe, wherein the first type of input parameter is used to indicate a first virtual memory range applied for allocation by the target process; When the first type of return value indicates that the memory allocation is successful, parsing the first type of return value to obtain a first virtual memory address allocated to the target process; The detection result is generated based on the first virtual memory range and the first virtual memory address.

4. The detection method according to claim 2, characterized in that: The step of receiving the detection result of the target kernel probe also includes: In the case where the event type is a virtual memory release event, determining a memory release function called by the execution program, wherein the target kernel probe is inserted into the memory release function; Acquire, by the target kernel probe, a second type of input parameter and a second type of return value of the memory release function, wherein the second type of input parameter is used to indicate a second virtual memory range requested to be released by the target process; When the second type of return value indicates that the memory is released successfully, parsing the return value to obtain a second virtual memory address that is released successfully; The detection result is generated based on the second virtual memory range and the second virtual memory address.

5. The detection method according to claim 2, characterized in that: The step of receiving the detection result of the target kernel probe also includes: In the case where the event type is a system page fault interrupt event, determining a page fault processing function called by the execution program, wherein the target kernel probe is inserted into the page fault processing function; Acquire a third type of input parameter and a third type of return value of the page fault processing function through the target kernel probe, wherein the third type of input parameter is used to indicate a third virtual memory address accessed by the target process; When the third type of return value indicates that the memory access is successful, the detection result is generated based on the third virtual memory address.

6. The detection method according to claim 1, characterized in that: The steps of establishing a virtual memory allocation table and a physical memory allocation table based on the monitoring result include: In the case where the event type is a virtual memory allocation event, the virtual memory allocation table is generated with the process ID of the target process, the first virtual memory address, the allocated virtual memory capacity and the first time point as table fields, wherein the first time point refers to the time point when the virtual memory is allocated to the target process; In the case where the event type is a virtual memory release event, searching the virtual memory allocation table based on the second virtual memory address, and deleting the found table entry to obtain an updated virtual memory allocation table; When the event type is a system page fault interrupt event, the physical memory allocation table is generated with the third virtual memory address and the second time point as table fields, wherein the second time point refers to the time point at which the physical memory is associated with the target process.

7. The detection method according to claim 1, characterized in that: The step of comparing the virtual memory allocation table and the physical memory allocation table based on a preset detection rule to obtain a comparison result includes: Traversing the physical memory allocation table, wherein the physical memory allocation table includes S physical memory allocation records, each of which includes at least the following contents: an associated virtual memory address in the physical memory and an associated time point, where S is an integer greater than R; For each physical memory allocation record, query the virtual memory allocation table based on the virtual memory address to obtain a query result; Based on the preset detection rule, when the query result indicates that the virtual memory allocation table does not contain a memory application record of the virtual memory address, or contains a memory release record corresponding to the virtual memory address, or the memory is not released for more than an expected time period, the virtual memory address is determined to be abnormal memory; After the traversal is completed, all the abnormal memories are integrated, and the stack identifiers corresponding to the abnormal memories in the physical memory are determined one by one to obtain R stack identifiers in the comparison result.

8. A memory leak detection device, characterized in that: include: A monitoring unit, used to monitor memory events of a target process during its execution to obtain monitoring results, wherein the memory events are used to indicate changes in virtual memory and physical memory; An establishing unit, used for establishing a virtual memory allocation table and a physical memory allocation table based on the monitoring result; A comparison unit, configured to compare the virtual memory allocation table and the physical memory allocation table based on a preset detection rule to obtain a comparison result, wherein the comparison result is used to record R stack identifiers, where R is a preset value; The generating unit is used to use the R call stacks corresponding to the R stack identifiers as suspected leaked memory to generate a memory leak detection result.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored computer program, wherein when the computer program is executed, the device where the computer-readable storage medium is located is controlled to execute the memory leak detection method according to any one of claims 1 to 7.

10. An electronic device, characterized in that: It includes one or more processors and a memory, wherein the memory is used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the memory leak detection method described in any one of claims 1 to 7.

Images