A JVM heap memory optimization method, device and electronic equipment

Abstract

The application provides a JVM heap memory optimization method and device and electronic equipment. When an allocation object operation exists in the heap memory, an object callback event is triggered in response to the allocation object operation, call stack information and object tracking information of the allocation object are obtained and recorded, the survival state of each object in the heap memory is determined according to the object tracking information and weak reference attribute information created for the allocation object, and then the call stack information of the survival state is the same and the object type of several target objects is the same. After data compression processing, the compressed data is displayed in the user interaction interface through the multi-dimensional aggregation display mode. It can help users understand the specific use of the current heap memory, facilitate users to adjust the use of the heap memory according to the display result, thereby reducing the problem of software performance decline or crash caused by the heap memory problem.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer software, and particularly relates to a JVM heap memory optimization method and device and electronic equipment. BACKGROUND

[0002] In the field of computer science and software engineering, the running efficiency, response speed or resource utilization of software is improved by adjusting code, system design or resource configuration, so that the software can complete the running task in a shorter time and consume less resources. In the field of Java software development, JVM (Java Virtual Machine) is the core environment for running Java programs, which is responsible for translating Java bytecode (.class) into machine execution that can be executed by a specific operating system.

[0003] JVM heap memory is the core area for storing object instances in the Java virtual machine, and JVM heap memory is a memory space shared by all Java threads. Therefore, the reasonable use of JVM heap memory will directly affect the running efficiency of each Java thread. That is, how to monitor, analyze and optimize the use of JVM heap memory is the key to ensure that the application program will not be caused by memory problems to cause software performance degradation or crash during running. SUMMARY

[0004] Therefore, the embodiments of the present application provide a JVM heap memory optimization method and device and electronic equipment to monitor and analyze the use of JVM heap memory, so as to ensure that the application program will not be caused by memory problems to cause software performance degradation or crash during running.

[0005] In a first aspect, the embodiments of the present application provide a JVM heap memory optimization method, and the method comprises the following steps:

[0006] In response to an allocation object operation in the heap memory, triggering an object callback event, obtaining and recording the call stack information and object tracking information of the allocated object; wherein the allocation object operation comprises: creating weak reference attribute information for the allocated object, the call stack information comprises: the code path when the allocated object is created; and the object tracking information comprises: the object type of the allocated object;

[0007] According to the object tracking information and the weak reference attribute information, the survival state of each object in the heap memory is determined.

[0008] If there are several target objects with the same call stack information and the same object type in the survival state, data compression processing is performed on each target object, and the compressed data is displayed in the user interaction interface in a multi-dimensional aggregation display manner.

[0009] In a second aspect, the embodiments of the present application provide a JVM heap memory optimization device, wherein the device comprises:

[0010] An event triggering module is configured to trigger an object callback event in response to an allocation object operation in the heap memory, and acquire and record call stack information and object tracking information of the allocated object, wherein the allocation object operation comprises creating weak reference attribute information for the allocated object, the call stack information comprises a code path when the allocated object is created, and the object tracking information comprises an object type of the allocated object.

[0011] A survival analysis module is configured to determine survival states of each object in the heap memory according to the object tracking information and the weak reference attribute information.

[0012] A compression display module is configured to, if there are several target objects with the same call stack information and the same object type in the survival state, perform data compression processing on each target object, and display the compressed data in the user interaction interface in a multi-dimensional aggregation display manner.

[0013] In a third aspect, the embodiments of the present application provide an electronic device, wherein the electronic device comprises a processor and a memory storing a program, and the program comprises instructions which, when executed by the processor, cause the processor to perform the JVM heap memory optimization method of the first aspect.

[0014] In a fourth aspect, the embodiments of the present application provide a non-transitory computer readable storage medium storing computer instructions, and the computer instructions are used to cause a computer to perform the JVM heap memory optimization method of the first aspect.

[0015] The beneficial effects of the present application are as follows:

[0016] The present application provides a JVM heap memory optimization method, device and electronic device. When there is an allocation object operation in the heap memory, an object callback event is triggered in response to the allocation object operation, call stack information and object tracking information of the allocated object are acquired and recorded, then survival states of each object in the heap memory are determined according to the object tracking information and weak reference attribute information created for the allocated object, then several target objects with the same call stack information and the same object type in the survival state are subjected to data compression processing, and the data subjected to the compression processing is displayed in the user interaction interface in a multi-dimensional aggregation display manner.

[0017] By selecting the embodiment of the present application, the specific use of the object in the heap memory is efficiently monitored through the object callback event, the survival state of the object in the heap memory is analyzed, and then the objects with the same call stack information and object type information are compressed and aggregated in multiple dimensions to be displayed to the user, which can help the user to understand the specific use of the current heap memory, facilitate the user to adjust the use of the heap memory according to the display result, and thus reduce the problem of software performance decline or crash caused by the heap memory problem. BRIEF DESCRIPTION OF DRAWINGS

[0018] In the following description of the exemplary embodiments in conjunction with the drawings, more details, features and advantages of the present application are disclosed, in which:

[0019] Figure 1 A flowchart of a JVM heap memory optimization method provided by the present application is shown;

[0020] Figure 2 Another flowchart of a JVM heap memory optimization method provided by the present application is shown;

[0021] Figure 3 A flowchart of call stack compression aggregation in a JVM heap memory optimization method provided by the present application is shown;

[0022] Figure 4 A logical structure diagram of a JVM heap memory optimization device provided by the present application is shown;

[0023] Figure 5 A structural block diagram of an exemplary electronic device capable of implementing the embodiments of the present application is shown. DETAILED DESCRIPTION

[0024] Embodiments of the present application will be described in more detail below with reference to the accompanying drawings. Although some embodiments of the present application are shown in the drawings, it should be understood that the present application can be implemented in various forms, and should not be interpreted as being limited to the embodiments set forth herein, but rather these embodiments are provided to more thoroughly and completely understand the present application. It should be understood that the drawings and embodiments of the present application are for exemplary purposes only, and are not intended to limit the scope of protection of the present application.

[0025] It should be understood that each step described in the method embodiments of the present application can be executed in different order and / or in parallel. In addition, the method embodiments can include additional steps and / or omit the execution of the steps shown. The scope of the present application is not limited in this respect.

[0026] The term "include" and variations thereof, as used in this document, means "to include, without limitation." The term "based on" means "based at least in part on." The term "one embodiment" means "at least one embodiment." The term "another embodiment" means "at least one additional embodiment." The term "some embodiments" means "at least some embodiments." Related terms shall be construed accordingly. It should be noted that "a" or "an" entity as used herein means "one or more" entities. The terms "first," "second," and the like as used in this document do not imply a quantity or order, but rather are used to distinguish different entities.

[0027] It should be noted that the terms "one" and "a" or "an" as used herein mean "one or more" unless expressly stated otherwise. The terms "first," "second," and the like as used in this document do not imply a quantity or order, but rather are used to distinguish different entities.

[0028] In a first aspect, the present application provides a JVM heap memory optimization method. The method is applied to any electronic device with JVM heap memory optimization function, including but not limited to personal mobile terminal, computer or server, etc. As shown in the figure, the method includes the following steps: Figure 1

[0029] S11, in response to the allocation object operation in the heap memory, triggering the object callback event, obtaining and recording the call stack information and object tracking information of the allocated object; wherein the allocation object operation includes creating weak reference attribute information for the allocated object, the call stack information includes the code path when the allocated object is created, and the object tracking information includes the object type of the allocated object;

[0030] S12, determining the survival state of each object in the heap memory according to the object tracking information and the weak reference attribute information;

[0031] S13, if there are several target objects with the same call stack information and the same object type in the survival state, performing data compression processing on each target object, and displaying the compressed data in the user interaction interface through multi-dimensional aggregation display.

[0032] When there is an allocation object operation in the heap memory, in response to the allocation object operation, triggering the object callback event, obtaining and recording the call stack information and object tracking information of the allocated object, then determining the survival state of each object in the heap memory according to the object tracking information and the weak reference attribute information created for the allocated object, and then performing data compression processing on several target objects with the same call stack information and the same object type in the survival state, and displaying the compressed data in the user interaction interface through multi-dimensional aggregation display. ​

[0033] By selecting the embodiments of the present application, the specific use of objects in the heap memory is efficiently monitored through the object callback event, the survival state of the objects in the heap memory is analyzed, and then the objects with the same call stack information and object type information are compressed and displayed to the user in multiple dimensions, which can help the user to understand the specific use of the current heap memory, facilitate the user to adjust the use of the heap memory according to the display result, and thus reduce the problem of software performance degradation or crash caused by the heap memory problem.

[0034] The above steps S11-S13 will be described in detail below with specific examples:

[0035] In the present application, the heap memory is a core memory area for dynamically allocating object instances of a Java program at runtime. During the development and operation of the Java program, all objects created through the keyword new are stored in the heap memory. Among them, the objects in the heap memory refer to the data entities instantiated by classes in the heap memory, that is, the "object" refers to the instance created in the heap memory at runtime of the Java program, which is specifically instantiated by the Class. For example, in the Java program statement: String str = new String ("example"), "example" is an object instance created in the heap memory by the String class. Among them, the types of objects include, for example, String, List, custom class instances, etc.

[0036] This description is slightly abstract. In order to facilitate understanding, the heap memory can be understood as a giant express sorting center, and the packages needed to be sorted and processed every day can be understood as Java objects. In the embodiments of the present application, the heap memory can be automatically managed by JVM, without manual allocation or release of memory, which can be understood as that the automatic sorting device can realize the sorting and delivery in the express sorting center.

[0037] The allocation object operation in the heap memory refers to the process of creating a new object instance in the heap memory by the user or the program. Specifically, when the application program executes the new operation, the JVM will automatically allocate objects in the heap memory. Based on this, the allocation object operation in the heap memory can be simply understood as the execution of the new operation by the application program, at which time the JVM will perform the following steps:

[0038] 1) Allocate memory space for the new operation. Find a continuous space in the heap memory to store the data of the object instance, wherein the data of the object instance includes: field value, type information, etc.

[0039] 2) Initialize the object for the new operation by calling the constructor function to initialize the state of the object.

[0040] 3) return reference. Specifically, the address information of the allocated memory space can be returned to a variable. For example, the memory space can be returned to the variable obj through object obj = new object().

[0041] In this process, as an implementation, step S11 is performed to trigger an object callback event, which can be a JVMTI (Java Virtual Machine Tool Interface, a native interface for monitoring and managing the behavior of JVM) event. Through the object callback event, the call stack information and object tracking information of the allocated object are obtained.

[0042] As an implementation, step S11 can be implemented through the following steps:

[0043] If it is detected that a thread allocates an object in the heap memory, a SampledObjectAlloc event is triggered, and object tracking information generated during the allocation of the object is sampled and recorded according to a dynamic sampling interval. The object tracking information includes the ID of the target thread that allocates the object, the object class name of the allocated object, the size of the allocated object, the class ID of the allocated object, and the stack frame information of the target thread.

[0044] Specifically, when it is detected that a thread allocates an object in the heap memory, the object tracking information of the allocated object can be obtained through the SampledObjectAlloc event in the JVMTI event. The entire process of obtaining the object tracking information through the JVMTI event can be simply understood as sampling the allocation of the object. In combination with the above example of express sorting, the JVMTI event can be understood as an intelligent monitoring device installed in the sorting center. When the sorter B (equivalent to the thread B) puts a refrigerator package into the sorting center, the intelligent monitoring device detects the action of putting the refrigerator package and then triggers the recording of various information of the refrigerator package, including the call stack information and the tracking information.

[0045] In the embodiments of the present application, the process of sampling the allocation of the object is to record the allocation information of the allocated object, which includes the size of the object, the allocated stack information, and some other related information. The specific implementation steps include the following steps 1 to step 4:

[0046] Step 1: Initialize sampling configuration. Specifically, in the ObjectSampler::recordAllocation method, it first checks whether allocation events need to be recorded. This is determined by whether _gc_generations, _record_allocations, and _record_liveness are true. If all three flags are false, the method returns without performing any action.

[0047] The _gc_generations flag controls whether to enable GC generation-based tracking of live objects. JVM garbage collection typically uses a generational collection mechanism (e.g., young generation, old generation), with different object survival periods. If _gc_generations is true, it indicates that the generation of objects that survive multiple GCs (e.g., whether an object survives generation 1, generation 2, etc.) needs to be recorded. This is combined with weak references (jweaks) and GC events to determine whether an object survives multiple collections.

[0048] The _record_allocations flag is used to control whether to record detailed information about object allocation events. If _record_allocations is true:

[0049] When an object is allocated, the following actions are triggered: Profiler::instance()->recordExternalSample() is called to record the allocation event. Information such as the object's call stack, thread ID, object class name, and size are saved. Specifically, the call stack hash value (which uniquely identifies the code path), the number of allocations for the object, the total size of the object, and the timestamps of the first and last allocations are recorded.

[0050] If _record_allocations is false, the object allocation recording process is skipped.

[0051] The _record_liveness flag controls whether to track and record object liveness. If _record_liveness is true, the liveness tracker is called when an object is allocated. Specifically, the LivenessTracker::instance()->track() method in the liveness tracker is called. This method creates a weak reference (jweak) for the object, tracks its liveness across multiple GCs, and checks whether the object has been collected using env->IsSameObject().

[0052] If _record_liveness is false, the object liveness tracking process is skipped.

[0053] Step 2: Obtain the ID of the current thread, which is the thread that allocates the object. Specifically, the thread ID of the current thread can be obtained by using ProfiledThread::currentTid(). The thread ID is used to identify the source thread of the allocation event, facilitating subsequent analysis and sampling.

[0054] Step 3: Obtain the class name and find the class ID, where the class name is the class name of the allocated object. Specifically, the signature of the class of the allocated object can be obtained by using jvmti->GetClassSignature, and the class ID can be found according to the class signature. If the search fails (i.e., the return value is -1), the sampling of the object is skipped directly. If a valid class signature is obtained, the system uses the class signature to find the ID of the class, and then stores the ID in the AllocEvent structure.

[0055] Step 4: Collect stack frame information. When it is necessary to record the stack information of object allocation, jvmti->GetStackTrace is called to obtain the stack frame information of the current thread. The frames array is used to store the stack information, and each stack frame contains method, class, and other information. frames_size indicates the number of stack frames. If the stack information fails to be obtained (for example, the return value is JVMTI_ERROR_NONE or the number of stack frames is 0), the allocation information of the object is not recorded.

[0056] In the embodiments of the present application, sampling refers to dynamically monitoring the allocation of JVM heap memory objects, and the core goal is to capture the allocation information of key objects with a low performance overhead, to assist in analyzing the problem of high occupation of heap memory or memory leakage. When an object is allocated in the heap memory by a thread, i.e., when the new operation is generated, the sampling logic can be triggered immediately. Specifically, the SampleObjectAlloc event callback mechanism in JVMTI can be used to obtain the following information when the object is allocated:

[0057] The object class name (such as java.util.HashMap), the object size (the number of bytes of heap memory occupied), the thread ID (the thread identifier that allocates the object), and the call stack (the allocation path, such as Main.run()→Service.process()→new HashMap()).

[0058] In the embodiments of the present application, the process of sampling the object tracking information of the allocated object can be sampling at a fixed sampling interval, or sampling at a dynamic sampling interval. The dynamic sampling interval can be understood as a sampling scheme that intelligently controls the sampling frequency. The dynamic sampling interval can be determined in the following way:

[0059] determining a weight of the allocated object according to a size of the allocated object;

[0060] determining a pseudo-random sampling interval for the allocated object based on the weight of the allocated object, and determining the pseudo-random sampling interval as a new dynamic sampling interval of the allocated object.

[0061] Specifically, the pseudo-random sampling interval can be set by a SetHeapSamplingInterval method and dynamically adjusted based on an average size of historical allocated objects. The weight of the object can be calculated by the following formula:

[0062]

[0063] wherein size is the size of the object, and interval is a reference sampling interval, which can be dynamically adjusted based on an average size of historical allocated objects. For a large object with a larger size, the weight value is higher, and the corresponding sampling probability is higher. For a small object with a smaller size, the weight value is lower, and the sampling probability is lower.

[0064] In the embodiments of the present application, the stack trace information is a method call chain recorded by a program during running, reflecting a code execution path when an object is allocated. Based on this, the stack trace information includes a code path when the allocated object is created, specifically a code execution path when the object is allocated. The functions of the stack trace information include locating an allocation source and thread association. The locating of the allocation source refers to that when an object is allocated in a heap memory, the stack trace records all method call levels from a program entry (such as main()) to a position where the object is created. The thread association is to record a thread ID by the stack trace information, used to determine which thread allocates the object.

[0065] The tracking data of the object is monitoring data for a life cycle (from allocation to recycling) of the allocated object, which can be used to analyze a survival state of the object and a use mode of the heap memory by the minute information of the object. As an implementation, the tracking data of the object includes an ID of a target thread of the allocated object, an object class name of the allocated object, an object size of the allocated object, a class ID of the allocated object, and stack frame information of the target thread.

[0066] In the embodiments of the present application, the stack trace information can be understood as a "map of object allocation", and the code path in the stack trace information can be used to accurately locate a problem source. The tracking information can be understood as a "medical record of object survival", and the life cycle data of the tracking information can be used to diagnose a health state of the heap memory.

[0067] In the JVM heap memory, each object can be automatically recycled by a garbage collector, releasing the content occupied by an unreferenced object (which can be regarded as garbage) to improve the memory usage of the heap memory. In the process of performing step S11, weak reference attribute information can be created for the allocated object. The weak reference attribute information refers to a special reference type in Java, Weak Reference. If an object has weak reference attribute information, the garbage collector will not recycle the object, that is, the weak reference attribute information will not prevent the garbage collector from recycling the object to which it applies. Even if the weak reference exists, as long as the object has no strong reference or other strong reachable path, the garbage collector will automatically recycle the object at runtime. That is, the weak reference only provides a path to access the object, but does not protect the object from being recycled by the garbage collector GC.

[0068] Based on this, in some possible embodiments, step S12 is performed to determine the survival state of each object in the heap memory according to the object tracking information and the weak reference attribute information. Specifically, step S12 can be implemented by the following steps:

[0069] calling a survival tracker and passing the object tracking information to the survival tracker, and using the survival tracker to determine whether the input object is still alive based on the weak reference attribute information;

[0070] if the input object is still alive after multiple garbage collections, using the survival tracker to report the call stack information of a potential leak object, wherein the potential leak object is an object that is still alive after multiple garbage collections;

[0071] if the survival state includes several target objects with the same call stack information and the same object type, the method comprises:

[0072] determining each potential leak object with the same call stack information and the same object type as each target object.

[0073] In the embodiments of the present application, the survival tracker is LivenessTracker, which is a core module for tracking the survival state of objects in the JVM heap memory. Specifically, it identifies potential memory leaks by determining whether an object has not been recycled after multiple recycling. When an object is allocated in a thread, the JNI() will automatically trigger the creation of a weak reference (jwaek) for the allocated object and store the weak reference in the survival tracker LivenessTracker. For example, a weak reference is created by the following code:

[0074] jWeak weakRef = env->NewWeakGlobalRef(obj); / / create weak reference

[0075] Then the garbage collector will traverse all the weak references each time it performs a garbage collection check to check whether the object referenced by the weak reference is alive. As an example, the object is traversed to determine whether the object is alive by the following way:

[0076]

[0077] If the object is still alive after N times of garbage collection, such as after 3 times of garbage collection, the object can be marked as a potential leak object, and the potential leak object needs to be reported.

[0078] In some possible embodiments, the method further comprises:

[0079] The object tracking information is passed and recorded into the live tracker, and the stack frame information of the object is released.

[0080] Specifically, if the_record_allocations flag is true, a set algorithm Profiler::instance() is called, and Profiler::instance()->recordExternalSample is used to record the object allocation event. In this way, the object allocation information (such as object size, stack frame, etc.) can be saved to the sampling data.

[0081] When recording, the allocation event counter_alloc_event_count can also be updated, and the sampling configuration can be updated according to the number of sampling events and the time period. If the configuration update time period exceeds a certain threshold (which can be flexibly set according to actual experience, and is configured by CONFIG_UPDATE_CHECK_PERIOD_SECS), the sampling strategy is updated.

[0082] Then, the specific live information of the object is recorded. As an implementation, if_gc_generations or_record_liveness is true, the live tracker is called, and the LivenessTracker::instance()->track method is called to pass the object allocation information to the live tracker LivenessTracker for live tracking. At this time, the allocated object information (including the stack frame) is recorded to the LivenessTracker, which facilitates subsequent analysis of the live state of the object.

[0083] Specifically, after each garbage collection, the Liveness Tracker will actively iterate through all objects in the tracking table, specifically by checking the validity of weak references to determine if an object is alive. As an example, the validity of a weak reference is determined by using the env->IsSameObject(weakRef, nullptr) method in JNI. If a non-null value is returned, the object's age is updated and the last time the object was alive is timestamped. If a null value is returned, the weak reference to the object is deleted and the stack information associated with the object referenced by the weak reference is deleted.

[0084] If the Liveness Tracker finds that an object is still alive after each garbage collection, the object's age (i.e., the number of times the object has undergone garbage collection) is incremented by 1. If the number of times the object has undergone garbage collection exceeds a set threshold, the object can be marked as a potential leak object, and the stack information, class name, and total memory usage of the long-lived object are uploaded for subsequent heap memory analysis.

[0085] Specifically, after each garbage collection (GC) is completed, the Liveness Tracker triggers a cleanup process to iterate through the object information in the tracking table. At this time, the weak reference of each object is checked again:

[0086] If the object is still valid (i.e., not garbage collected), it means that the object is alive, and the Liveness Tracker updates the object's information, increases its "age," and moves it to a new location in the tracking table.

[0087] If the object has been collected, the object's weak reference is cleared, the stack information associated with the object is deleted, and the object is removed from the tracking table.

[0088] Finally, regardless of whether the object's allocation information is recorded, since the Liveness Tracker independently manages the object's allocation information, the object's stack frame information can be cleaned up and the frames array can be released.

[0089] To better understand, assume that an object MyObject is tracked in the following scenarios:

[0090] Allocation phase:

[0091] The call stack A->B->C is recorded at the time of allocation, and a weak reference weakRef_MyObject is created.

[0092] First GC:

[0093] weakRef_MyObject is checked to be valid, and the age is updated to 1.

[0094] Third GC:

[0095] Age accumulated to 3, more than the threshold, report the allocation path and memory occupation of MyObject.

[0096] Developer analysis:

[0097] According to the reported stack information, it is found that MyObject is not released in a certain cache, and the code is repaired.

[0098] In this way, combined with weak references and stack information, false positives can be reduced, and through the implementation of JVMTI, the state analysis of internal objects in the heap memory can be realized without modifying the application code.

[0099] In the embodiments of the present application, the entire process of determining whether the object is alive continues after multiple garbage collections. If an object is not recycled after multiple garbage collections, the survival tracker can consider the object to be alive and retain its stack information. At this time, it can be regarded as a potential leak object or a candidate object that is not released in time. If there are some objects that need to be forcibly cleaned up, the survival tracker can control the need to forcibly clean up the alive objects through the forced parameter. In this way, in the case of excessive resource occupation or high memory occupation, the objects that need to be forcibly cleaned up can be checked and cleaned up.

[0100] Further, after determining the potential leak objects that survive after multiple garbage collections according to the specific survival state of each object, the potential leak objects are classified according to the call stack information and object type, and then the step S13 is executed to divide each potential leak object with the same call stack information and object type into a class of target objects, and then perform data compression processing on the class of target objects, so as to report the data of each target object to the user after data aggregation.

[0101] As an implementation mode, when step S13 is executed, the following steps can be implemented:

[0102] S13-1, extracting the call stack information, timestamp and allocation size of each target object;

[0103] S13-2, determining whether the call stack information of each target object exists in a preset hash table, if it exists, updating the last occurrence timestamp of the corresponding call stack in the preset hash table according to the timestamp of the target object;

[0104] S13-3, and according to the allocation size of the target object, accumulating the allocation size of each target object related to the call stack.

[0105] As another implementation mode, on the basis of the above steps S13-1 to S13-3, when step S13 is executed, the following steps can also be implemented:

[0106] S13-4, if the call stack information of each target object does not exist in the preset hash table, a new entry is created in the preset hash table, the number of allocations is recorded as 1, the first occurrence timestamp and the current timestamp are recorded, and the object allocation size is initialized as the allocation size of the current target object.

[0107] In the embodiments of the present application, the preset hash table is a data table used to summarize and sort the target objects. By using the preset hash table to merge the same call stack information, the effect of merging the same call paths can be achieved, and only the number of allocations and the allocation size need to be accumulated in the preset hash table. In this way, the amount of repeated data can be reduced, and the amount of data stored and transmitted can be compressed.

[0108] Specifically:

[0109] First, the hash table is initialized, and the hash table (dictionary) is used to store the merging information of each unique call stack. The merging information of each unique call stack at least includes: call stack path, allocation count, time period (first and last time stamp), and allocation size accumulated according to object type.

[0110] Further, the sampling data is traversed, and the call stack path, timestamp, object type, and allocation size in the sampling data are extracted. Then, the data is merged according to the following merging logic:

[0111] If the call stack exists, the allocation count of the call stack is increased, the last occurrence timestamp (end_time) is updated, and the allocation size of the same object type is accumulated (such as ClassX total size + = current allocation size). If the call stack does not exist, a new entry is created, the allocation count is recorded as 1, the timestamp and the object type allocation size are initialized.

[0112] Then, the data is merged according to the time, and the time range of the same call stack is merged, and only the first occurrence timestamp is retained, and the intermediate fluctuations are ignored.

[0113] Specifically, the merging process can be operated according to the following steps:

[0114] Extract the call stack, timestamp, and allocation size from each sampling data to extract the call stack, current timestamp, and object allocation size. Merge the call stack: if the call stack already exists in the hash table: increase the allocation count (i.e. the number of occurrences) of the call stack, update the last occurrence timestamp of the call stack, and accumulate the object allocation size related to the call stack. If the call stack does not exist in the hash table: create a new entry in the hash table, record the allocation count as 1, record the first occurrence timestamp and the current timestamp, and initialize the object allocation size as the current object size.

[0115] Merged object allocation size: For each allocated object, record the class to which each object belongs and accumulate the allocation size of objects of the same class. For example, if the same type of object is allocated multiple times in the same call stack, the size of the type of object is accumulated.

[0116] Time merging: For an existing call stack, update its time period. The time period consists of two timestamps:

[0117] First occurrence timestamp: indicates the time when the call stack is first sampled.

[0118] Last occurrence timestamp: indicates the time when the call stack is last sampled.

[0119] Specifically, update the first occurrence timestamp and the last occurrence timestamp.

[0120] After merging, each entry in the hash table will contain the following information:

[0121] a) Call stack: unique identifier.

[0122] b) Allocation frequency: the number of times the call stack appears (i.e., the frequency of object allocation).

[0123] c) Time period: contains the first occurrence timestamp and the last occurrence timestamp.

[0124] d) Allocation size: records the total allocation size of all object instances under the call stack.

[0125] For example, assume the following sampling data shown in Table 1:

[0126] Table 1. A sample data table

[0127] Sample Number Call Stack Timestamp Object Class Allocation Size (bytes) 1 A->B->C t1 = 10 ms Class X 200 2 A->B->C t2 = 20 ms Class X 100 3 A->D->E t3 = 25 ms Class Y 150 4 A->B->C t4 = 30 ms Class X 300 5 A->D->E t5 = 35 ms Class Z 400 6 A->B->C t6 = 40 ms Class X 50

[0128] By the following merging steps, the data in the table can be summarized and merged:

[0129]

[0130]

[0131] Explanation of the above code:

[0132] The "A->B->C" call stack appears 4 times (allocation frequency), first at 10ms and last at 40ms. Under this call stack, the ClassX type of object allocation size is accumulated to 650 bytes.

[0133] The "A->D->E" call stack appears twice (allocation times), the first time at 25 ms and the last time at 35 ms. Under this call stack, objects of ClassY and ClassZ types are allocated 150 bytes and 400 bytes, respectively.

[0134] Further, the merged call stack data will contain call stack, allocation times, time period, and allocation size, etc. In order to further reduce the occupation of network bandwidth, the next step is to compress these data and send them to the backend at fixed time intervals. Specifically, data compression can be achieved by hashing call stack information, numerical encoding optimization, and data block compression. Among them, the call stack information hashing can be to convert the call stack path into a hash value, which can reduce the repeated transmission of strings. Numerical encoding optimization can be to use compact numerical encoding, such as Varint to store allocation times, timestamps, and allocation size. Then, the merged data block (such as hash table entries) is compressed using general compression algorithms such as Gzip compression algorithm and Snappy compression algorithm. Among them, the data is compressed into the simplest form, for example, the hash value of each call stack plus its allocation times, timestamp range, and object type allocation size.

[0135] The above process can be understood in combination with the flow table as shown in Figure 2

[0136] Initialize the hash table `call_stack_map`, each entry contains: call stack, allocation times (times), time period (first occurrence and last occurrence timestamp), and allocation size (cumulative by class).

[0137] Then, traverse the sampling data, extract the current sampling call stack, timestamp, object type, and allocation size.

[0138] Then, check if the call stack exists. If the call stack exists, increase the allocation times and update the last timestamp, and accumulate the allocation size of the object type. If the call stack does not exist, insert it into the hash table, record the allocation times as 1, the timestamp as the current sampling time, and initialize the allocation size of the object type.

[0139] After merging is completed, the call stack data is sorted and filtered. After merging is completed, each entry in the hash table will contain: call stack, allocation times (times), time period (first occurrence and last occurrence timestamp), and total allocation size of each object type. According to the needs, these information is sorted, filtered (such as sorting by allocation times or filtering according to time range) to achieve data compression, and is reported to the backend regularly, so that the backend can be analyzed and monitored.

[0140] ​On the basis of the steps S13-1 to S13-4, the compressed data is aggregated in multiple dimensions by the following steps:

[0141] Based on the information recorded in the preset hash table, the data after aggregation is displayed in the form of a chart in the user interaction interface after aggregation in a target aggregation manner, wherein the target aggregation manner includes one or more of time window aggregation, call stack information level merging, live object aggregation, and dimension merging.

[0142] Specifically, multi-dimensional aggregation display can realize data aggregation in multiple dimensions, so that the user can analyze the heap memory according to the aggregated data. Among them, based on the information recorded in the preset hash table, one or more of time window aggregation, call stack level merging, live object aggregation, and dimension merging is used for aggregation, and the specific aggregation manner can be set by the user.

[0143] The specific processing flow can be as shown in Figure 3 First, collect data, and then aggregate the collected data in the time window aggregation, call stack path aggregation, and object type aggregation manner. For time window aggregation, the data can be aggregated according to the time window, and the time window data can be merged. For call stack path aggregation, the data can be aggregated according to the call stack path, and the call stack path data can be merged. For object type aggregation, the data can be aggregated according to the object type, and the object type data can be merged. Further, the time window and the call stack path are merged into larger granularity data display, which can be summarized according to the day, and then classified according to the class and the call stack path, and finally the time, object type, call stack allocation times, and size are displayed to the user.

[0144] The time window aggregation can be understood as merging data according to a fixed time window, such as every minute or every hour, to display the heap memory situation every minute or every hour. The data can be segmented according to the timestamp, and the data in the same time window can be merged into a data point, thereby reducing the amount of data displayed. The specific implementation process can be:

[0145] The data in each time window is merged to calculate the total allocation times, total allocation size, and average allocation size in the time window.

[0146] The aggregated statistical data of the time window is generated, such as the total allocation size per minute, the allocation times per hour, and the number of live objects per hour.

[0147] For example, assuming that data is reported once per minute, the data can be summarized by hour, and then the hourly summary result can be as shown in Table 2:

[0148] Table 2. A time window aggregation table

[0149] Time Window Total Allocation Count Total Allocation Size (MB) Surviving Object Count 2024-12-24 00:00-00:59 3500 240 900 2024-12-24 01:00-01:59 3000 210 850 2024-12-24 02:00-02:59 2900 195 830 2024-12-24 03:00-03:59 3200 215 860

[0150] In which, the call stack level merging can be understood as merging the call stacks of the same path, and the allocation frequency and total size are counted. The objects with the same call stack path are merged, and the aggregation is performed according to the level of the call stack path. The same type of call stack can be merged according to the path and level of the call stack, thereby reducing the number of call stacks displayed. The specific implementation process can be:

[0151] Based on the different levels of the call stack, the call stacks of the same path are merged. The total allocation times, allocation size, and the number of live objects of each call stack path are counted.

[0152] If necessary, the call stack path can be displayed according to the level, and the call stack information and related data of each level are displayed.

[0153] Exemplarily, for each time period, the object allocation of the same call stack path can be merged as shown in Table 3 below:

[0154] Table 3. A call stack level merging table

[0155] Call Stack Path Allocation Count Total Allocation Size (MB) A->B->C 2500 160 A-D 1500 130 A->C->D 1000 85 A->B->D 800 50

[0156] The above is the object allocation after merging according to different methods (call stack paths), which indicates that the method is called multiple times, and the merged allocation times and allocation size.

[0157] In which, the live object aggregation can be understood as counting the memory occupation according to the object type, such as sting and arraylist. By analyzing the number of live objects and their memory allocation, a summary report of the live objects is generated. By aggregating the live data of each object type in a time period, the distribution of live objects in the entire system is displayed. The specific implementation process can be:

[0158] According to the time and allocation times of the object survival, the number of objects surviving in a certain period of time, the average allocation size of the live objects, and the like are counted.

[0159] The survival of different types of objects in different time periods is displayed, and the data is summarized.

[0160] Exemplarily, for the allocation of each object type, the summary can be performed according to Table 4 as shown below:

[0161] Table 4. A live object aggregation table

[0162] Object Type Allocation Count Total Allocation Size (MB) Surviving Object Count java.lang.String 1800 120 500 java.lang.Integer 1200 80 350 com.example.MyClass 1000 70 300 java.util.ArrayList 700 50 250

[0163] wherein the dimension merging can be understood as a mixed dimension display, combining time, call stack, object type to generate a comprehensive report. Different dimensions (such as threads, classes, methods, etc.) are merged and displayed, and object allocation, call stack and memory usage are displayed according to different dimensions. The memory usage of different threads, classes or methods can be analyzed by grouping. The specific implementation process is as follows:

[0164] Grouping and merging data of different dimensions, and counting the total allocation times and memory size in each dimension.

[0165] Displaying the merged statistical data under different dimensions to facilitate the identification of differences between different dimensions.

[0166] Exemplarily, a time window + call stack merging + object type merging method can be used for mixed aggregation, which can be shown in Table 5 as follows:

[0167] Table 5. A mixed dimension merging table:

[0168]

[0169] The above aggregation processes can be realized by the following steps:

[0170] In the data storage layer, first, store the sampled data into the backend database, and index according to the dimensions of time stamp, call stack, object type, etc. to facilitate efficient query and aggregation.

[0171] Then, in the data aggregation layer (which is above the data storage layer), build a data aggregation module to aggregate data through multiple dimensions such as time window, call stack level and object type. MapReduce, SQL aggregation function or streaming processing framework can be used to complete data merging and calculation.

[0172] Finally, the aggregation result is displayed on the data display layer. Specifically, display the summary information of large granularity, such as the total allocation size in each time window, the allocation times of each object type, the number of surviving objects, etc. Charts (such as line charts, column charts, etc.) and tables can be used to display the aggregated data. Periodic reporting: according to the set time interval (such as every hour, every day, etc.), generate periodic reports to display the summary data of large granularity.

[0173] Exemplarily, the data display can be more aggregated and concise, as shown in Table 6, which can summarize the data by day and classify them according to object type and call stack path:

[0174] Table 6. A merged display table

[0175]

[0176] These combined display strategies help aggregate memory allocation data from multiple dimensions in different ways, reducing data redundancy and enabling developers to more clearly understand the overall memory allocation situation, call stack distribution, and memory usage by object type. These methods effectively reduce the granularity of data display while providing more valuable information.

[0177] Through the above method, data merging and display can effectively reduce storage and display overhead, while providing more granular and dimensional information to help developers quickly locate memory usage issues.

[0178] In a second aspect, the present application provides a JVM heap memory optimization device, wherein, Figure 4 As shown, the device 40 includes:

[0179] The event triggering module 401 is configured to trigger an object callback event in response to an object allocation operation in heap memory, and obtain and record call stack information and object tracking information of the allocated object; wherein the object allocation operation includes: creating weak reference attribute information for the allocated object; the call stack information includes: the code path when the allocated object is created; and the object tracking information includes: the object type of the allocated object;

[0180] A survival analysis module 402 is configured to determine the survival status of each object in the heap memory based on the object tracking information and the weak reference attribute information;

[0181] The compression display module 403 is used to perform data compression processing on each target object if there are several target objects with the same call stack information and the same object type in the survival state, and display the compressed data in the user interaction interface through multi-dimensional aggregation display.

[0182] In conjunction with the second aspect, in a second possible embodiment, the event triggering module is further configured to:

[0183] If it is monitored that a thread allocates an object in the heap memory, a SampledObjectAlloc event is triggered, and object tracking information generated during the object allocation process is sampled and recorded according to a dynamic sampling interval; wherein the object tracking information includes: the ID of the target thread that allocates the object, the object class name of the allocated object, the size of the allocated object, the class ID of the allocated object, and the stack frame information of the target thread.

[0184] In conjunction with the second aspect, in some possible embodiments, the event triggering module is further configured to:

[0185] Determining a weight of the allocated object according to the size of the allocated object;

[0186] determining a pseudo-random sampling interval for the allocated object based on the weight of the allocated object, the pseudo-random sampling interval being determined as a new dynamic sampling interval for the allocated object.

[0187] In some possible embodiments, the survival analysis module is further configured to:

[0188] invoke a survival tracker and pass the object tracking information into the survival tracker, and determine, based on the weak reference attribute information, whether the input object is still alive by using the survival tracker;

[0189] if the input object is still alive after multiple garbage collections, report call stack information of a potential leak object by using the survival tracker, wherein the potential leak object is an object that is still alive after multiple garbage collections;

[0190] if the survival state includes a plurality of target objects that have the same call stack information and the same object type, the method further includes:

[0191] determining each potential leak object that has the same call stack information and the same object type as each of the target objects.

[0192] With reference to the second aspect, in some possible embodiments, the compression display module is further configured to:

[0193] extract call stack information, a timestamp, and an allocation size of each of the target objects;

[0194] determine whether the call stack information of each of the target objects exists in a preset hash table, and if so, update a last occurrence timestamp of the call stack in the preset hash table according to the timestamp of the target object;

[0195] and according to the allocation size of the target object, accumulate the allocation size of each target object related to the call stack.

[0196] With reference to the second aspect, in some possible embodiments, the compression display module is further configured to:

[0197] if the call stack information of each of the target objects does not exist in the preset hash table, create a new entry in the preset hash table, record an allocation number of 1, and record a first occurrence timestamp and a current timestamp, and initialize an object allocation size as the allocation size of the current target object.

[0198] With reference to the second aspect, in some possible embodiments, the compression display module is further configured to:

[0199] Based on the information recorded in the preset hash table, after aggregation in a target aggregation manner, the aggregated data is displayed in a chart manner in the user interaction interface, wherein the target aggregation manner includes one or more of time window aggregation, call stack information level merging, live object aggregation, and dimension merging.

[0200] In the present application, the collection, storage, use, processing, transmission, provision and disclosure of user personal information comply with relevant laws and regulations and do not violate public order and good customs.

[0201] The names of the messages or information exchanged between the plurality of devices in the embodiments of the present application are only for illustrative purposes, and are not intended to limit the scope of the messages or information.

[0202] In a third aspect, the example embodiments of the present application also provide an electronic device, comprising: at least one processor; and a memory communicatively connected with the at least one processor. The memory stores a computer program capable of being executed by the at least one processor, and the computer program, when executed by the at least one processor, is configured to cause the electronic device to perform the method according to the embodiments of the present application.

[0203] The example embodiments of the present application also provide a non-transitory computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor of a computer, is configured to cause the computer to perform the method according to the embodiments of the present application.

[0204] The example embodiments of the present application also provide a computer program product comprising a computer program, wherein the computer program, when executed by a processor of a computer, is configured to cause the computer to perform the method according to the embodiments of the present application.

[0205] Reference Figure 5 A block diagram of an electronic device 500, which can be used as the server or client of the present application, will now be described, which is an example of a hardware device that can be applied to various aspects of the present application. The electronic device is intended to represent a wide variety of digital electronic computing devices, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computing devices. The electronic device can also represent a wide variety of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown here, their connections, and their functions, are meant to be examples only, and are not intended to limit the implementations of the present application described and / or claimed herein.

[0206] As Figure 5As shown, the electronic device 500 includes a computing unit 501 that can perform various appropriate actions and processes in accordance with a computer program stored in a read-only memory (ROM 502) or a computer program loaded into a random access memory (RAM 503) from a storage unit 508. In the RAM 503, various programs and data required for the operation of the electronic device 500 can also be stored. The computing unit 501, the ROM 502, and the RAM 503 are connected to each other through a bus 504. An input / output interface (I / O interface 505) is also connected to the bus 504.

[0207] A plurality of components in the electronic device 500 are connected to the I / O interface 505, including an input unit 506, an output unit 507, a storage unit 508, and a communication unit 509. The input unit 506 can be any type of device that can input information to the electronic device 500, and can receive inputted numerical or character information, as well as generate key signal inputs related to user settings and / or function controls of the electronic device. The output unit 507 can be any type of device that can present information, and can include, but is not limited to, a display, a speaker, a video / audio output terminal, a vibrator, and / or a printer. The storage unit 508 can include, but is not limited to, a magnetic disk, an optical disk. The communication unit 509 allows the electronic device 500 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks, and can include, but is not limited to, a modem, a network card, an infrared communication device, a wireless communication transceiver, and / or a chipset, such as a Bluetooth™ device, a WiFi device, a WiMax device, a cellular communication device, and / or the like.

[0208] The computing unit 501 can be various general and / or special purpose processing components having processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The computing unit 501 performs various methods and processes described above. For example, in some embodiments, the aforementioned JVM heap memory optimization method can be implemented as a computer software program tangibly embodied in a machine-readable medium, such as the storage unit 508. In some embodiments, part or all of the computer program can be loaded and / or installed onto the electronic device 500 via the ROM 502 and / or the communication unit 509. In some embodiments, the computing unit 501 can be configured to perform the aforementioned JVM heap memory optimization method by any other appropriate means, such as by means of firmware.

[0209] The program code for implementing the methods of the present application can be written in any combination of one or more programming languages. Such program code can be provided to a processor or controller of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that when the program code is executed by the processor or controller, the functions / operations specified in the flow charts and / or block diagrams are implemented. The program code can be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0210] In the context of the present application, a machine-readable medium can be a tangible medium that can contain or store a program for use by an instruction execution system, device or equipment or used in combination with an instruction execution system, device or equipment. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared or semiconductor system, device or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium can include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0211] As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, apparatus, and / or device (e.g., a magnetic disk, an optical disk, a memory, a programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

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

[0213] The systems and techniques described here can be implemented in a computing system that includes a back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a user computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet.

[0214] The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

Claims

1. A method for JVM heap memory optimization, the method comprising: The method comprises: ​ In response to an allocation object operation in the heap memory, triggering an object callback event, obtaining and recording the call stack information and object tracking information of the allocated object; wherein the allocation object operation comprises: creating weak reference attribute information for the allocated object, the call stack information comprises: the code path when the allocated object is created, and the object tracking information comprises: the object type of the allocated object; According to the object tracking information and the weak reference attribute information, determining the survival state of each object in the heap memory; If there are several target objects with the same call stack information and the same object type in the survival state, performing data compression processing on each target object, and displaying the compressed data in the user interaction interface through the way of multi-dimensional aggregation display; According to the object tracking information and the weak reference attribute information, determining the survival state of each object in the heap memory, comprising: Calling the survival tracker and passing the object tracking information to the survival tracker, and using the survival tracker to determine whether the input object is still alive based on the weak reference attribute information; If the input object still survives after multiple garbage collections, use the survival tracker to report the call stack information of the potential leakage object, wherein the potential leakage object is the object that still survives after multiple garbage collections; If there are several target objects with the same call stack information and the same object type in the survival state, comprising: Determine each potential leakage object with the same call stack information and object type as each target object.

2. The method of claim 1, wherein, In response to an allocation object operation in the heap memory, triggering an object callback event, obtaining and recording the call stack information and object tracking information of the allocated object; comprising: If the thread allocates objects in the heap memory is monitored, triggering the SampledObjectAlloc event, sampling and recording the object tracking information generated in the allocation object process according to the dynamic sampling interval; wherein the object tracking information comprises: the ID of the target thread of the allocated object, the object class name of the allocated object, the size of the allocated object, the class ID of the allocated object, and the stack frame information of the target thread.

3. The method of claim 2, wherein, The method further comprises: According to the size of the allocated object, determining the weight of the allocated object; Based on the weight of the allocated object, determining the pseudo-random sampling interval for the allocated object as the new dynamic sampling interval of the allocated object.

4. The method of claim 1, wherein, The data compression processing on each target object comprises: Extracting the call stack information, timestamp and allocation size of each target object; Determine whether the call stack information of each target object exists in a preset hash table, if it exists, update the last occurrence timestamp of the corresponding call stack in the preset hash table according to the timestamp of the target object; And according to the allocation size of the target object, accumulate the allocation size of each target object related to the call stack.

5. The method of claim 4, wherein, The method further comprises: If the call stack information of each target object does not exist in the preset hash table, a new entry is created in the preset hash table, the number of allocation times is recorded as 1, the first occurrence timestamp and the current timestamp are recorded, and the object allocation size is initialized as the allocation size of the current target object.

6. The method of claim 4, wherein, The compressed data is displayed in the user interactive interface in a multi-dimensional aggregation manner. Based on the information recorded in the preset hash table, the data after aggregation is displayed in the user interactive interface in a chart manner after aggregation in a target aggregation manner, wherein the target aggregation manner includes one or more of time window aggregation, call stack information level merging, live object aggregation, and dimension merging.

7. A JVM heap memory optimization apparatus, comprising: The apparatus includes: An event triggering module configured to trigger an object callback event in response to an allocation object operation in the heap memory, and acquire and record call stack information and object tracking information of an allocated object, wherein the allocation object operation includes creating weak reference attribute information for the allocated object, the call stack information includes a code path when the allocated object is created, and the object tracking information includes an object type of the allocated object; A live analysis module configured to determine a live state of each object in the heap memory based on the object tracking information and the weak reference attribute information; A compression display module configured to, if there are a plurality of target objects with the same call stack information and the same object type in the live state, perform data compression processing on each target object, and display the compressed data in a user interactive interface in a multi-dimensional aggregation manner. The live analysis module is specifically configured to: Call a live tracker and pass the object tracking information to the live tracker, and determine whether an input object is still alive based on the weak reference attribute information by using the live tracker; If the input object is still alive after a plurality of garbage collections, report call stack information of a potential leak object by using the live tracker, wherein the potential leak object is an object that is still alive after a plurality of garbage collections. If there are a plurality of target objects with the same call stack information and the same object type in the live state, the target objects include: Each potential leak object with the same call stack information and the same object type is determined as each target object.

8. An electronic device, comprising: The electronic device includes a processor and a memory storing a program, wherein the program includes instructions that, when executed by the processor, cause the processor to perform the method according to any one of claims 1-6.

9. A non-transitory computer-readable storage medium having stored thereon computer instructions, wherein, The computer instructions are used to cause a computer to perform the method according to any one of claims 1-6.

Images