Method and device for handling memory leak of java virtual machine

CN116257325BActive Publication Date: 2026-06-30HUNAN HAPPLY SUNSHINE INTERACTIVE ENTERTAINMENT MEDIA CO LTD

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
HUNAN HAPPLY SUNSHINE INTERACTIVE ENTERTAINMENT MEDIA CO LTD
Filing Date
2023-04-19
Publication Date
2026-06-30

Smart Images

  • Figure CN116257325B_ABST
    Figure CN116257325B_ABST
Patent Text Reader

Abstract

This application provides a method and apparatus for handling memory leaks in a Java Virtual Machine (JVM). The method includes: determining whether a memory leak has occurred in the JVM; if a memory leak is determined, identifying the target object causing the leak based on the net memory growth rate of objects in the heap memory; isolating the target object using a bulkhead pattern to limit the maximum heap memory capacity available to the target object; and moving the target object to off-heap memory when the heap memory used by the target object reaches the maximum heap memory capacity. Based on the technical solution provided by this application, the JVM can still provide normal services even when a memory leak occurs.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application belongs to the field of computer technology, and in particular relates to a method and apparatus for handling memory leaks in a Java Virtual Machine. Background Technology

[0002] Memory leaks can occur during the operation of the JVM (Java Virtual Machine). A memory leak occurs when memory is not released after use. Memory leaks can lead to wasted system memory, slowed program execution, and even serious consequences such as system crashes.

[0003] In existing technologies, technicians typically use memory leak detection tools to identify the cause of a memory leak, fix the code accordingly, and then restart the service. This process is time-consuming, and the Java Virtual Machine (JVM) cannot provide services. Therefore, how to handle JVM memory leaks so that the JVM can continue to provide services normally when memory leaks occur is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a method and apparatus for handling memory leaks in a Java Virtual Machine, so that the Java Virtual Machine can still provide services normally when a memory leak occurs.

[0005] To achieve the above objectives, this application provides the following technical solution:

[0006] This application provides a method for handling memory leaks in a Java Virtual Machine, the method comprising:

[0007] Determine if a memory leak has occurred in the Java Virtual Machine;

[0008] If a memory leak is determined to have occurred in the Java Virtual Machine, the target object causing the memory leak is identified based on the net memory growth rate of objects in the heap memory.

[0009] The target object is isolated using a bulkhead pattern to limit the maximum on-heap memory capacity available to the target object;

[0010] If the on-heap memory used by the target object reaches the maximum on-heap memory capacity, the target object will be moved to off-heap memory.

[0011] Optionally, after moving the target object to off-heap memory, the method further includes:

[0012] The target object is compressed based on a reversible compression algorithm;

[0013] Upon receiving an instruction to invoke the target object, the compressed target object is decompressed to the off-heap memory so that the decompressed target object can provide services. After the services are completed, the target object is compressed based on the reversible compression algorithm, and the compressed target object is stored in the off-heap memory.

[0014] Optionally, determining the target object causing the memory leak based on the net memory growth rate of objects in the heap memory includes:

[0015] Determine the age of each object in the heap memory;

[0016] Compare the age of objects in the heap memory with a preset age threshold, and determine objects whose age is greater than the age threshold as over-aged objects;

[0017] Determine the net memory growth rate of the over-aged objects;

[0018] The net memory growth rate of the overaged objects is compared with a preset growth rate threshold, and the overaged objects whose net memory growth rate is greater than the growth rate threshold are identified as target objects.

[0019] Optionally, determining whether a memory leak has occurred in the Java Virtual Machine includes:

[0020] The usage rate of the young generation heap space in the Java Virtual Machine is obtained according to a preset period.

[0021] Based on the usage rate of the young generation heap space obtained multiple times, the usage growth rate of the young generation heap space is determined; if the usage growth rate of the young generation heap space is greater than a preset first threshold within a preset time, it is determined that the Java Virtual Machine has a memory leak.

[0022] Optionally, determining whether a memory leak has occurred in the Java Virtual Machine includes:

[0023] The usage rate of the old generation heap space in the Java Virtual Machine is obtained according to a preset period.

[0024] Based on the usage rate of the old generation heap space obtained multiple times, the usage growth rate of the old generation heap space is determined; if the usage growth rate of the old generation heap space is greater than a preset second threshold within a preset time, it is determined that the Java Virtual Machine has a memory leak.

[0025] Optionally, based on the above method, further settings can be made:

[0026] If the off-heap memory used by the decompressed target object reaches the set maximum off-heap memory capacity, the operating system is triggered to reclaim the off-heap memory used by the target object.

[0027] This application also provides a memory leak handling device for a Java Virtual Machine, the device comprising:

[0028] The judgment unit is used to determine whether a memory leak has occurred in the Java Virtual Machine.

[0029] The target object determination unit is used to determine the target object causing the memory leak based on the net memory growth rate of objects in the heap memory when it is determined that the Java Virtual Machine has a memory leak.

[0030] An isolation unit is used to isolate the target object using a bulkhead pattern to limit the maximum on-heap memory capacity available to the target object.

[0031] The first processing unit is configured to transfer the target object to off-heap memory when the on-heap memory used by the target object reaches the maximum on-heap memory capacity.

[0032] Optionally, based on the above-mentioned device, the following further configuration can be made:

[0033] The second processing unit is configured to compress the target object based on a reversible compression algorithm after the first processing unit has transferred the target object to off-heap memory; when receiving an instruction to call the target object, decompress the compressed target object to the off-heap memory so that the decompressed target object can provide services; after completing the service, compress the target object based on the reversible compression algorithm and store the compressed target object in the off-heap memory.

[0034] Optionally, the target object determination unit is specifically used for:

[0035] Determine the age of each object in the heap memory; compare the age of the objects in the heap memory with a preset age threshold, and identify objects whose age is greater than the age threshold as overaged objects; determine the net memory growth rate of the overaged objects; compare the net memory growth rate of the overaged objects with a preset growth rate threshold, and identify overaged objects whose net memory growth rate is greater than the growth rate threshold as target objects.

[0036] Optionally, based on the above-mentioned device, the following further configuration can be made:

[0037] The reclamation unit is used to trigger the operating system to reclaim the off-heap memory used by the target object when the off-heap memory used by the decompressed target object reaches the set maximum off-heap memory capacity.

[0038] Therefore, the beneficial effects of this application are as follows:

[0039] The Java Virtual Machine (JVM) memory leak handling method and apparatus disclosed in this application first determines whether a JVM memory leak has occurred. If a memory leak is confirmed, the target object causing the leak is identified based on the net memory growth rate of objects in the heap memory. The target object is then isolated using a bulkhead pattern to limit its maximum usable heap memory capacity, preventing it from using JVM memory without restriction and avoiding the memory leak from affecting other objects, thus ensuring that other objects can provide services normally. Furthermore, when the target object reaches its maximum heap memory capacity, it is moved to off-heap memory. The target object in off-heap memory can then provide services normally, thus enabling the JVM to continue providing services even when a memory leak occurs. Attached Figure Description

[0040] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0041] Figure 1 This is a flowchart of a method for handling memory leaks in a Java Virtual Machine disclosed in this application;

[0042] Figure 2 This is a flowchart of another Java Virtual Machine memory leak handling method disclosed in this application;

[0043] Figure 3 A flowchart of the method for determining the target object based on the net memory growth rate of objects in heap memory disclosed in this application;

[0044] Figure 4 This is a schematic diagram of the structure of a memory leak handling device for a Java Virtual Machine disclosed in this application. Detailed Implementation

[0045] This application discloses a method and apparatus for handling memory leaks in a Java Virtual Machine, enabling the Java Virtual Machine to continue providing services normally even when a memory leak occurs.

[0046] First, let's explain the terminology used in this application:

[0047] JVM: Java Virtual Machine, is a specification for computing devices that simulates various computer functions on an actual computer.

[0048] The JVM heap space (heap memory) is the largest memory space managed by the JVM, mainly used to store instances of various classes.

[0049] The young generation heap space is a component of the JVM heap space and is the storage location for newly created objects during JVM runtime.

[0050] The old generation heap space is another component of the JVM heap space. Objects that survive multiple local garbage collections in the young generation heap space are stored in the old generation heap space.

[0051] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0052] See Figure 1 , Figure 1 This is a flowchart illustrating a method for handling memory leaks in a Java Virtual Machine (JVM) as disclosed in this application. The method is executed by an electronic device, which may be the electronic device hosting the JVM. The method includes:

[0053] S1: Determine if a memory leak has occurred in the Java Virtual Machine.

[0054] S2: In the event that a memory leak has occurred in the Java Virtual Machine, the target object causing the memory leak is determined based on the net memory growth rate of objects in the heap memory.

[0055] When a Java Virtual Machine (JVM) creates an object, it allocates memory for the newly created object in the young generation heap space. When a memory leak occurs, the heap memory used by the object causing the leak cannot be reclaimed, and the heap memory used by that object will continue to increase. Therefore, when a JVM memory leak is confirmed, the target object causing the memory leak can be determined based on the net growth rate of the object's memory usage in the heap.

[0056] The net memory growth rate of objects is: (M i+1 -M i ) / M i Among them, M i M represents the amount of heap memory used by the object in the i-th detection cycle. i+1 This represents the amount of on-heap memory used by the object in the (i+1)th detection cycle.

[0057] S3: Use the bulkhead pattern to isolate the target object to limit the maximum on-heap memory capacity that the target object can use.

[0058] S4: If the on-heap memory used by the target object reaches the maximum on-heap memory capacity, move the target object to off-heap memory.

[0059] It should be noted that off-heap memory is managed by the operating system. After executing step S4, on-heap memory no longer stores the target object.

[0060] Understandably, if the heap memory used by the target object does not reach the maximum heap memory capacity, there is no need to process the target object, and the target object can provide services normally.

[0061] The maximum heap memory capacity set for a target object can be an empirical value or it can be set based on the memory capacity of the Java Virtual Machine.

[0062] The Java Virtual Machine (JVM) memory leak handling method disclosed in this application first determines whether a JVM memory leak has occurred. If a memory leak is confirmed, the target object causing the leak is identified based on the net memory growth rate of objects in the heap. The target object is then isolated using a bulkhead pattern to limit its maximum heap memory usage, preventing unrestricted use of JVM memory and avoiding the impact of the memory leak on other objects, thus ensuring that other objects can provide services normally. Furthermore, when the target object reaches its maximum heap memory capacity, it is moved to off-heap memory. The off-heap target object can then provide services normally, ensuring that the JVM can still provide services even when a memory leak occurs.

[0063] See Figure 2 , Figure 2 This is a flowchart illustrating another method for handling memory leaks in a Java Virtual Machine (JVM) as disclosed in this application. The method is executed by an electronic device, which may be the electronic device hosting the JVM. The method includes:

[0064] S1: Determine if a memory leak has occurred in the Java Virtual Machine.

[0065] S2: In the event that a memory leak has occurred in the Java Virtual Machine, the target object causing the memory leak is determined based on the net memory growth rate of objects in the heap memory.

[0066] S3: Use the bulkhead pattern to isolate the target object to limit the maximum on-heap memory capacity that the target object can use.

[0067] S4: If the on-heap memory used by the target object reaches its maximum memory capacity, move the target object to off-heap memory.

[0068] S5: Compress the target object based on a reversible compression algorithm.

[0069] S6: When an instruction to call the target object is received, the compressed target object is decompressed to off-heap memory so that the decompressed target object can provide services. After the service is completed, the target object is compressed based on a reversible compression algorithm and the compressed target object is stored in off-heap memory.

[0070] It's important to note that after decompressing the compressed target object, the decompressed target object is stored in off-heap memory, and the compressed target object is no longer stored. In other words, off-heap memory does not simultaneously store both compressed and decompressed versions of the target object, in order to reduce the off-heap memory used by the target object when it is not being used.

[0071] In addition, the target object can be compressed multiple times to reduce the off-heap memory used by the target object when it is not called. Correspondingly, when the target object needs to be called to provide services, it also needs to be decompressed multiple times.

[0072] Optionally, the multiple compression processes performed on the target object can employ different reversible compression algorithms. For example, the target object can be compressed for the first time using the LZ77 compression algorithm, and then compressed a second time using the Huffman tree compression algorithm. Correspondingly, when it is necessary to call the target object to provide services, the object can be decompressed for the first time using the Huffman tree compression algorithm, and then decompressed a second time using the LZ77 compression algorithm.

[0073] This application Figure 2 The publicly available Java Virtual Machine memory leak handling method involves moving the target object to off-heap memory when the on-heap memory used by the target object reaches the maximum on-heap memory capacity. Furthermore, the target object is compressed using a reversible compression algorithm. When the target object is needed to provide services, the compressed target object is decompressed in off-heap memory, and the decompressed target object provides the services. After the target object completes the service, it is compressed again using the reversible algorithm and stored in off-heap memory, thereby reducing the off-heap memory used when the target object is not being used.

[0074] In another embodiment of this application, in Figure 2Based on the method shown, a further setting is made: when the off-heap memory used by the decompressed target object reaches the set maximum off-heap memory capacity, the operating system is triggered to reclaim the off-heap memory used by the target object.

[0075] In practice, the target object can be determined based on the net memory growth rate of objects in the heap memory. The following approach can be adopted: determine the net memory growth rate of each object in the heap memory; compare the net memory growth rate of each object with the preset growth rate threshold, and determine the object whose net memory growth rate is greater than the growth rate threshold as the target object.

[0076] In another embodiment of this application, the target object is determined based on the net memory growth rate of objects in the heap memory, using methods such as... Figure 3 The proposed scheme includes:

[0077] S21: Determine the age of each object in the heap memory.

[0078] S22: Compare the age of objects in the heap memory with a preset age threshold, and identify objects whose age is greater than the age threshold as over-aged objects.

[0079] S23: Determine the net memory growth rate of overaged objects.

[0080] S24: Compare the net memory growth rate of over-aged objects with the preset growth rate threshold, and identify over-aged objects whose net memory growth rate is greater than the growth rate threshold as target objects.

[0081] The Java Virtual Machine (JVM) performs garbage collection on heap memory. After each garbage collection operation, if the heap memory used by an object is not reclaimed, the object's age is incremented by 1. If an object does not have a memory leak, the heap memory used by the object will be reclaimed after a period of time (after multiple garbage collection operations), and the object's age will not continue to increase. However, if an object has a memory leak, the heap memory used by the object cannot be reclaimed, the heap memory used by the object will continue to increase, and the object's age will also continue to increase.

[0082] In the scheme disclosed in this application, over-aged objects are first screened out, that is, objects that may cause memory leaks are screened based on their age. Then, the net memory growth rate of each over-aged object is compared with a preset growth rate threshold. If the net memory growth rate of an over-aged object is greater than the growth rate threshold, then the over-aged object is determined as the target object. Compared with the first scheme for determining target objects disclosed above, this reduces the amount of data computation.

[0083] In implementation, memory snapshots of the Java Virtual Machine are obtained at preset intervals. Based on the memory snapshots, the age of each object in the heap memory is determined. The age of the objects in the heap memory is compared with a preset age threshold. Objects with an age greater than the age threshold are identified as overaged objects. The net memory growth rate of overaged objects is determined based on memory snapshots obtained in adjacent intervals. The net memory growth rate of overaged objects is compared with a preset growth rate threshold. Overaged objects with a net memory growth rate greater than the growth rate threshold are identified as target objects.

[0084] Typically, the JVM heap space is divided into the young generation heap space and the old generation heap space. In some cases, the JVM heap space is divided into the young generation heap space, the old generation heap space, and the permanent generation space.

[0085] The Java Virtual Machine employs different garbage collection mechanisms for the young generation heap and the old generation heap. Typically, garbage collection for the young generation heap is called Minor GC, and garbage collection for the old generation heap is called Full GC.

[0086] For example, garbage collection in the young generation heap space is performed using a copying algorithm, while garbage collection in the old generation heap space is performed using a mark-and-sweep algorithm. Objects that survive multiple garbage collections in the young generation heap space are stored in the old generation heap space. If the data stored in the heap space continues to increase, this indicates that some memory has not been released after use, and a memory leak has occurred in the Java Virtual Machine.

[0087] In another embodiment of this application, the following method is used to determine whether a memory leak has occurred in the Java Virtual Machine:

[0088] The usage rate of the young generation heap space in the Java Virtual Machine is obtained according to a preset period.

[0089] Based on the usage rate of the young generation heap space obtained multiple times, the usage growth rate of the young generation heap space is determined; if the usage growth rate of the young generation heap space exceeds a preset first threshold within a preset time, it is determined that a memory leak has occurred in the Java Virtual Machine.

[0090] It is understandable that during normal Java Virtual Machine (JVM) operation, the space used in the young generation heap is dynamically balanced. That is, the space used in the young generation heap will dynamically increase or decrease, rather than continuously increase. Therefore, based on the usage rate of the young generation heap space obtained multiple times, the usage growth rate of the young generation heap space is determined. If the usage growth rate of the young generation heap space exceeds a first threshold within a preset time, it indicates that the usage rate of the young generation heap space is continuously increasing, confirming that some memory has not been reclaimed after use, resulting in a memory leak. Here, the first threshold is an empirical value, and it is understood that the first threshold is a positive number. The usage growth rate of the young generation heap space is: (Yi+1 -Y i ) / Y i Among them, Y i Y represents the utilization rate of the young generation heap space in the i-th detection cycle. i+1 This represents the utilization rate of the young generation heap space during the (i+1)th detection cycle.

[0091] Optionally, the usage rate of the young generation heap space in the Java Virtual Machine can be obtained according to a preset period. Specifically, the usage rate of the young generation heap space is obtained after garbage collection is performed on the young generation heap space.

[0092] In another embodiment of this application, the following method is used to determine whether a memory leak has occurred in the Java Virtual Machine:

[0093] The usage rate of the old generation heap space in the Java Virtual Machine is obtained according to a preset period.

[0094] Based on the usage rate of the old generation heap space obtained multiple times, the usage growth rate of the old generation heap space is determined; if the usage growth rate of the old generation heap space exceeds a preset second threshold within a preset time, it is determined that a memory leak has occurred in the Java Virtual Machine.

[0095] It is understandable that during normal Java Virtual Machine (JVM) operation, the space used in the old generation heap is dynamically balanced. That is, the space used in the old generation heap will dynamically increase or decrease, rather than continuously increase. Therefore, based on the old generation heap space usage rate obtained multiple times, the old generation heap space usage growth rate is determined. If the old generation heap space usage growth rate is greater than a second threshold within a preset time, it indicates that the old generation heap space usage rate is continuously increasing, confirming that some memory has not been reclaimed after use, resulting in a memory leak. The second threshold is an empirical value, and understandably, it is a positive number. The old generation heap space usage growth rate is: (O i+1 -O i ) / O i Among them, O i O represents the utilization rate of the old generation heap space in the i-th detection cycle. i+1 This represents the utilization rate of the old generation heap space in the (i+1)th detection cycle.

[0096] Optionally, the usage rate of the old generation heap space in the Java Virtual Machine can be obtained according to a preset period. Specifically, the usage rate of the old generation heap space is obtained after garbage collection of the old generation space.

[0097] The above-disclosed method for handling memory leaks in a Java Virtual Machine, and correspondingly, the above-disclosed apparatus for handling memory leaks in a Java Virtual Machine. The descriptions of the two in the specification can be referenced interchangeably.

[0098] See Figure 4 , Figure 4 This is a schematic diagram of a memory leak handling device for a Java Virtual Machine disclosed in this application. The memory leak handling device includes:

[0099] Judgment unit 10 is used to determine whether a memory leak has occurred in the Java Virtual Machine;

[0100] The target object determination unit 20 is used to determine the target object that caused the memory leak based on the net memory growth rate of objects in the heap memory when it is determined that a memory leak has occurred in the Java Virtual Machine.

[0101] Isolation unit 30 is used to isolate the target object using a bulkhead pattern to limit the maximum on-heap memory capacity that the target object can use;

[0102] The first processing unit 40 is used to transfer the target object to off-heap memory when the on-heap memory used by the target object reaches the maximum on-heap memory capacity.

[0103] The memory leak handling apparatus for the Java Virtual Machine disclosed in this application first determines whether a memory leak has occurred in the Java Virtual Machine. If a memory leak is confirmed, the target object causing the leak is identified based on the net memory growth rate of objects in the heap memory. The target object is then isolated using a bulkhead pattern to limit its maximum usable heap memory capacity, preventing it from using the Java Virtual Machine's memory without restriction and avoiding the memory leak from affecting other objects, thus ensuring that other objects can provide services normally. Furthermore, when the target object reaches its maximum heap memory capacity, it is moved to off-heap memory. The target object in off-heap memory can then provide services normally, thereby ensuring that the Java Virtual Machine can still provide services normally even when a memory leak occurs.

[0104] In another embodiment, in Figure 4 Based on the memory leak handling device of the Java Virtual Machine shown, a second processing unit is further set up.

[0105] The second processing unit is used to: after the first processing unit transfers the target object to off-heap memory, compress the target object based on a reversible compression algorithm; when receiving an instruction to call the target object, decompress the compressed target object to off-heap memory so that the decompressed target object can provide services; after completing the service, compress the target object based on the reversible compression algorithm and store the compressed target object in off-heap memory.

[0106] In another embodiment, the memory leak handling apparatus further includes a recycling unit.

[0107] The reclamation unit is used to trigger the operating system to reclaim the off-heap memory used by the target object when the off-heap memory used by the decompressed target object reaches the set maximum off-heap memory capacity.

[0108] In another embodiment, the target object determination unit 20 is specifically used for:

[0109] Determine the age of each object in the heap memory; compare the age of the objects in the heap memory with a preset age threshold, and identify objects whose age is greater than the age threshold as over-aged objects; determine the net memory growth rate of over-aged objects; compare the net memory growth rate of over-aged objects with a preset growth rate threshold, and identify over-aged objects whose net memory growth rate is greater than the growth rate threshold as target objects.

[0110] In another embodiment, the determining unit 10 is specifically used for:

[0111] The usage rate of the young generation heap space in the Java Virtual Machine is obtained according to a preset period; the usage growth rate of the young generation heap space is determined based on the usage rate of the young generation heap space obtained multiple times; if the usage growth rate of the young generation heap space is greater than a preset first threshold within a preset time, it is determined that the Java Virtual Machine has a memory leak.

[0112] or,

[0113] The usage rate of the old generation heap space in the Java Virtual Machine is obtained according to a preset period; the usage growth rate of the old generation heap space is determined based on the usage rate of the old generation heap space obtained multiple times; if the usage growth rate of the old generation heap space is greater than a preset second threshold within a preset time, it is determined that the Java Virtual Machine has a memory leak.

[0114] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0115] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0116] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for handling memory leaks in a Java Virtual Machine, characterized in that, The method includes: Determine if a memory leak has occurred in the Java Virtual Machine; If a memory leak is determined to have occurred in the Java Virtual Machine, the target object causing the memory leak is identified based on the net memory growth rate of objects in the heap memory. The target object is isolated using a bulkhead pattern to limit the maximum on-heap memory capacity available to the target object; If the on-heap memory used by the target object reaches the maximum on-heap memory capacity, the target object will be moved to off-heap memory. The method of determining the target object causing the memory leak based on the net memory growth rate of objects in the heap memory includes: Determine the age of each object in the heap memory; Compare the age of objects in the heap memory with a preset age threshold, and determine objects whose age is greater than the age threshold as over-aged objects; Determine the net memory growth rate of the over-aged objects; The net memory growth rate of the overaged objects is compared with a preset growth rate threshold, and the overaged objects whose net memory growth rate is greater than the growth rate threshold are identified as target objects.

2. The method according to claim 1, characterized in that, After moving the target object to off-heap memory, the process also includes: The target object is compressed based on a reversible compression algorithm; Upon receiving an instruction to invoke the target object, the compressed target object is decompressed to the off-heap memory so that the decompressed target object can provide services. After the services are completed, the target object is compressed based on the reversible compression algorithm, and the compressed target object is stored in the off-heap memory.

3. The method according to claim 1 or 2, characterized in that, The method for determining whether a Java Virtual Machine (JVM) memory leak has occurred includes: The usage rate of the young generation heap space in the Java Virtual Machine is obtained according to a preset period. Based on the usage rate of the young generation heap space obtained multiple times, the usage growth rate of the young generation heap space is determined; if the usage growth rate of the young generation heap space is greater than a preset first threshold within a preset time, it is determined that the Java Virtual Machine has a memory leak.

4. The method according to claim 1 or 2, characterized in that, The method for determining whether a Java Virtual Machine (JVM) memory leak has occurred includes: The usage rate of the old generation heap space in the Java Virtual Machine is obtained according to a preset period. Based on the usage rate of the old generation heap space obtained multiple times, the usage growth rate of the old generation heap space is determined; if the usage growth rate of the old generation heap space is greater than a preset second threshold within a preset time, it is determined that the Java Virtual Machine has a memory leak.

5. The method according to claim 2, characterized in that, Also includes: If the off-heap memory used by the decompressed target object reaches the set maximum off-heap memory capacity, the operating system is triggered to reclaim the off-heap memory used by the target object.

6. A memory leak handling device for a Java Virtual Machine, characterized in that, The device includes: The judgment unit is used to determine whether a memory leak has occurred in the Java Virtual Machine. The target object determination unit is used to determine the target object causing the memory leak based on the net memory growth rate of objects in the heap memory when it is determined that the Java Virtual Machine has a memory leak. An isolation unit is used to isolate the target object using a bulkhead pattern to limit the maximum on-heap memory capacity available to the target object. The first processing unit is configured to transfer the target object to off-heap memory when the on-heap memory used by the target object reaches the maximum on-heap memory capacity. Specifically, the target object determination unit is used for: Determine the age of each object in the heap memory; compare the age of the objects in the heap memory with a preset age threshold, and identify objects whose age is greater than the age threshold as overaged objects; determine the net memory growth rate of the overaged objects; compare the net memory growth rate of the overaged objects with a preset growth rate threshold, and identify overaged objects whose net memory growth rate is greater than the growth rate threshold as target objects.

7. The apparatus according to claim 6, characterized in that, Also includes: The second processing unit is used to compress the target object based on a reversible compression algorithm after the first processing unit has transferred the target object to off-heap memory; Upon receiving an instruction to invoke the target object, the compressed target object is decompressed to the off-heap memory so that the decompressed target object can provide services. After the services are completed, the target object is compressed based on the reversible compression algorithm, and the compressed target object is stored in the off-heap memory.

8. The apparatus according to claim 7, characterized in that, Also includes: The reclamation unit is used to trigger the operating system to reclaim the off-heap memory used by the target object when the off-heap memory used by the decompressed target object reaches the set maximum off-heap memory capacity.