A memory exception attribution method and device, computer equipment and a storage medium
By automatically acquiring and analyzing memory usage description files across multiple devices, filtering and aggregating target business code, the problem of low efficiency and accuracy in memory anomaly attribution analysis is solved, achieving efficient memory anomaly analysis and rapid resolution.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- DOUYIN VISION CO LTD
- Filing Date
- 2022-08-30
- Publication Date
- 2026-06-09
AI Technical Summary
Existing technologies for memory anomaly attribution analysis are inefficient and inaccurate, leading to functional malfunctions during application runtime.
By automatically acquiring memory usage description files from multiple devices, analyzing memory anomalies using analysis threads, filtering out candidate program objects that cause memory anomalies, and aggregating target business code through multi-threading, the main cause of memory anomalies can be determined.
It enables automated analysis of memory anomalies, improving analysis efficiency and accuracy, and allowing for rapid identification and resolution of memory anomaly issues.
Smart Images
Figure CN117667471B_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of computer technology, and more specifically, to a method, apparatus, computer device, and storage medium for attributing memory anomalies. Background Technology
[0002] Applications frequently encounter memory exceptions during runtime. When a memory exception occurs, users may be unable to perform certain functionalities, impacting the application's user experience. There are many causes of memory exceptions, and it's necessary to examine the application's stack trace in the memory log file to find the time of the exception.
[0003] Currently, memory anomaly attribution analysis has low efficiency and low accuracy. Summary of the Invention
[0004] This disclosure provides at least one method, apparatus, computer device, and storage medium for attributing memory anomalies.
[0005] In a first aspect, embodiments of this disclosure provide a memory anomaly attribution method, including:
[0006] In response to a memory exception occurring during the operation of a target application deployed on multiple devices, the system obtains memory usage description files for the target application generated on each of the multiple devices; the memory usage description files are used to describe the memory usage of each program object in the target application.
[0007] For each device, an analysis thread corresponding to each device is created, and using the analysis thread corresponding to each device, based on the memory usage description file generated for each device, candidate program objects causing the memory exception and the exception types caused by the candidate program objects are determined.
[0008] Extract the target business code that references the candidate program object from the memory usage description file generated by each device;
[0009] For each of the aforementioned exception types, the target business code of each candidate program object matching the exception type is aggregated to obtain the occurrence frequency of each candidate object under the exception type;
[0010] Based on the frequency of occurrence of each candidate program object under the aforementioned exception type, the target program object to be updated that caused the memory exception is selected.
[0011] In one optional implementation, the exception type includes a first type; the first type is used to indicate that a memory leak has occurred; the memory usage description file includes: release status information of each program object after requesting memory release;
[0012] The process of determining candidate program objects causing memory anomalies and the types of anomalies caused by these candidate program objects, based on the memory usage description file generated for each device, includes:
[0013] The program objects in the memory usage description file generated by each device are traversed to obtain the release status information of each program object after a request to release memory;
[0014] If the release status information indicates that the program object has not been released, the program object is identified as a candidate program object that could cause the memory exception, and the exception type caused by the candidate program object is identified as the first type.
[0015] In one optional implementation, the exception type includes a second type; the second type indicates that the size of a first memory space occupied by the candidate program object exceeds a set threshold.
[0016] The process of determining candidate program objects causing memory anomalies and the types of anomalies caused by these candidate program objects, based on the memory usage description file generated for each device, includes:
[0017] Based on the memory usage description file generated by each device, at least one reference chain is determined, as well as the first memory space size occupied by each reference chain; each reference chain includes: a first program object, and a second program object directly and / or indirectly referenced by the first program object;
[0018] The size of the first memory space occupied by each of the aforementioned reference chains is compared with the set threshold.
[0019] In response to any reference chain occupying a first memory space larger than the set threshold, the first program object in that reference chain is identified as a candidate program object, and the exception type caused by the candidate program object is identified as a second type.
[0020] In one optional implementation, the memory usage description file includes: the size of a second memory space occupied by each program object;
[0021] The determination of at least one reference chain and the first memory space size occupied by each reference chain, based on the memory usage description file generated for each device, includes:
[0022] The memory usage description file generated by each device is parsed to obtain the reference relationship information corresponding to each program object;
[0023] Based on the reference relationship information corresponding to each program object, the reference relationship chain is determined, and based on the second memory space size occupied by the first program object and the second program object included in the reference relationship chain, the first memory space size occupied by the reference relationship chain is determined.
[0024] In one optional implementation, the step of filtering out the target program object to be updated that caused the memory exception based on the frequency of occurrence of each candidate program object under the exception type includes:
[0025] The occurrence frequency of candidate program objects under each exception type is compared with a preset frequency threshold;
[0026] In response to the occurrence frequency of any candidate program object under each exception type being greater than or equal to the preset frequency threshold, each candidate program object is determined as the target program object;
[0027] or,
[0028] In response to the occurrence frequency of any candidate program object under each exception type being greater than or equal to the preset frequency threshold, the total memory space occupied by any candidate program object is determined; in response to the total memory space occupied by any candidate program object being greater than the preset memory space threshold, any candidate program object is determined as the target program object.
[0029] In one optional implementation, extracting the target business code that references the candidate program object from the memory usage description file generated by each device includes:
[0030] Extract the first line of business code from the business code of each candidate program object from the memory usage description file generated by each device;
[0031] The first line of business code is used as the target business code that references the candidate program object.
[0032] In one optional implementation, the step of aggregating the target business code of each candidate program object matching the exception type for each exception type to obtain the occurrence frequency of each candidate object under the exception type includes:
[0033] For each of the aforementioned exception types, the target business code of each candidate program object matching the aforementioned exception type is aggregated to obtain the occurrence frequency of each of the aforementioned target business codes;
[0034] The frequency of occurrence of each target business code is taken as the frequency of occurrence of each candidate object under the exception type.
[0035] Secondly, embodiments of this disclosure also provide a memory anomaly attribution device, comprising:
[0036] The acquisition module is used to acquire memory usage description files of the target application generated by the multiple devices respectively in response to a memory exception that occurs during the operation of the target application deployed on multiple devices; the memory usage description files are used to describe the memory usage of each program object in the target application.
[0037] The determination module is used to create an analysis thread corresponding to each device for each device, and use the analysis thread corresponding to each device to determine the candidate program object that causes the memory exception and the exception type caused by the candidate program object based on the memory usage description file generated by each device.
[0038] An extraction module is used to extract target business code that references the candidate program object from the memory usage description file generated by each device;
[0039] An aggregation module is used to aggregate the target business code of each candidate program object matching the exception type for each exception type, so as to obtain the occurrence frequency of each candidate object under the exception type.
[0040] The filtering module is used to filter out the target program objects that cause the memory exception based on the frequency of occurrence of each candidate program object under the exception type.
[0041] Thirdly, embodiments of this disclosure also provide a computer device, including: a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the computer device is running, the processor communicates with the memory via the bus, and when the machine-readable instructions are executed by the processor, the steps of the first aspect above, or any possible implementation of the first aspect, are performed.
[0042] Fourthly, embodiments of this disclosure also provide a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the first aspect or any possible implementation of the first aspect.
[0043] The memory anomaly attribution method provided in this disclosure can automatically obtain the memory usage files of the target applications deployed on multiple devices when memory anomalies are detected during operation. Then, using pre-created analysis threads corresponding to each device, the method can automatically determine the target program object causing the memory anomaly for each anomaly type based on the memory usage files. This process automates the detection of memory anomalies, the acquisition of memory usage files, and the analysis of these files. Furthermore, by using multiple threads to analyze memory usage files on different devices simultaneously, the efficiency of memory anomaly attribution analysis is improved.
[0044] Furthermore, the above process automatically aggregates the target business code for each type of exception to identify the target program object that caused the memory exception. In other words, it identifies the main cause of various types of memory exceptions and achieves accurate attribution of memory exceptions.
[0045] To make the above-mentioned objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description
[0046] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the embodiments will be briefly described below. These drawings are incorporated in and constitute a part of this specification. They illustrate embodiments conforming to this disclosure and, together with the specification, serve to explain the technical solutions of this disclosure. It should be understood that the following drawings only show some embodiments of this disclosure and should not be considered as limiting the scope. Those skilled in the art can obtain other related drawings based on these drawings without creative effort.
[0047] Figure 1 A flowchart of a memory anomaly attribution method provided by an embodiment of this disclosure is shown;
[0048] Figure 2 A schematic diagram of a memory anomaly attribution device provided in an embodiment of this disclosure is shown;
[0049] Figure 3 A schematic diagram of a computer device provided in an embodiment of this disclosure is shown. Detailed Implementation
[0050] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. The components of the embodiments of this disclosure described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this disclosure provided in the accompanying drawings is not intended to limit the scope of the claimed disclosure, but merely represents selected embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without inventive effort are within the scope of protection of this disclosure.
[0051] When an application encounters a memory exception during runtime, memory exception detection tools are typically used to detect it. However, the collection and analysis of memory exception information are performed through processes and require manual completion by testers or developers. This process is time-consuming, resulting in low efficiency and accuracy in analyzing memory exception problems.
[0052] Based on this, this disclosure provides a memory anomaly attribution method. When a memory anomaly is detected during the execution of a target application deployed on multiple devices, the method can automatically obtain the memory usage files of the target application generated on each device. Then, using a pre-created analysis thread corresponding to each device, the method can automatically determine the target program object causing the memory anomaly for each anomaly type based on the memory usage files. The above process automates the processes of detecting memory anomalies, obtaining memory usage files, and analyzing memory usage files. Furthermore, it improves the efficiency of memory anomaly attribution analysis by simultaneously analyzing memory usage files on different devices through multi-threading.
[0053] Furthermore, the above process automatically aggregates the target business code for each type of exception to identify the target program object that caused the memory exception. In other words, it identifies the main cause of various types of memory exceptions and achieves accurate attribution of memory exceptions.
[0054] The deficiencies of the above solutions and the proposed solutions are the result of the inventor's practice and careful research. Therefore, the discovery process of the above problems and the solutions proposed in this disclosure below should be considered as the inventor's contribution to this disclosure.
[0055] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.
[0056] To facilitate understanding of this embodiment, a memory anomaly attribution method disclosed in this disclosure will first be described in detail. The execution subject of the memory anomaly attribution method provided in this disclosure is generally a computer device with a certain computing power.
[0057] See Figure 1 The diagram shows a flowchart of a memory anomaly attribution method provided in an embodiment of this disclosure. The method includes steps S101 to S105, wherein:
[0058] S101: In response to a memory exception occurring during the operation of a target application deployed on multiple devices, obtain memory usage description files of the target application generated by each of the multiple devices; the memory usage description files are used to describe the memory usage of each program object in the target application.
[0059] In this embodiment, memory may include a memory model managed by the Java Virtual Machine (JVM). Memory anomalies in the target application typically include: the target application failing to release memory space after it has been allocated and used during runtime, preventing the JVM from reusing that memory space (memory leak); or the target application requesting more memory than the JVM can provide (memory overflow). When such memory anomalies occur, the target application is prone to crashing. Therefore, when a memory anomaly occurs in the target application, its memory usage description file can be obtained. By analyzing the memory usage description file, the specific cause of the target application crash can be determined.
[0060] In one implementation, a pre-created memory analysis tool can be used to obtain real-time memory status information of the target application during its runtime. This memory status information can describe the memory status of the target application. When the obtained memory status information indicates that a memory exception has occurred in the target application, a memory usage description file at the moment the memory exception occurred can be obtained. This memory usage description file can include the memory usage of each program object in the target application, such as the size of the memory space occupied by each program object. In another implementation, a heap memory snapshot file (Heap Profile, Hprof file) of the target application can be obtained. The Hprof file can be a reference tree structure file of each program object in Java memory, recording the memory usage of each program object and the reference relationships between each program object in memory.
[0061] The pre-created memory analysis tool mentioned above can be pre-bound to the target application. For each device with the target application deployed, upon obtaining the memory status information from that device indicating a memory exception in the target application, the memory usage description file of the target application generated by that device can be automatically obtained. In other words, the pre-created memory analysis tool can automatically obtain the memory usage description files of the target application generated by multiple devices with the target application deployed when a memory exception occurs.
[0062] S102: For each device, create an analysis thread corresponding to each device, and use the analysis thread corresponding to each device to determine the candidate program object that causes the memory exception and the exception type caused by the candidate program object based on the memory usage description file generated by each device.
[0063] After obtaining the memory usage description file, the candidate program objects causing memory exceptions and the types of exceptions caused by the candidate program objects can be determined based on the memory usage of each program object included in the memory usage description file.
[0064] In one implementation, an analysis thread corresponding to each device can be created using the aforementioned pre-created memory analysis tool. That is, when memory usage description files of the target application generated by multiple devices deploying the target application are obtained, a corresponding analysis thread can be created for each device. Using the analysis thread corresponding to each device, based on the memory usage description file of the target application generated by each device, candidate program objects causing memory anomalies and the types of anomalies caused by these candidate program objects are determined. Since the aforementioned memory analysis tool for analyzing and processing memory usage description files can be thread-level, by using multiple created analysis threads to process the memory usage description files generated by each device in parallel, the efficiency of memory anomaly attribution analysis can be improved.
[0065] Based on the various scenarios of memory anomalies occurring in the target application, the anomaly types caused by candidate program objects can correspondingly include multiple types. In one implementation, the anomaly types caused by candidate program objects can specifically include a first type and a second type. The first type indicates a memory leak, meaning that the target application has not released memory space after it has been used up during runtime. The second type indicates that the size of the first memory space occupied by the candidate program object exceeds a set threshold. Here, the size of the first memory space occupied by the candidate program object can refer to the size of the memory space occupied by the reference chain in which the candidate program object resides, as will be described in detail later.
[0066] In one implementation, given that the exception type may include a first type and the memory usage description file may include release status information of each program object after requesting memory release, the process of determining candidate program objects causing memory exceptions and the exception types caused by the candidate program objects based on the memory usage description file may specifically include: traversing the program objects in the memory usage description file generated by each device to obtain the release status information of each program object after requesting memory release; if the release status information indicates that the program object has not been released, identifying the program object as a candidate program object causing memory exceptions, and identifying the exception type caused by the candidate program object as the first type.
[0067] The program objects here can include, for example, program activities (Activities) and program fragments (Fragments). An Activity can refer to a user interface program, used to provide interactive interface functionality to the user. A pre-created user interface (UI) can be placed on the window created by the Activity. When a later Activity starts, the lifecycle of the earlier started Activity has ended, and the earlier started Activity can request memory release. The release status information of each program object after requesting memory release can be stored in a memory usage description file. In one implementation, the release status information of an Activity can be target attribute information. The target attribute information contains a true value (True) to indicate that the Activity is in a released state; and an error value (False) to indicate that the Activity is not released.
[0068] For an Activity whose lifecycle has ended, if the onDestroy method has been executed, and there is still a reference chain to the Garbage Collector Root (GC Root), the corresponding release status information can indicate that the Activity has not been released. In this case, the Activity cannot be reclaimed by the GC. The corresponding release status information indicating that the Activity has not been released can be used as a candidate for causing a memory exception, and the exception type caused by the candidate Activity can be identified as the first type.
[0069] In one implementation, for cases where the exception type may include a second type, the process of determining candidate program objects causing memory exceptions and the exception types caused by the candidate program objects based on the memory usage description file generated for each device may specifically include: determining at least one reference chain and the first memory space size occupied by each reference chain based on the memory usage description file generated for each device; comparing the first memory space size occupied by each reference chain with a set threshold; and, in response to the set threshold of the first memory space size occupied by any reference chain, determining the first program object in any reference chain as a candidate program object and determining the exception type caused by the candidate program object as a second type.
[0070] Each reference chain includes: a first program object, and a second program object directly and / or indirectly referenced by the first program object. That is, the first program object in the reference chain can be the starting point of the reference chain, and the second program object can be a program object directly and / or indirectly referenced by the first program object.
[0071] The initial memory space size occupied by each reference chain (e.g., retained size) can include the sum of the memory space size occupied by the first program object itself (e.g., shallow size) and the memory space size occupied by each second program object.
[0072] Here, a threshold can be set for the size of the first memory space occupied by the reference chain, such as 1 MB. The size of the first memory space occupied by each reference chain is compared with the set threshold. Program objects whose size of the first memory space occupied by the reference chain is greater than the set threshold are identified as candidate program objects, and the exception type caused by the candidate program object is identified as the second type.
[0073] In one implementation, the memory usage description file may include the second memory space size occupied by each program object. The process of determining at least one reference chain and the first memory space size occupied by each reference chain based on the memory usage description file generated for each device may specifically include: parsing the memory usage description file generated for each device to obtain reference relationship information corresponding to each program object; determining the reference chain based on the reference relationship information corresponding to each program object; and determining the first memory space size occupied by the reference chain based on the second memory space sizes occupied by the first program object and the second program object included in the reference chain.
[0074] During the parsing of the memory usage description file, the instance information in the file can be parsed into a graph structure describing reference relationships. Then, a target algorithm (such as a graph search algorithm) is used to determine the reference relationship information corresponding to each program object. By summing the second memory space sizes occupied by the first program object and the second program object included in the reference relationship chain, the first memory space size occupied by the reference relationship chain is obtained.
[0075] In one implementation, the identified candidate program objects and their corresponding reference chains can be displayed in the visual interface of a pre-built memory analysis tool, thereby providing an intuitive understanding of the identified candidate program objects and their corresponding reference chains.
[0076] Regarding the aforementioned exception types, which may include a first type, and the memory usage description file may include release status information of each program object after requesting memory release, in one implementation, after identifying the candidate program object causing the first type of memory exception, the target reference chain from the candidate program object to the GC Root can be determined based on the memory usage description file. Then, based on the target reference chain from the candidate program object to the GC Root, the size of the third memory space occupied by the target reference chain is determined.
[0077] The target reference chain from candidate program objects to GC roots can be a strong reference chain, meaning that program objects causing memory leaks in a strong reference chain will never be released. The target reference chain from candidate program objects to GC roots can contain candidate program objects as well as third program objects directly and / or indirectly referenced by the candidate program objects. The size of the third memory space occupied by the target reference chain can include the sum of the memory space occupied by the candidate program object itself and the memory space occupied by the third program objects.
[0078] Then, based on the size of the third memory space occupied by the target reference chain, the severity of the memory anomaly caused by the candidate program object is determined. The larger the size of the third memory space occupied by the target reference chain, the more severe the memory anomaly caused by the corresponding candidate program object. In one implementation, based on the severity information of the memory anomalies caused by the candidate program objects, candidate program objects causing severe memory anomalies can be processed first. Furthermore, through the target reference chain from the candidate program object to the GC Root, the fourth program object referenced by the candidate program object can also be determined, that is, which program object caused the memory anomaly of the candidate program object can be identified, thus determining the target program object to be processed.
[0079] S103: Extract the target business code that references the candidate program object from the memory usage description file generated by each device.
[0080] Here, the first line of business code in the business code of each candidate program object can be extracted from the memory usage description file generated for each device; this first line of business code is used as the target business code referencing the candidate program object. For each candidate program object, the target business code referencing that candidate program object may be the same as or different from the target business code referencing other candidate program objects. In practice, the target business code can be aggregated to count the frequency of occurrence of each candidate object under the exception type; the specific process is described below.
[0081] S104: For each of the above exception types, aggregate the target business code of each candidate program object matching the exception type to obtain the occurrence frequency of each candidate object under the exception type.
[0082] S105: Based on the frequency of occurrence of each candidate program object under the aforementioned exception type, filter out the target program object to be updated that caused the memory exception.
[0083] This can be used to filter candidate program objects under each exception type to identify the main target program objects that cause memory exceptions of that exception type, such as the target program object that causes memory exceptions of that exception type the most times.
[0084] In a specific implementation, for each exception type, the target business code matching each candidate program object under that exception type can be used as the aggregation feature to perform data aggregation on the candidate program objects under each exception type. That is, the frequency of occurrence of the target business code matching each candidate program object under that exception type is counted, which is the frequency of occurrence of each candidate program object under each exception type.
[0085] For example, for candidate program objects of the first type, i.e. candidate program objects that cause memory leaks, the first line of business code of each candidate program object can be aggregated to obtain the frequency of occurrence of each first line of business code, i.e. the frequency of occurrence of each candidate program object of the first type; for candidate program objects of the second type, i.e. candidate program objects that cause the size of the first memory space occupied to exceed a set threshold, the first line of business code of each candidate program object can be aggregated to obtain the frequency of occurrence of each first line of business code, i.e. the frequency of occurrence of each candidate program object of the second type.
[0086] In one implementation, the process of selecting the target program object to be updated based on the occurrence frequency of each candidate program object under each anomaly type may specifically include: comparing the occurrence frequency of the candidate program object under each anomaly type with a preset frequency threshold; and determining each candidate program object as the target program object in response to the occurrence frequency of any candidate program object under each anomaly type being greater than or equal to the preset frequency threshold.
[0087] In the above embodiments, a preset frequency threshold for candidate program objects under each exception type can be set separately, meaning the preset frequency thresholds for candidate program objects under different exception types can be different; alternatively, a uniform preset frequency threshold can be set, meaning the preset frequency thresholds for candidate program objects under different exception types can be the same. In other embodiments, the candidate program object with the highest occurrence frequency under each exception type can be determined as the target program object.
[0088] In one implementation, the total memory space occupied by any candidate program object can be determined in response to the occurrence frequency of any candidate program object under each exception type being greater than or equal to the preset frequency threshold; and in response to the total memory space occupied by any candidate program object being greater than the preset memory space threshold, the candidate program object can be determined as the target program object.
[0089] Here, the total memory space size can refer to the memory space occupied by the candidate program object itself and the memory space occupied by other program objects directly or indirectly referenced by the candidate program object.
[0090] In the above implementation, in addition to the occurrence frequency of any candidate program object under each exception type being greater than or equal to the preset frequency threshold, any candidate program object can also be determined as the target program object if the total memory space occupied by any candidate program object is greater than the preset memory space threshold.
[0091] Through the above implementation process, the target program objects that need to be processed first can be screened out. Moreover, the above implementation process does not require manual analysis of the memory usage description file of the target application. By automatically analyzing the memory usage description file of the target application, and by using multi-threading to analyze the memory usage files of different devices simultaneously, the efficiency of memory anomaly attribution analysis can be improved, and memory anomaly problems can be resolved quickly.
[0092] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.
[0093] Based on the same inventive concept, this disclosure also provides a memory anomaly attribution device corresponding to the memory anomaly attribution method. Since the principle of the device in this disclosure for solving the problem is similar to the memory anomaly attribution method described above in this disclosure, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.
[0094] Reference Figure 2 The diagram shown is an architectural schematic of a memory anomaly attribution device provided in an embodiment of this disclosure. The device includes: an acquisition module 201, a determination module 202, an extraction module 203, an aggregation module 204, and a filtering module 205, wherein:
[0095] The acquisition module 201 is used to acquire memory usage description files of the target applications generated by the multiple devices respectively in response to a memory exception that occurs during the operation of the target applications deployed on multiple devices; the memory usage description files are used to describe the memory usage of each program object in the target application.
[0096] The determination module 202 is used to create an analysis thread corresponding to each device for each device, and use the analysis thread corresponding to each device to determine the candidate program object that causes the memory abnormality and the type of abnormality caused by the candidate program object based on the memory usage description file generated by each device.
[0097] Extraction module 203 is used to extract target business code that references the candidate program object from the memory usage description file generated by each device;
[0098] Aggregation module 204 is used to aggregate the target business code of each candidate program object matching the exception type for each exception type, so as to obtain the occurrence frequency of each candidate object under the exception type;
[0099] The filtering module 205 is used to filter out the target program object to be updated that causes the memory abnormality based on the frequency of occurrence of each candidate program object under the abnormality type.
[0100] In one optional implementation, the exception type includes a first type; the first type is used to indicate that a memory leak has occurred; the memory usage description file includes: release status information of each program object after requesting memory release;
[0101] Module 202 is specifically used for:
[0102] The program objects in the memory usage description file generated by each device are traversed to obtain the release status information of each program object after a request to release memory;
[0103] If the release status information indicates that the program object has not been released, the program object is identified as a candidate program object that could cause the memory exception, and the exception type caused by the candidate program object is identified as the first type.
[0104] In one optional implementation, the exception type includes a second type; the second type indicates that the size of a first memory space occupied by the candidate program object exceeds a set threshold.
[0105] Module 202 is specifically used for:
[0106] Based on the memory usage description file generated by each device, at least one reference chain is determined, as well as the first memory space size occupied by each reference chain; each reference chain includes: a first program object, and a second program object directly and / or indirectly referenced by the first program object;
[0107] The size of the first memory space occupied by each of the aforementioned reference chains is compared with the set threshold.
[0108] In response to any reference chain occupying a first memory space larger than the set threshold, the first program object in that reference chain is identified as a candidate program object, and the exception type caused by the candidate program object is identified as a second type.
[0109] In one optional implementation, the memory usage description file includes: the size of a second memory space occupied by each program object;
[0110] Module 202 is specifically used for:
[0111] The memory usage description file generated by each device is parsed to obtain the reference relationship information corresponding to each program object;
[0112] Based on the reference relationship information corresponding to each program object, the reference relationship chain is determined, and based on the second memory space size occupied by the first program object and the second program object included in the reference relationship chain, the first memory space size occupied by the reference relationship chain is determined.
[0113] In one optional implementation, the filtering module 205 has features for:
[0114] The occurrence frequency of candidate program objects under each exception type is compared with a preset frequency threshold;
[0115] In response to the occurrence frequency of any candidate program object under each exception type being greater than or equal to the preset frequency threshold, each candidate program object is determined as the target program object;
[0116] or,
[0117] In response to the occurrence frequency of any candidate program object under each exception type being greater than or equal to the preset frequency threshold, the total memory space occupied by any candidate program object is determined; in response to the total memory space occupied by any candidate program object being greater than the preset memory space threshold, any candidate program object is determined as the target program object.
[0118] In one optional implementation, the extraction module 203 has features for:
[0119] Extract the first line of business code from the business code of each candidate program object from the memory usage description file generated by each device;
[0120] The first line of business code is used as the target business code that references the candidate program object.
[0121] In one alternative implementation, the aggregation module 20 has features for:
[0122] For each of the aforementioned exception types, the target business code of each candidate program object matching the aforementioned exception type is aggregated to obtain the occurrence frequency of each of the aforementioned target business codes;
[0123] The frequency of occurrence of each target business code is taken as the frequency of occurrence of each candidate object under the exception type.
[0124] The processing flow of each module in the device and the interaction flow between each module can be referred to the relevant descriptions in the above method embodiments, and will not be detailed here.
[0125] Based on the same technical concept, this disclosure also provides a computer device. (See also...) Figure 3 The diagram shows the structure of a computer device 300 provided in this embodiment, including a processor 301, a memory 302, and a bus 303. The memory 302 stores execution instructions and includes a main memory 3021 and an external memory 3022. The main memory 3021, also called internal memory, is used to temporarily store computational data in the processor 301 and data exchanged with external memory such as a hard disk. The processor 301 exchanges data with the external memory 3022 through the main memory 3021. When the computer device 300 is running, the processor 301 and the memory 302 communicate through the bus 303, causing the processor 301 to execute the following instructions:
[0126] In response to a memory exception occurring during the operation of a target application deployed on multiple devices, the system obtains memory usage description files for the target application generated on each of the multiple devices; the memory usage description files are used to describe the memory usage of each program object in the target application.
[0127] For each device, an analysis thread corresponding to each device is created, and using the analysis thread corresponding to each device, based on the memory usage description file generated for each device, candidate program objects causing the memory exception and the exception types caused by the candidate program objects are determined.
[0128] Extract the target business code that references the candidate program object from the memory usage description file generated by each device;
[0129] For each of the aforementioned exception types, the target business code of each candidate program object matching the exception type is aggregated to obtain the occurrence frequency of each candidate object under the exception type;
[0130] Based on the frequency of occurrence of each candidate program object under the aforementioned exception type, the target program object to be updated that caused the memory exception is selected.
[0131] This disclosure also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the memory exception attribution method described in the above-described method embodiments. The storage medium may be a volatile or non-volatile computer-readable storage medium.
[0132] This disclosure also provides a computer program product carrying program code. The program code includes instructions that can be used to execute the steps of the memory exception attribution method described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.
[0133] The aforementioned computer program product can be implemented through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically embodied in a computer storage medium; in another optional embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.
[0134] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection may be through some communication interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.
[0135] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0136] In addition, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0137] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0138] Finally, it should be noted that the above-described embodiments are merely specific implementations of this disclosure, used to illustrate the technical solutions of this disclosure, and not to limit it. The protection scope of this disclosure is not limited thereto. Although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this disclosure. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure, and should all be covered within the protection scope of this disclosure. Therefore, the protection scope of this disclosure should be determined by the protection scope of the claims.
Claims
1. A memory anomaly attribution method, characterized in that, include: In response to a memory exception occurring during the operation of a target application deployed on multiple devices, the system obtains memory usage description files for the target application generated on each of the multiple devices; the memory usage description files are used to describe the memory usage of each program object in the target application. For each device, an analysis thread corresponding to each device is created, and using the analysis thread corresponding to each device, based on the memory usage description file generated for each device, candidate program objects causing the memory exception and the exception types caused by the candidate program objects are determined. Extract the target business code that references the candidate program object from the memory usage description file generated by each device; For each of the aforementioned exception types, the target business code of each candidate program object matching the exception type is aggregated to obtain the occurrence frequency of each candidate program object under the exception type; Based on the frequency of occurrence of each candidate program object under the aforementioned exception type, the target program object to be updated that causes the memory exception is selected. Specifically, for each of the aforementioned exception types, the aggregation of the target business code of each candidate program object matching the exception type to obtain the occurrence frequency of each candidate program object under the exception type includes: For each of the aforementioned exception types, the target business code of each candidate program object matching the aforementioned exception type is aggregated to obtain the occurrence frequency of each of the aforementioned target business codes; The frequency of occurrence of each target business code is taken as the frequency of occurrence of each candidate program object under the exception type.
2. The method according to claim 1, characterized in that, The exception type includes a first type; the first type is used to indicate that a memory leak has occurred; the memory usage description file includes: release status information of each program object after requesting memory release; The process of determining candidate program objects causing memory anomalies and the types of anomalies caused by these candidate program objects, based on the memory usage description file generated for each device, includes: The program objects in the memory usage description file generated by each device are traversed to obtain the release status information of each program object after a request to release memory; If the release status information indicates that the program object has not been released, the program object is identified as a candidate program object that could cause the memory exception, and the exception type caused by the candidate program object is identified as the first type.
3. The method according to claim 1, characterized in that, The exception type includes a second type; the second type indicates that the first memory space occupied by the candidate program object exceeds a set threshold. The process of determining candidate program objects causing memory anomalies and the types of anomalies caused by these candidate program objects, based on the memory usage description file generated for each device, includes: Based on the memory usage description file generated by each device, at least one reference chain is determined, as well as the first memory space size occupied by each reference chain; each reference chain includes: a first program object, and a second program object directly and / or indirectly referenced by the first program object; The size of the first memory space occupied by each of the aforementioned reference chains is compared with the set threshold. In response to any reference chain occupying a first memory space larger than the set threshold, the first program object in that reference chain is identified as a candidate program object, and the exception type caused by the candidate program object is identified as a second type.
4. The method according to claim 3, characterized in that, The memory usage description file includes: the size of the second memory space occupied by each program object; The determination of at least one reference chain and the first memory space size occupied by each reference chain, based on the memory usage description file generated for each device, includes: The memory usage description file generated by each device is parsed to obtain the reference relationship information corresponding to each program object; Based on the reference relationship information corresponding to each program object, the reference relationship chain is determined, and based on the second memory space size occupied by the first program object and the second program object included in the reference relationship chain, the first memory space size occupied by the reference relationship chain is determined.
5. The method according to claim 1, characterized in that, The process of filtering out the target program objects to be updated that cause the memory exception based on the frequency of occurrence of each candidate program object under the exception type includes: The occurrence frequency of candidate program objects under each exception type is compared with a preset frequency threshold; In response to the occurrence frequency of any candidate program object under each exception type being greater than or equal to the preset frequency threshold, each candidate program object is determined as the target program object; or, In response to the occurrence frequency of any candidate program object under each exception type being greater than or equal to the preset frequency threshold, the total memory space occupied by any candidate program object is determined; in response to the total memory space occupied by any candidate program object being greater than the preset memory space threshold, any candidate program object is determined as the target program object.
6. The method according to claim 1, characterized in that, Extracting the target business code that references the candidate program object from the memory usage description file generated from each device includes: Extract the first line of business code from the business code of each candidate program object from the memory usage description file generated by each device; The first line of business code is used as the target business code that references the candidate program object.
7. A memory anomaly attribution device, characterized in that, include: The acquisition module is used to acquire memory usage description files of the target application generated by the multiple devices respectively in response to a memory exception that occurs during the operation of the target application deployed on multiple devices; the memory usage description files are used to describe the memory usage of each program object in the target application. The determination module is used to create an analysis thread corresponding to each device for each device, and use the analysis thread corresponding to each device to determine the candidate program object that causes the memory exception and the exception type caused by the candidate program object based on the memory usage description file generated by each device. An extraction module is used to extract target business code that references the candidate program object from the memory usage description file generated by each device; An aggregation module is used to aggregate the target business code of each candidate program object matching the exception type for each exception type, so as to obtain the occurrence frequency of each candidate program object under the exception type. The filtering module is used to filter out the target program object to be updated that causes the memory exception based on the frequency of occurrence of each candidate program object under the exception type. The aggregation module is further configured to aggregate the target business code of each candidate program object matching the exception type for each exception type, and obtain the occurrence frequency of each target business code; and use the occurrence frequency of each target business code as the occurrence frequency of each candidate program object under the exception type.
8. A computer device, characterized in that, include: The computer device includes a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and the processor communicates with the memory via the bus when the computer device is running, and the machine-readable instructions, when executed by the processor, perform the steps of the memory anomaly attribution method as described in any one of claims 1 to 6.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the memory anomaly attribution method as described in any one of claims 1 to 6.