CN114003488A - Memory leak detection method and equipment - Google Patents
Memory leak detection method and equipment Download PDFInfo
- Publication number
- CN114003488A CN114003488A CN202111144069.8A CN202111144069A CN114003488A CN 114003488 A CN114003488 A CN 114003488A CN 202111144069 A CN202111144069 A CN 202111144069A CN 114003488 A CN114003488 A CN 114003488A
- Authority
- CN
- China
- Prior art keywords
- objects
- memory leak
- preset
- identifiers
- preset set
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3636—Software debugging by tracing the execution of the program
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45591—Monitoring or debugging support
Abstract
The embodiment of the invention relates to the field of computers, and discloses a memory leak detection method and device, wherein the method comprises the following steps: when a Java application program runs on a virtual machine, calling a Java virtual machine tool interface JVMTI to monitor whether an object is recovered; wherein the object is associated with an identifier; deleting the identifier associated with the object in a preset set under the condition that the object is monitored to be recycled; wherein the preset set comprises identifiers associated with the plurality of objects; and determining that the objects associated with one or more identifiers in the remaining identifiers in the preset set are memory leak objects. By implementing the embodiment of the invention, the efficiency of memory leak detection can be improved.
Description
The application is a divisional application of an application with the application date of 31/3/2017, the application number of 201710211056.5 and the invention name of 'a memory leak detection method and equipment' submitted to the intellectual property office of China.
Technical Field
The invention relates to the field of computers, in particular to a memory leak detection method and device.
Background
In the field of computers, a memory leak refers to the inability to reclaim memory that has been no longer used by a program due to an error or negligence. As applications run, less and less memory is available in the system, causing the system to crash because there is insufficient memory.
Currently, the means to detect memory leaks is a memory analysis tool. The memory analysis tool firstly artificially judges the number of object instances or the occupied size of object memory by a file exported during the running of an application program to find a class with high-risk memory leakage; then, exporting a file at another time to perform the same analysis, comparing the analysis results of the two times, and if the number of instances of a certain class is obviously increased and the general trend is increased along with the running of the application program, the class can be a key concern object of memory leakage; and finally, artificially participating to perform deeper analysis to determine the objects with memory leaks.
However, in practice, it is found that the whole memory leak detection process needs human intervention, and people familiar with the memory leak scene need to detect, so that the efficiency of memory leak detection is low.
Disclosure of Invention
The embodiment of the invention discloses a memory leak detection method and device, which can improve the efficiency of memory leak detection.
In a first aspect, an embodiment of the present invention provides a memory leak detection method, where the method includes:
when an application program runs on a virtual machine, calling a Java virtual machine tool interface JVMTI to monitor whether an object is recovered; wherein the object is associated with an identifier;
deleting the identifier associated with the object in a preset set under the condition that the object is monitored to be recycled; wherein the preset set comprises identifiers associated with the plurality of objects;
the remaining identifiers in the preset set may be used to determine the memory leak object. Specifically, the memory leak detection device determines that an object associated with one or more identifiers of the remaining identifiers in the preset set is a memory leak object.
In this embodiment of the present invention, the memory leak detection device, by using the JVMTI, may monitor the capability of whether an object in an application is recovered, detect an object that is not recovered in the application, that is, an object associated with the remaining identifier, and determine the memory leak object according to the object that is not recovered. Therefore, compared with the prior art that the memory leakage object is found by artificially judging the number of the object instances or the occupied size of the object memory, the scheme reduces the consumption of human resources and improves the efficiency of memory leakage detection.
In one possible design, the location information of the object is obtained by tracking creation events of the object through a code injection technique.
The obtained location information of the object may be used to determine the location of the memory leak object. Specifically, the memory leak detection device determines the location of the memory leak object according to the location information.
By the technical scheme provided by the embodiment of the invention, the memory leak detection equipment can determine the memory leak object and position the memory leak object at the same time, so that the position of the memory leak object is prevented from being manually searched, and the efficiency of memory leak detection is improved.
In one possible design, creating an allocation list of threads in which the object is located through a Thread-local mechanism of the JVMTI; calling an information transfer interface function to transfer the identifier and the position information of the object to the distribution list;
wherein the threads are each associated with an allocation list; the distribution list comprises identifiers and position information which are respectively associated with a plurality of objects; the identifier and the position information of the same object in the distribution list have an association relation;
the determining the location of the memory leak object according to the location information includes:
and determining the position of the memory leak object according to the position information in the distribution list.
Through the technical scheme provided by the implementation of the invention, the identifier and the position information are stored through the allocation list created by the thread-local mechanism of the JVM, so that the problem of multithreading concurrency is avoided.
In one possible design, the determining the location of the memory leak object according to the location information in the allocation list includes: calling a daemon thread that has been created in the JVMTI derives the identifier and location information in the allocation list.
Wherein the derived identifier and the location information may be used to determine the location of the memory leak object. Specifically, the memory leak detection device may determine the location of the memory leak object according to the derived identifier and the location information.
According to the technical scheme provided by the embodiment of the invention, the memory leakage detection equipment can also derive the position information through the created daemon thread at random, so that the phenomenon that the utilization rate of the memory is too high because the position information exists in the memory is avoided.
In one possible design, a start instruction is obtained that includes a specified directory; the starting instruction is used for starting a file detection thread, the starting file detection thread is used for detecting whether a starting file or an ending file exists in the specified directory, the starting file is used for triggering the recovery condition of the starting monitoring object, and the ending file is used for triggering the recovery condition of the ending monitoring object;
when detecting that the starting file exists in the specified directory, triggering and executing the step of calling the JVMTI to monitor whether the object is recovered;
when the ending file is detected to exist in the specified directory, ending monitoring of the object recovery condition, and triggering and executing the step of determining that the object associated with one or more identifiers in the remaining identifiers in the preset set is a memory leak object.
Through the technical scheme provided by the embodiment of the invention, the JVMTI can only monitor the objects created after the start file is detected, so that all objects in an application program are prevented from being monitored, the magnitude of the monitored objects is small, and the memory leakage detection efficiency is high; in addition, in the running process of the application program, the memory leak detection device can also start a file detection thread at an indefinite time so as to start the recovery condition of the monitored object at any time point of the running of the application program, thereby realizing the flexible setting of the monitoring range.
In one possible design, calling a daemon thread that has been created in the JVMTI derives the remaining identifiers in the preset set; and determining the memory leak object according to the derived identifier.
According to the technical scheme provided by the embodiment of the invention, the memory leak detection equipment creates a daemon thread through the JVM TI to specially derive the residual identifiers, so that the influence on the running efficiency of the application program caused by the fact that the derivation operation is executed through a service thread in the application program is avoided.
In one possible design, the memory leak object is determined according to the remaining identifiers in the preset set and a preset exclusion object.
Through the scheme provided by the embodiment of the invention, the memory leak detection equipment can also preset exclusion objects, such as static objects or global objects which have the same life cycle as the application program and are normally quoted, when the memory leak objects are determined, the exclusion objects are excluded, so that the exclusion objects set by the static objects or the global objects and the like are prevented from being defined as the memory leak objects by mistake, and the accuracy of detecting the memory leak objects is improved.
In one possible design, after determining the location of the memory leak object according to the derived identifier and the location information, the method further includes:
under the condition that the position information of the memory leakage object is repeated, removing the repeated position information in the position information of the memory leakage object
According to the technical scheme provided by the embodiment of the invention, under the condition that the derived position information is repeated, the memory leak detection equipment can make the position information of the memory leak object intuitively, simply and clearly by carrying out duplication elimination operation on the position information of the memory leak object.
In a second aspect, an embodiment of the present invention provides a memory leak detection apparatus, where the apparatus includes:
the monitoring unit is used for calling a Java virtual machine tool interface JVMTI to monitor whether an object is recycled when an application program runs on a virtual machine; wherein the object is associated with an identifier;
the identifier deleting unit is used for deleting the identifier associated with the object in a preset set under the condition that the monitoring unit monitors that the object is recovered; wherein the preset set comprises identifiers associated with the plurality of objects;
and the object determining unit is used for determining that the objects associated with one or more identifiers in the remaining identifiers in the preset set are memory leak objects.
In the embodiment of the present invention, the memory leak detection device monitors objects that are not recovered in the application program, that is, objects associated with the remaining identifiers, and determines the memory leak object according to the objects that are not recovered. Therefore, compared with the prior art that the memory leak object is found by manually judging the number of the object instances or the occupied size of the object memory, the scheme provided by the embodiment of the invention reduces the consumption of human resources and improves the efficiency of memory leak detection.
In one possible design, the apparatus further includes:
a position determination unit for tracking a creation event of the object by a code injection technique to acquire position information of the object; and determining the position of the memory leakage object according to the position information.
By the technical scheme provided by the embodiment of the invention, the memory leak detection equipment can determine the memory leak object and simultaneously position the memory leak object, thereby avoiding manually searching the position of the memory leak object and improving the efficiency of memory leak detection.
In a possible design, the location determining unit is specifically configured to create an allocation list of threads where the object is located through a Thread-local mechanism of the JVMTI; calling an information transfer interface function to transfer the identifier and the position information of the object to the distribution list;
wherein the threads are each associated with an allocation list; the distribution list comprises identifiers and position information which are respectively associated with a plurality of objects; the identifier and the position information of the same object in the distribution list have an association relation;
and determining the position of the memory leak object according to the position information in the distribution list.
Through the technical scheme provided by the implementation of the invention, the identifier and the position information are stored through the allocation list created by the thread-local mechanism of the JVM, so that the problem of multithreading concurrency is avoided.
In one possible design, the location determining unit is specifically configured to invoke a daemon thread that has been created in the JVMTI to export identifiers and location information in the allocation list; and determining the position of the memory leak object according to the derived identifier and the position information.
According to the technical scheme provided by the embodiment of the invention, the memory leakage detection equipment can also derive the position information through the created daemon thread at random, so that the phenomenon that the utilization rate of the memory is too high because the position information exists in the memory is avoided.
In one possible design, the apparatus further includes:
an acquisition unit configured to acquire a start instruction including a specified directory; the starting instruction is used for starting a file detection thread, the file detection thread is used for detecting whether a starting file or an ending file exists in the specified directory, the starting file is used for triggering the recovery condition of starting the monitoring object, and the ending file is used for triggering the recovery condition of ending the monitoring object;
when detecting that the starting file exists in the specified directory, triggering and executing the step of calling the JVMTI to monitor whether the object is recovered;
when the ending file is detected to exist in the specified directory, ending monitoring of the object recovery condition, and triggering and executing the step of determining that the object associated with one or more identifiers in the remaining identifiers in the preset set is a memory leak object.
Through the technical scheme provided by the embodiment of the invention, the JVMTI can only monitor the objects created after the start file is detected, so that all objects in an application program are prevented from being monitored, the magnitude of the monitored objects is small, and the memory leakage detection efficiency is high; in addition, in the running process of the application program, the memory leak detection device can also start a file detection thread at an indefinite time so as to start the recovery condition of the monitored object at any time point of the running of the application program, thereby realizing the flexible setting of the monitoring range.
In a possible design, the object determining unit is specifically configured to invoke a daemon thread that has been created in the JVMTI to export remaining identifiers in the preset set; and determining the memory leak object according to the derived identifier.
According to the technical scheme provided by the embodiment of the invention, the memory leak detection equipment creates a daemon thread through the JVM TI to specially derive the residual identifiers, so that the influence on the running efficiency of the application program caused by the fact that the derivation operation is executed through a service thread in the application program is avoided.
In a possible design, the object determining unit is specifically configured to determine the memory leak object according to the remaining identifiers in the preset set and a preset excluded object.
Compared with the prior art, the embodiment of the invention has the following beneficial effects:
in this embodiment of the present invention, the memory leak detection device, by using the JVMTI, may monitor the capability of whether an object in an application is recovered, detect an object that is not recovered in the application, that is, an object associated with the remaining identifier, and determine the memory leak object according to the object that is not recovered. Therefore, compared with the prior art that the memory leakage object is found by artificially judging the number of the object instances or the occupied size of the object memory, the scheme reduces the consumption of human resources and improves the efficiency of memory leakage detection.
Drawings
In order to more clearly illustrate the technical solution in the embodiments of the present invention, the drawings required to be used in the embodiments will be briefly described below.
FIG. 1 is a diagram of an architecture model of a JVM TI according to an embodiment of the present invention;
fig. 2 is a schematic flow chart illustrating a method for detecting memory leak according to an embodiment of the present invention;
fig. 3 is a schematic structural diagram of a memory leak detection device according to an embodiment of the present invention;
fig. 4 is a schematic structural diagram of another memory leak detection apparatus disclosed in the embodiment of the present invention;
fig. 5 is a schematic structural diagram of another memory leak detection apparatus disclosed in the embodiment of the present invention;
fig. 6 is a schematic structural diagram of another memory leak detection device disclosed in the embodiment of the present invention.
Detailed Description
Embodiments of the present invention will be described below with reference to the accompanying drawings.
Referring to fig. 1, fig. 1 is a schematic diagram of an architecture model of a Java Virtual Machine Tool Interface (JVMTI), according to an embodiment of the present invention. The JVMTI is a C-based Application Programming Interface (API), through which functions of the JVMTI can monitor applications and the like, and an architecture model thereof may be as shown in fig. 1. The JVMTI may subscribe to an event of interest, such as object recycling, thread ending, etc., to a running application, and when the subscribed event occurs, the JVMTI may be activated in a manner of a callback function and processed through a function provided by the JVMTI. It should be noted that the embodiment of the present invention includes but is not limited to Java language, for example, other programming languages for automatic memory management may also be included.
Referring to fig. 2, fig. 2 is a schematic flow chart illustrating a memory leak detection method according to an embodiment of the present invention. As shown in fig. 2, the memory leak detection method may include the following steps.
Step S201: when an application program runs on a virtual machine, calling a Java virtual machine tool interface JVMTI to monitor whether an object is recovered; wherein the object is associated with an identifier.
The memory leak detection equipment can call an object processing function to allocate an identifier for the object of the application program, and then transfer the identifier to the JVMTI through an information transfer interface function; or, the memory leak detection device may also directly call a function in the JVMTI to allocate an identifier to the object, and the like. In the JVMTI, the memory leak detection device may call a setTag () function in the JVMTI to associate the identifier with the object, and after the identifier is associated with the object, the associated object may be identified by the identifier. Wherein the identifier can be represented by letters, numbers, symbols or the like, such as tag _01, tag _02, tag _03 and the like; in addition, in order to avoid the multithreading concurrency problem, the identifier can also have an atomic operation characteristic; the information transfer Interface function may include a cross-platform Interface function such as a Java Native Interface (JNI) function.
For example, if the function in the JVMTI allocates the identifiers tag _01 to tag _05 to the objects object _01 to object _05, respectively, that is, the object _01 is allocated with the identifier tag _01, the object _02 is allocated with the identifier tag _02, the object _03 is allocated with the identifier tag _03, the object _04 is allocated with the identifier tag _04, and the object _05 is allocated with the identifier tag _ 05; and the function prototype of the setTag () is jvmtiError setTag (jpointing tag), the first parameter is the object object, the second parameter is the identifier tag allocated to the object object, and the object object and the identifier tag can be associated by the jvmtiError setTag (jpointing tag) function. Therefore, the memory leak detection apparatus may call the following functions to associate the objects object _01 to object _05 and the identifiers tag _01 to tag _05 one by one, respectively.
jvmtiError SetTag(jobject object_01，jlong tag_01)；
jvmtiError SetTag(jobject object_02，jlong tag_02)；
jvmtiError SetTag(jobject object_03，jlong tag_03)；
jvmtiError SetTag(jobject object_04，jlong tag_04)；
jvmtiError SetTag(jobject object_05，jlong tag_05)；
After the objects object _01 to object _05 are associated with the identifiers tag _01 to tag _05, the associated object _01 can be identified by tag _01, the associated object _02 can be identified by tag _02, the associated object _03 can be identified by tag _03, the associated object _04 can be identified by tag _04, and the associated object _05 can be identified by tag _05 in the objects object _01 to object _ 05.
In this embodiment of the present invention, the memory leak detection device may further call a function in the JVMTI to establish a preset set, so as to store the object associated with the identifier.
For example, the JVMTI establishes a preset set as shown in table 1, for storing the identifiers tag _01 to tag _ 05.
TABLE 1 Preset set
| tag_01 |
| tag_02 |
| tag_03 |
| tag_04 |
| tag_05 |
In the embodiment of the present invention, the memory leak detection device may call a callback function in the JVMTI to detect whether an object is recovered. Further, the callback function may be ObjectFree (), a function prototype of the ObjectFree () is void JNICALL ObjectFree (jvmtiEnv jvmti _ env, jlong tag), and the second argument is an identifier associated with the object to be reclaimed, that is, when the callback function is void JNICALL ObjectFree (jvmtiEnv jvmti _ env, j long tag), it indicates that the object associated with the identifier tag is reclaimed.
For example, if the callback function of the JVMTI is void JNICALL ObjectFree (jvmtiEnv JVMTI _ env, jlong tag _01), it indicates that the object _01 associated with the tag _01 is recycled, and if the callback function of the JVMTI is void JNICALL ObjectFree (JVMTI _ env, long tag _02), it indicates that the object _02 associated with the tag _02 is recycled, etc.
Step S202: deleting the identifier associated with the object in a preset set under the condition that the object is monitored to be recycled;
the memory leak detection device may call a function in the JVMTI to delete the identifier associated with the object from a preset set. For example, if the preset set is shown in table 1 and the JVMTI monitors that the object _01 and the object _02 are recycled, as shown in table 2, the memory leak detection apparatus may call a function in the JVMTI to delete the identifiers tag _01 and tag _02 associated with the object _01 and the object _02 from table 1.
TABLE 2 Preset set
| tag_03 |
| tag_04 |
| tag_05 |
Step S203: and determining that the objects associated with one or more identifiers in the remaining identifiers in the preset set are memory leak objects.
The memory leak detection device may call a daemon thread created by the JVMTI to export the remaining identifiers to an analysis program for analysis, so as to determine a memory leak object. Further, the memory leak detection device may also, when the JVMTI detects that garbage collection of the application is finished, call a daemon thread created by the JVMTI to export the remaining identifiers to an analysis program for analysis, so as to determine a memory leak object. The JVMTI may detect that garbage collection of the application is finished through a callback function, for example, detect that garbage collection of the application is finished through a callback function garbagcollectionnotify () of the JVMTI.
In an optional implementation manner, the memory leak detection device may define the object associated with the remaining identifiers as the memory leak object. For example, if the remaining identifiers are tag _03, tag _04, and tag _05 as shown in table 2, the memory leak detection apparatus may define object _03, object _04, and object _05 associated with tag _03, tag _04, and tag _05 as a memory leak object.
In another alternative embodiment, the memory leak detection device may preset an exclusion object, where the exclusion object may include a static object or a global object that has the same life cycle as the application and is normally referenced, or an object in a cache, or an object in a container, and so on. Further, the memory leak detection device may determine the objects associated with the remaining identifiers, then exclude the excluded objects from the determined objects, and finally use the objects remaining after exclusion as the memory leak objects. For example, if the excluded object is object _03 and the remaining identifiers are tag _03, tag _04, and tag _05, the memory leak detection apparatus may first determine that the objects associated with tag _03, tag _04, and tag _05 are object _03, object _04, and object _05, then exclude object _03 from object _03, object _04, and object _05, and finally define the object _04 and object _05 remaining after exclusion as the memory leak object.
Or, the memory leak detection device may further search for the identifier associated with the excluded object first, then exclude the identifier associated with the excluded object from the remaining identifiers, finally determine the identifiers remaining after the exclusion of the identifier associated with the excluded object is completed, and define the determined object associated with the identifier as the memory leak object. For example, if the tag associated with the excluded object is tag _03 and the remaining tags are tag _03, tag _04 and tag _05, the memory leak detection apparatus may exclude tag _03 from tag _03, tag _04 and tag _05, and then define object _04 and object _05 associated with tag _04 and tag _05 as memory leak objects.
Through the scheme provided by the embodiment of the invention, the memory leak detection equipment can also preset exclusion objects, such as static objects or global objects which have the same life cycle as the application program and are normally quoted, when the memory leak objects are determined, the exclusion objects are excluded, so that the exclusion objects set by the static objects or the global objects and the like are prevented from being defined as the memory leak objects by mistake, and the accuracy of detecting the memory leak objects is improved.
In addition, the memory leak detection device creates a daemon thread through the JVMTI to specially derive the remaining identifiers, thereby avoiding the influence on the operating efficiency of the application program caused by the derivation operation executed through a service thread in the application program.
In this embodiment of the present invention, the memory leak detection device can monitor the capability of whether an object in an application is recovered by using the JVMTI, detect an object that is not recovered in the application, that is, an object associated with the remaining identifier, and determine the memory leak object according to the object that is not recovered. Therefore, compared with the prior art that the memory leak object is found by manually judging the number of the object instances or the occupied size of the object memory, the scheme provided by the embodiment of the invention reduces the consumption of human resources and improves the efficiency of memory leak detection.
In an optional embodiment, the memory leak detection device may set a monitoring range, and detect whether a memory leak object exists in objects created in the monitoring range. The memory leak detection device can set the monitoring range through the steps 1) to 3).
Step 1), obtaining a starting instruction comprising an appointed directory; the starting instruction may be used to start a file detection thread, where the file detection thread is used to detect whether a start file or an end file exists in the specified directory, where the start file is used to trigger a recovery condition for starting a monitored object, and the end file is used to trigger a recovery condition for ending the monitored object;
step 2), when detecting that the starting file exists in the appointed directory, triggering and executing the step of calling JVMTI to monitor whether an object is recovered;
and 3) when the ending file exists in the specified directory, ending monitoring of the object recovery condition, and triggering and executing the step of determining the memory leak object according to the rest identifiers in the preset set.
The start file or the end file can be used as an inter-process communication means, and the interaction of the start process/the end process and the monitored process is counted. Specifically, the memory leak detection device may inject a file detection thread into the application program in advance through a code injection technique. In the running process of the application program, the memory leak detection device may start the file detection thread through the obtained start instruction, the file detection thread detects whether the start file or the end file exists under an appointed directory indicated by the start instruction, if the start file exists, the start file triggers a statistical start process to execute a step of calling JVMTI to monitor whether an object is recovered, and if the end file exists, the end file triggers a statistical end process to execute a step of determining a memory leak object according to remaining identifiers in the preset set. Wherein the start instruction may be sent to the memory leak detection apparatus by a timer or other external application program.
For example, in the running process of the application program, if a timer at time 1 sends a first start instruction to the memory leak detection device to start the file detection thread to detect whether the start file exists in a first specified directory, if the start file exists, the start file triggers and counts a start process to execute a step of calling a JVMTI to monitor whether an object is recovered; if the timer sends a second starting instruction to the memory leak detection device at the time 2, the file detection thread is started to detect whether the end file exists in a second specified directory, and if the end file exists, the end file triggers a statistical end process to execute the step of determining the memory leak object according to the remaining identifiers in the preset set.
The specified directory may be a directory existing under an operating system such as windows, linux, and solaris.
Further, if it is detected that the start file exists in the first designated directory, the statistics start process may deploy a start identifier at a position where the application program is currently running, and call the JVMTI to monitor an object created after the start identifier; if the end file exists in the second designated directory, the statistics end process may deploy an end identifier at the current running position of the application program, and end monitoring of the recovery condition of the object.
For example, the code segments of the application are as follows:
course 1
An object A;
an object B; };
course 2
An object C; };
as shown below, if the file detection thread detects the start file at time 1, the statistics starting process may deploy a start identifier at a running location of the application program (at an entry function of process 1) at time 1, and call the JVMTI to monitor an object created after the start identifier; if the file detection thread detects the end file at time 2, the statistics end process may deploy an end identifier at the running position of the application program (end position of process 1) at time 2, and end monitoring of the recovery condition of the object.
Starting identification;
course 1
An object A;
an object B; };
ending the identification;
course 2
An object C; };
in another optional implementation manner, the memory leak detection device may further limit the monitoring range by writing a configuration file. Further, the configuration file may include classes in the monitoring scope. Before the application program is started, the memory leak detection device may read a bytecode file (or class file) of the application program to be loaded by using a code injection technique, and determine whether a class in the monitoring range exists in the bytecode, if so, inject a start file at an entry function of the class in the bytecode, and inject an end file at an exit function of the class in the bytecode. The memory leak detection device can monitor memory leak of the objects created after the start file and before the end file.
Therefore, in the embodiment of the present invention, the memory leak detection device only monitors the objects of the application program in the operating range from time 1 to time 2, so as to avoid monitoring all the objects in the application program, and the monitored objects have a small order of magnitude and high memory leak detection efficiency.
In another optional embodiment, the memory leak detection apparatus may further track a creation event of each object through a code injection technique to obtain location information of each object, and after determining the memory leak object, determine the location of the memory leak object according to the obtained location information. The location information may include a class file where the object is located, or a specific function of creating the object, or a line number where the object is created, and the like.
In order to avoid the multi-Thread concurrency problem, the memory leak detection device may create an allocation list of threads where the objects are located through a Thread-local mechanism of the JVMTI, and call the JNI function to transfer identifiers and location information of the objects to the allocation list, where the identifiers and the location information of the objects are stored in the allocation list, and the identifiers and the location information of the same object have an association relationship; or, the memory leak detection device may further obtain location information of an object in the application program, and call the JNI function to transfer the location information to a preset set of the JVMTI, where identifiers and location information of multiple objects are stored in the preset set, and the identifiers and the location information of the same object have an association relationship.
The memory leak detection device may call a daemon thread that has been created in the JVMTI to derive the identifier and the location information in the allocation list or the preset set, and send the derived identifier and location information to an analysis program to confirm the location of the memory leak object. Optionally, the memory leak detection device may first obtain the identifier of the memory leak object according to the scheme provided above, query location information associated with the identifier of the memory leak object in the derived identifier and location information, and finally use the queried location information as the location of the memory leak. For example, if the allocation list is shown in table 3, the position information associated with tag _01 to tag _05 is position information 1 to position information 5.
TABLE 3 Allocation List
| tag_01 | Location information 1 |
| tag_02 | Location information 2 |
| tag_03 | Position information 3 |
| tag_04 | Location information 4 |
| tag_05 | Position information 5 |
If the memory leak detection device obtains identifiers of the memory leak objects as tag _03, tag _04, and tag _05 according to the above-mentioned technical solution, the memory leak detection device may use, as the locations of the memory leak objects, location information 3, location information 4, and location information 5 respectively associated with tag _03, tag _04, and tag _05 in table 3.
Optionally, if the derived location information in the allocation list or the preset set is duplicated, the memory leak detection device may query the location information of the memory leak object according to the scheme provided above, and remove duplicated location information in the location information of the memory leak object. For example, if the allocation list is as shown in table 4, there is duplicate location information 3. According to the scheme provided above, if the memory leak detection device obtains the identifiers of the memory leak objects as tag _03, tag _04, and tag _05, the memory leak detection device may query, from table 4, the location information 3, and the location information 5 respectively associated with tag _03, tag _04, and tag _05, and remove the repeated location information 3, so that the location information 3 and the location information 5 are used as the locations of the memory leak objects.
In addition, the memory leak detection device may further count the number of objects associated with the location information of the memory leak objects, and sort the location information of the memory leak objects in a descending order according to the number. By way of example with reference to table 4, the number of objects associated with the location information 3 of the memory leak object is 2, the number of objects associated with the location information 5 of the memory leak object is 1, and the memory leak detection device performs descending order on the location information of the memory leak object according to the number: position information 3, position information 5.
TABLE 4 Allocation List
| tag_01 | Location information 1 |
| tag_02 | Location information 2 |
| tag_03 | Position information 3 |
| tag_04 | Position information 3 |
| tag_05 | Position information 5 |
According to the technical scheme provided by the embodiment of the invention, under the condition that the derived position information is repeated, the memory leak detection equipment can make the position information of the memory leak object intuitively, simply and clearly by carrying out duplication elimination operation on the position information of the memory leak object. In addition, the memory leak detection device can derive the position information through the created daemon thread at random, so that the phenomenon that the use rate of the memory is too high due to the fact that the position information exists in the memory is avoided.
By the technical scheme provided by the embodiment of the invention, the memory leak detection equipment can determine the memory leak object and position the memory leak object at the same time, so that the position of the memory leak object is prevented from being manually searched, and the efficiency of memory leak detection is improved.
Referring to fig. 3, fig. 3 is a schematic structural diagram of a memory leak detection apparatus according to an embodiment of the present invention. Wherein, the apparatus shown in fig. 3 may include:
the monitoring unit 301 is configured to call a Java virtual machine tool interface JVMTI to monitor whether an object is recovered when an application runs on a virtual machine; wherein the object is associated with an identifier;
an identifier deleting unit 302, configured to delete an identifier associated with the object in a preset set when the monitoring unit 301 monitors that the object is recovered; wherein the preset set comprises identifiers associated with the plurality of objects;
an object determining unit 303, configured to determine that an object associated with one or more identifiers of the remaining identifiers in the preset set is a memory leak object.
The monitoring unit 301 is specifically configured to invoke JVMTI to monitor whether an object is recovered.
In an alternative embodiment, as shown in fig. 4, the apparatus further comprises: a position determination unit 304 for tracking creation events of the respective objects by a code injection technique to acquire position information of the respective objects; and after determining the memory leak object according to the remaining identifiers in the preset set, determining the position of the memory leak object according to the position information.
Further, the location determining unit 304 is specifically configured to create an allocation list of threads where the objects are located through a Thread-local mechanism of the JVMTI; calling an information transfer interface function to transfer the identifier and the position information of each object to the distribution list;
wherein the threads are each associated with an allocation list; the distribution list comprises identifiers and position information which are respectively associated with a plurality of objects; the identifier and the position information of the same object in the distribution list have an association relation;
and determining the position of the memory leak object according to the position information in the distribution list.
Further, the location determining unit 304 is further specifically configured to invoke a daemon thread that has been created in the JVMTI to export the identifier and the location information in the allocation list; and determining the position of the memory leak object according to the derived identifier and the position information.
In another alternative embodiment, referring to fig. 5, the apparatus further comprises: an acquisition unit 305 for acquiring a start instruction including a specified directory; the starting instruction is used for starting a file detection thread, the file detection thread is used for detecting whether a starting file or an ending file exists in the specified directory, the starting file is used for triggering the recovery condition of starting the monitoring object, and the ending file is used for triggering the recovery condition of ending the monitoring object;
when detecting that the starting file exists in the specified directory, triggering and executing the step of calling the JVMTI to monitor whether the object is recovered;
and when the ending file is detected to exist in the specified directory, ending the monitoring of the recovery condition of the object, and triggering and executing the step of determining the memory leak object according to the remaining identifiers in the preset set.
Further, the object determining unit 303 is specifically configured to invoke a daemon thread that has been created in the JVMTI to export remaining identifiers in the preset set; and determining the memory leak object according to the derived identifier.
Alternatively, the object determining unit 303 is further specifically configured to determine the memory leak object according to the remaining identifiers in the preset set and a preset excluded object.
The embodiment of the present invention may refer to the related description in the embodiment shown in fig. 2, and is not described herein again.
It can be seen that, with the implementation of the apparatus described in fig. 3, the memory leak detection apparatus can monitor the capability of whether an object in an application is recovered or not, detect an object in the application that is not recovered, that is, an object associated with the remaining identifier, and determine a memory leak object according to the object that is not recovered. Therefore, compared with the prior art that the memory leak object is found by manually judging the number of the object instances or the occupied size of the object memory, the scheme provided by the embodiment of the invention reduces the consumption of human resources and improves the efficiency of memory leak detection.
Referring to fig. 6, fig. 6 is a memory leak detection apparatus 60 according to an embodiment of the present invention, where the apparatus 60 includes a processor 601 and a storage 602, and the processor 601 and the storage 602 are connected to each other through a bus.
The memory 602 includes, but is not limited to, a Random Access Memory (RAM), a Read Only Memory (ROM), an erasable programmable read only memory (EPROM or flash memory), or a portable read only memory (CD-ROM), and the memory 602 is used to store a set of program codes.
The processor 601 may be one or more Central Processing Units (CPUs), and in the case that the processor 601 is one CPU, the CPU may be a single-core CPU or a multi-core CPU.
The processor 601 in the device 60 is configured to read the program code stored in the memory 602, and then perform the following operations:
when an application program runs on a virtual machine, calling a Java virtual machine tool interface JVMTI to monitor whether an object is recovered; wherein the object is associated with an identifier;
deleting the identifier associated with the object in a preset set under the condition that the object is monitored to be recycled; wherein the preset set comprises identifiers associated with the plurality of objects;
and determining that the objects associated with one or more identifiers in the remaining identifiers in the preset set are memory leak objects. In an alternative embodiment, a Java virtual machine tool interface JVMTI is called to monitor whether there are objects reclaimed.
In another optional implementation, the creation events of the objects are tracked through a code injection technology so as to obtain the position information of the objects;
after determining the memory leak object according to the remaining identifiers in the preset set, the method further includes:
and determining the position of the memory leakage object according to the position information.
In another optional implementation, an allocation list of threads where the objects are located is created through a Thread-local mechanism of the JVMTI; calling an information transfer interface function to transfer the identifier and the position information of each object to the distribution list;
wherein the threads are each associated with an allocation list; the distribution list comprises identifiers and position information which are respectively associated with a plurality of objects; the identifier and the position information of the same object in the distribution list have an association relation;
the determining the location of the memory leak object according to the location information includes:
and determining the position of the memory leak object according to the position information in the distribution list.
In another optional implementation, the determining the location of the memory leak object according to the location information includes:
calling a daemon thread which is created in the JVMTI to export identifiers and position information in the distribution list;
and determining the position of the memory leak object according to the derived identifier and the position information.
In another alternative embodiment, a start instruction including a specified directory is obtained; the starting instruction is used for starting a file detection thread, the file detection thread is used for detecting whether a starting file or an ending file exists in the specified directory, the starting file is used for triggering the recovery condition of starting the monitoring object, and the ending file is used for triggering the recovery condition of ending the monitoring object;
when detecting that the starting file exists in the specified directory, triggering and executing the step of calling the JVMTI to monitor whether the object is recovered;
when the ending file is detected to exist in the specified directory, ending monitoring of the object recovery condition, and triggering and executing the step of determining that the object associated with one or more identifiers in the remaining identifiers in the preset set is a memory leak object.
In another optional implementation, the determining a memory leak object according to the remaining identifiers in the preset set includes:
calling a daemon thread which is created in the JVMTI to export the rest identifiers in the preset set;
and determining the memory leak object according to the derived identifier.
In another optional implementation, the determining a memory leak object according to the remaining identifiers in the preset set includes:
and determining the memory leakage object according to the remaining identifiers in the preset set and a preset exclusion object.
The embodiment of the present invention may refer to the related description in the embodiment shown in fig. 2, and is not described herein again.
It can be seen that, with the implementation of the apparatus described in fig. 6, the memory leak detection apparatus can monitor the capability of whether an object in an application is recovered or not by using the JVMTI, detect an object that is not recovered in the application, that is, an object associated with the remaining identifier, and determine a memory leak object according to the object that is not recovered. Therefore, compared with the prior art that the memory leak object is found by manually judging the number of the object instances or the occupied size of the object memory, the scheme provided by the embodiment of the invention reduces the consumption of human resources and improves the efficiency of memory leak detection.
One of ordinary skill in the art will appreciate that all or part of the processes in the methods of the above embodiments may be implemented by hardware related to instructions of a computer program, which may be stored in a computer-readable storage medium, and when executed, may include the processes of the above method embodiments.
Claims (16)
1. A method for memory leak detection, the method comprising:
when an application program runs on a virtual machine, determining a preset set of objects according to preset conditions, wherein the preset set of objects comprises one or more object-associated identifiers, and the preset conditions are used for screening out objects with memory leakage possibility;
obtaining position information of one or more objects in the preset set of objects according to a detection thread injected in the application program;
determining one or more memory leak objects in the preset set of objects;
and determining the positions of one or more memory leak objects in the preset object set according to the position information of one or more objects in the preset object set.
2. The method of claim 1, wherein obtaining location information of one or more objects in the preset set of objects according to a detection thread injected by the application program comprises:
and tracking a creation event of one or more objects in the preset set of objects through a detection thread injected by the application program, and acquiring the position information of the one or more objects in the preset set of objects.
3. The method of claim 1 or 2, wherein the position information of one or more objects in the preset set of objects comprises one or more of: the identification of the class file where the object is located, the identification of the specific function of the object to be created, or the line number where the object is to be created.
4. The method according to any one of claims 1 to 3, wherein the obtaining the location information of the one or more objects in the preset set of objects by tracking creation events of the one or more objects in the preset set of objects through a detection thread injected in the application program further comprises:
creating an allocation list of threads where the objects are located through a Thread-local mechanism of the JVMTI; calling an information transfer interface function to transfer the identifier and the position information of the object to the distribution list;
wherein the threads are each associated with an allocation list; the distribution list comprises identifiers and position information which are respectively associated with one or more objects in the preset set of objects; the identifier and the position information of the same object in the distribution list have an association relationship.
5. The method according to any one of claims 1 to 4, wherein the determining the location of the one or more memory-leaking objects in the preset set of objects according to the location information of the one or more objects in the preset set of objects comprises:
calling a daemon thread which is created in the JVMTI to export identifiers and position information in the distribution list;
and determining the positions of one or more memory leak objects in the preset set of objects according to the derived identifiers and the position information.
6. The method of any of claims 1 to 5, further comprising:
acquiring a starting instruction comprising a specified directory; the starting instruction is used for starting a file detection thread, the file detection thread is used for detecting whether a starting file or an ending file exists in the specified directory, the starting file is used for triggering the recovery condition of starting the monitoring object, and the ending file is used for triggering the recovery condition of ending the monitoring object;
when detecting that the starting file exists in the specified directory, triggering and executing the step of calling the JVMTI to monitor whether the object is recovered;
when the ending file is detected to exist in the specified directory, the monitoring of the object recovery condition is ended, and the step of determining that the object associated with one or more identifiers in the preset object set is a memory leak object is triggered and executed.
7. The method of any of claims 1 to 6, wherein said determining one or more memory leak objects in said preset set of objects comprises:
calling a daemon thread that has been created in the JVMTI to export identifiers of one or more objects in the preset set of objects;
and determining one or more memory leak objects in the preset object set according to the derived identifiers of one or more objects in the preset object set.
8. The method of any of claims 1 to 6, wherein said determining one or more memory leak objects in said preset set of objects comprises:
and determining one or more memory leak objects in the preset object set according to the identifiers of one or more objects in the preset object set and preset exclusion objects.
9. A memory leak detection apparatus, comprising:
the system comprises an object determining unit, a memory leakage detecting unit and a memory leakage detecting unit, wherein the object determining unit is used for determining an object preset set according to preset conditions when an application program runs on a virtual machine, the object preset set comprises one or more object associated identifiers, and the preset conditions are used for screening out objects with memory leakage possibility;
the position determining unit is used for obtaining position information of one or more objects in the preset set of objects according to the detection threads injected in the application program;
the object determination unit is further configured to determine one or more memory leak objects in the preset set of objects;
the position determining unit is further configured to determine positions of one or more memory leak objects in the preset object set according to the position information of one or more objects in the preset object set.
10. The apparatus of claim 9, wherein the location determining unit is further configured to obtain location information of one or more objects in the preset set of objects by tracking creation events of one or more objects in the preset set of objects through a detection thread injected by the application.
11. The apparatus of claim 9 or 10, wherein the location information of one or more objects in the preset set of objects comprises one or more of: the identification of the class file where the object is located, the identification of the specific function of the object to be created, or the line number where the object is to be created.
12. The apparatus according to any of the claims 9 to 11, wherein the location determining unit is specifically configured to create an allocation list of threads where the object is located through a Thread-local mechanism of the JVMTI; calling an information transfer interface function to transfer the identifier and the position information of the object to the distribution list;
wherein the threads are each associated with an allocation list; the distribution list comprises identifiers and position information which are respectively associated with one or more objects in the preset set of objects; the identifier and the position information of the same object in the distribution list have an association relation;
and determining the position of the memory leak object according to the position information in the distribution list.
13. The apparatus according to any of claims 9 to 12, wherein the location determining unit is specifically configured to invoke a daemon thread that has been created in the JVMTI to export identifiers and location information in the allocation list; and determining the positions of one or more memory leak objects in the preset set of objects according to the derived identifiers and the position information.
14. The apparatus according to any one of claims 9 to 13, characterized in that it further comprises:
an acquisition unit configured to acquire a start instruction including a specified directory; the starting instruction is used for starting a file detection thread, the file detection thread is used for detecting whether a starting file or an ending file exists in the specified directory, the starting file is used for triggering the recovery condition of starting the monitoring object, and the ending file is used for triggering the recovery condition of ending the monitoring object;
when detecting that the starting file exists in the specified directory, triggering and executing the step of calling the JVMTI to monitor whether the object is recovered;
when the ending file is detected to exist in the specified directory, the monitoring of the object recovery condition is ended, and the step of determining that the object associated with one or more identifiers in the preset object set is a memory leak object is triggered and executed.
15. The device according to any one of claims 9 to 14, wherein the object determination unit is specifically configured to invoke a daemon thread that has been created in the JVMTI to export identifiers of one or more objects in the preset set of objects; and determining one or more memory leak objects in the preset set of objects according to the derived identifiers of one or more objects in the preset set of objects.
16. The apparatus according to any one of claims 9 to 14, wherein the object determining unit is further specifically configured to determine one or more memory leak objects in the preset set of objects according to identifiers of one or more objects in the preset set of objects and a preset excluded object.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111144069.8A CN114003488A (en) | 2017-03-31 | 2017-03-31 | Memory leak detection method and equipment |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111144069.8A CN114003488A (en) | 2017-03-31 | 2017-03-31 | Memory leak detection method and equipment |
| CN201710211056.5A CN108664390B (en) | 2017-03-31 | 2017-03-31 | Memory leak detection method and equipment |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710211056.5A Division CN108664390B (en) | 2017-03-31 | 2017-03-31 | Memory leak detection method and equipment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114003488A true CN114003488A (en) | 2022-02-01 |
Family
ID=63784075
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710211056.5A Active CN108664390B (en) | 2017-03-31 | 2017-03-31 | Memory leak detection method and equipment |
| CN202111144069.8A Pending CN114003488A (en) | 2017-03-31 | 2017-03-31 | Memory leak detection method and equipment |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710211056.5A Active CN108664390B (en) | 2017-03-31 | 2017-03-31 | Memory leak detection method and equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (2) | CN108664390B (en) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN109542778A (en) * | 2018-11-12 | 2019-03-29 | 中国银联股份有限公司 | A kind of method and device of resource leak detection |
| CN110704313B (en) * | 2019-09-25 | 2023-07-25 | 北京宝兰德软件股份有限公司 | JAVA virtual machine memory leakage detection method and device |
| CN112732513B (en) * | 2019-10-28 | 2023-05-23 | 腾讯科技（深圳）有限公司 | Memory monitoring method, memory monitoring device, computer readable storage medium and computer equipment |
| CN111143100A (en) * | 2019-12-09 | 2020-05-12 | 北京小米移动软件有限公司 | Memory leak detection method, device, equipment and storage medium |
| CN113835992B (en) * | 2020-06-23 | 2023-10-20 | 抖音视界有限公司 | Memory leakage processing method and device, electronic equipment and computer storage medium |
| CN111984541A (en) * | 2020-08-31 | 2020-11-24 | 北京达佳互联信息技术有限公司 | Memory leak detection method and device and terminal |
| CN112527663A (en) * | 2020-12-17 | 2021-03-19 | 杭州国芯科技股份有限公司 | Method for detecting memory used by software in embedded system |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7340493B2 (en) * | 2003-07-02 | 2008-03-04 | International Business Machines Corporation | System and method for reducing memory leaks in virtual machine programs |
| US7434206B2 (en) * | 2005-03-10 | 2008-10-07 | Hewlett-Packard Development Company, L.P. | Identifying memory leaks in computer systems |
| CN101046755B (en) * | 2006-03-28 | 2011-06-15 | 郭明南 | System and method of computer automatic memory management |
| US8566795B2 (en) * | 2008-07-15 | 2013-10-22 | International Business Machines Corporation | Selectively obtaining call stack information based on criteria |
| CN101727355B (en) * | 2008-10-31 | 2013-02-20 | 国际商业机器公司 | Handling method and system for memory access events |
| CN101593152B (en) * | 2009-06-25 | 2011-07-27 | 青岛海信移动通信技术股份有限公司 | Method and device for detecting memory leakage of mobile terminal |
| CN102122263A (en) * | 2011-03-23 | 2011-07-13 | 成都勤智数码科技有限公司 | Monitoring method and device of JAVA application system in running |
| US8539506B2 (en) * | 2012-02-09 | 2013-09-17 | Microsoft Corporation | Dynamic injection of code into running process |
| CN102866947A (en) * | 2012-08-29 | 2013-01-09 | 深圳市共进电子股份有限公司 | Method for detecting internal memory leakage of Linux kernel |
| CN103577335B (en) * | 2013-10-23 | 2016-09-07 | 中国科学院计算技术研究所 | A kind of internal memory garbage retrieving system and method |
| CN103701651B (en) * | 2013-12-31 | 2017-01-04 | 山东中创软件工程股份有限公司 | Application service disaster tolerance apparatus and method under a kind of domestic environment |
| CN103714004A (en) * | 2014-01-02 | 2014-04-09 | 金蝶软件（中国）有限公司 | JVM online memory leak analysis method and system |
| CN105912458A (en) * | 2016-03-28 | 2016-08-31 | 中国电力科学研究院 | Method and system for dynamically detecting C/C++ memory leak |
| CN106295354B (en) * | 2016-08-08 | 2019-09-27 | 中国科学院信息工程研究所 | A kind of android system heap overflow validating vulnerability method and device |
| CN106407114B (en) * | 2016-09-20 | 2017-12-15 | 腾讯科技（深圳）有限公司 | Memory overflow analysis method and device |
-
2017
- 2017-03-31 CN CN201710211056.5A patent/CN108664390B/en active Active
- 2017-03-31 CN CN202111144069.8A patent/CN114003488A/en active Pending
Also Published As
| Publication number | Publication date |
|---|---|
| CN108664390A (en) | 2018-10-16 |
| CN108664390B (en) | 2021-10-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108664390B (en) | Memory leak detection method and equipment | |
| US8429620B2 (en) | Memory leak diagnosis | |
| US7685182B2 (en) | Interleaved garbage collections | |
| US8661450B2 (en) | Deadlock detection for parallel programs | |
| US9003240B2 (en) | Blackbox memory monitoring with a calling context memory map and semantic extraction | |
| CN105159777A (en) | Process memory collection method and apparatus | |
| US9189393B2 (en) | Computer, control method of computer, and recording medium | |
| US10372601B2 (en) | Managing memory in a computer system | |
| JP2005108235A (en) | Autonomic memory leak detection and remediation | |
| CN111625833B (en) | Efficient method and device for judging reuse loopholes after release of software program | |
| US8122454B2 (en) | Managing memory resources in a shared memory system | |
| CN107077422B (en) | Determining causes of memory external fragmentation | |
| CN102681938A (en) | Memory leakage detecting method and device | |
| US9274946B2 (en) | Pre-leak detection scan to identify non-pointer data to be excluded from a leak detection scan | |
| US9910758B2 (en) | Computer flight recorder with active error detection | |
| CN112612537A (en) | Configuration data caching method, device, equipment and storage medium | |
| KR101494328B1 (en) | Apparatus and Method for Detecting Memory Leak using Heap Analysis | |
| KR102443089B1 (en) | Synchronization in a computing device | |
| CN108121602B (en) | Method for determining garbage collection trigger point, electronic equipment and storage medium | |
| CN110704313B (en) | JAVA virtual machine memory leakage detection method and device | |
| CN107122247B (en) | Method and device for detecting static occupied picture | |
| US8930420B2 (en) | Orphan object tracking for objects having acquire-release semantics | |
| CN115617504A (en) | Memory management system, leakage detection method and storage medium | |
| CN107844394B (en) | Memory leak positioning method and device | |
| CN109445951B (en) | Information processing method and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |