CN112148428B - Java virtual machine memory monitoring method, computer equipment and storage medium - Google Patents

Java virtual machine memory monitoring method, computer equipment and storage medium Download PDF

Info

Publication number
CN112148428B
CN112148428B CN202010952285.4A CN202010952285A CN112148428B CN 112148428 B CN112148428 B CN 112148428B CN 202010952285 A CN202010952285 A CN 202010952285A CN 112148428 B CN112148428 B CN 112148428B
Authority
CN
China
Prior art keywords
memory
size
virtual machine
heap
java virtual
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202010952285.4A
Other languages
Chinese (zh)
Other versions
CN112148428A (en
Inventor
廖雄杰
郭东旭
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Keynote Network Inc
Original Assignee
Beijing Keynote Network Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Keynote Network Inc filed Critical Beijing Keynote Network Inc
Priority to CN202010952285.4A priority Critical patent/CN112148428B/en
Publication of CN112148428A publication Critical patent/CN112148428A/en
Application granted granted Critical
Publication of CN112148428B publication Critical patent/CN112148428B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/301—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is a virtual computing platform, e.g. logically partitioned systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45591—Monitoring or debugging support

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Mathematical Physics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

The application relates to a Java virtual machine memory monitoring method, computer equipment and a storage medium, wherein the method comprises the following steps: intercepting an HTTP request; recording the request occurrence time of the HTTP request; acquiring a request uniform resource identifier (requestURI) and/or a context path (contextPath) of the HTTP request; acquiring the size of a first stack of memory accumulatively allocated by the Java virtual machine for the thread corresponding to the HTTP request; after executing the service code corresponding to the HTTP request, acquiring the size of a second heap memory accumulatively allocated by the Java virtual machine for the thread corresponding to the HTTP request; determining the size of a third stack of memory allocated for executing the service code application by the requestURI and/or the contextPath as the difference between the size of the second stack of memory and the size of the first stack of memory; and recording the corresponding relation between the requestURI and/or the contextPath, the request occurrence time and the third heap memory size. By the method and the device, the memory of the Java virtual machine can be monitored according to the requestURI and/or the contextPath.

Description

Java virtual machine memory monitoring method, computer equipment and storage medium
Technical Field
The present application relates to the field of computer technologies, and in particular, to a method for monitoring a memory of a Java virtual machine (JVM for short), a computer device, and a storage medium.
Background
The memory of the JVM is divided into Heap (Heap) and Non-Heap (Non-Heap) regions, the Heap is the runtime data region from which memory of all class instances and arrays is allocated. The heap is created at the start of the Java virtual machine. The heap memory of objects is reclaimed by an automatic memory management system called a garbage reclaimer.
In the related art, the JVM monitoring method can only monitor the memory application and occupation status of the whole heap area and non-heap area of the JVM.
Disclosure of Invention
In order to solve the technical problem or at least partially solve the technical problem, the present application provides a Java virtual machine memory monitoring method, a computer device, and a storage medium.
In a first aspect, the present application provides a method for monitoring a memory of a Java virtual machine, including: intercepting an HTTP request; recording the request occurrence time of the HTTP request; acquiring a request uniform resource identifier (requestURI) and/or a context path (contextPath) of the HTTP request; acquiring the size of a first stack of memory accumulatively allocated by the Java virtual machine for the thread corresponding to the HTTP request; after executing the service code corresponding to the HTTP request, acquiring the size of a second heap memory accumulatively allocated by the Java virtual machine for the thread corresponding to the HTTP request; determining the size of a third heap of memory, which is applied and allocated by the execution of the service code by the requestURI and/or the contextPath, as the difference between the size of the second heap of memory and the size of the first heap of memory; and recording the corresponding relation between the requestURI and/or the contextPath, the request occurrence time and the third heap memory size.
In some embodiments, the method for monitoring the memory of the Java virtual machine further includes: acquiring the size of a fourth heap memory used by the Java virtual machine within preset time; and determining the size of a fifth heap memory actually used by the requestURI and/or the contextPath according to the size of the fourth heap memory, wherein the size of the fifth heap memory is in direct proportion to the ratio of the size of the heap memory which is cumulatively applied and allocated by the requestURI and/or the contextPath in the preset time to the size of the heap memory which is cumulatively allocated by the Java virtual machine in the preset time.
In some embodiments, intercepting an HTTP request comprises: the HTTP request is intercepted by the invoke method of Tomcat's request interceptor interface.
In some embodiments, intercepting an HTTP request comprises: the HTTP request is intercepted by a service method of an interception service connector (Servlet) by using a bytecode injection mechanism.
In some embodiments, the first bank memory size and the second bank memory size are obtained by a com.
In some embodiments, the method for monitoring the memory of the Java virtual machine further includes: intercepting a business method corresponding to the HTTP request; recording the method name and the occurrence time of the service method; acquiring the size of a sixth heap of memory accumulatively allocated by the Java virtual machine for the thread corresponding to the HTTP request; before the business method returns, acquiring the size of a seventh heap memory accumulatively allocated by the Java virtual machine for the thread corresponding to the HTTP request; and determining the size of the eighth heap of memory applied and allocated by the business method as the difference between the size of the seventh heap of memory and the size of the sixth heap of memory.
In some embodiments, a method for intercepting a service corresponding to an HTTP request includes: and intercepting a business method corresponding to the HTTP request through a Java byte code injection mechanism.
In some embodiments, the sixth heap memory size and the seventh heap memory size are obtained by a com.
In a second aspect, the present application provides a computer device comprising: a memory, a processor, and a computer program stored on the memory and executable on the processor; when being executed by a processor, the computer program realizes the steps of the memory monitoring method of the Java virtual machine.
In a third aspect, the present application provides a computer-readable storage medium, where a Java virtual machine memory monitoring program is stored on the computer-readable storage medium, and the Java virtual machine memory monitoring program, when executed by a processor, implements the steps of the Java virtual machine memory monitoring method.
Compared with the prior art, the technical scheme provided by the embodiment of the application has the following advantages: according to the method provided by the embodiment of the application, the JVM heap memory allocation process is associated with the contextPath and/or the requestURI, and the monitoring of the Java virtual machine memory by the requestURI and/or the contextPath is realized.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and together with the description, serve to explain the principles of the invention.
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, and it is obvious for those skilled in the art that other drawings can be obtained according to the drawings without inventive exercise.
Fig. 1 is a flowchart of an embodiment of a method for monitoring a memory of a Java virtual machine according to an embodiment of the present invention;
fig. 2 is a flowchart of another implementation of a method for monitoring a memory of a Java virtual machine according to an embodiment of the present application; and
fig. 3 is a hardware schematic diagram of an implementation manner of a computer device according to an embodiment of the present application.
Detailed Description
It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.
In the following description, suffixes such as "module", "component", or "unit" used to denote elements are used only for facilitating the explanation of the present invention, and have no specific meaning in itself. Thus, "module", "component" or "unit" may be used mixedly.
For the purpose of facilitating an understanding of the present application, the technical terms referred to herein are described as follows:
heap memory
The memory of the Java virtual machine is divided into a Heap area (Heap) and a Non-Heap area (Non-Heap), the Heap is a runtime data area, and the memory of all class instances and arrays is distributed from the Heap. The heap is created at the start of the Java virtual machine. The heap memory of objects is reclaimed by an automatic memory management system called a garbage reclaimer.
Thread local cache (TLAB)
The thread local cache (TLAB) is called thread local AllocBuffer, is a private memory of the thread, when the thread is initialized, simultaneously, can also apply for a memory of a specified size, only use for the current thread, each thread has a Buffer alone like this, if need distribute the memory, just distribute on own Buffer, just so there is not the situation of competition, can promote the distribution efficiency greatly, when the Buffer capacity is not enough, again apply for a block from the Eden region and continue to use, this application action still needs atomic operation.
When the TLAB allocates the memory space for the new object, each Java application thread can allocate the space by using the exclusive allocation pointer of the TLAB, and the synchronous overhead caused by updating the allocation pointer shared in the GC heap (eden area) is shared.
Uniform Resource Identifier (URI)
A Uniform Resource Identifier (URI) is a string used to identify the name of an internet Resource. This identification allows the user to interoperate with any resource (including local and internet) via a particular protocol. The URI is defined by a scheme that includes a deterministic syntax and associated protocols. The URI in this context comprises a URI identification of an HTTP request in a Web application.
Byte code injection
The Java byte code file (class file) is compiled by a Java compiler, and byte codes can be modified during running by redefining a ClassLoader or utilizing JVMTI and Instrumentation mechanisms, so that some non-service logic codes are dynamically injected at a specified position. There are many open source frameworks that can be used to assist bytecode injection, such as ASM, BCEL, CGLIB, javasissst, etc.
JVMTI
JVM (JVM Tool interface) is a Native (C/C + +) interface provided by a Java virtual machine, can probe the internal state of the JVM and control the execution of JVM application programs, and can realize the purpose of enhancement by dynamically modifying JVM runtime class bytecodes. The functions that can be implemented include, but are not limited to: obtain JVM runtime state, replace and modify class definitions, and the like.
Instrumentation
Java Instrumentation refers to applications that can be monitored and assisted by an agent program independent of the application running on the JVM, and can achieve enhanced objectives by dynamically modifying JVM runtime class bytecodes. Such monitoring and assistance includes, but is not limited to, obtaining JVM runtime state, replacing and modifying class definitions, and the like.
The Java Instrumentation work and a set of Java agent interfaces on JVMTI, and developers can realize the Java interface by using Java language.
Apache Tomcat
One of the core projects in the Jakarta project of the Apache Software Foundation (Apache Software Foundation) is the most widely used open source Java Web application server.
Servlet
Java Servlet is a program running on a Web server or application server that acts as an intermediary between requests from a Web browser or other HTTP client and a database or application on the HTTP server.
getThreadAllocarededBytes method
The ThreadMXBean of JDK provides a getthreadallcatedbytes (long threadid) method that captures the heap memory size (in bytes) that a given thread applies for allocation since the thread started.
The following describes a method for monitoring a memory of a Java virtual machine according to an embodiment of the present application.
Fig. 1 is a flowchart of an implementation manner of a Java virtual machine memory monitoring method according to an embodiment of the present application, and as shown in fig. 1, the method includes steps S102 to S114.
Step S102, an HTTP request is intercepted.
Step S104 records the request occurrence time of the HTTP request.
Step S106, obtaining a request uniform resource identifier (requestURI) and/or a context path (contextPath) of the HTTP request.
Step S108, a first heap memory size (denoted as M0 in this embodiment) cumulatively allocated by the Java virtual machine for the thread corresponding to the HTTP request is obtained.
In the embodiment of the present application, HTTP requests have a correspondence with threads, for example, one HTTP request is executed by one thread.
In step S110, after executing the service code corresponding to the HTTP request, a second heap memory size (denoted as M1 in this embodiment) that is accumulatively allocated by the Java virtual machine for the thread corresponding to the HTTP request is obtained.
In step S112, it is determined that the third heap memory size allocated for executing the service code by the requestURI and/or the contextPath is the difference between the second heap memory size and the first heap memory size (in the embodiment of the present application, M1-M0).
Step S114, recording the corresponding relation between the requestURI and/or contextPath, the request occurrence time and the size of the third heap memory.
According to the embodiment of the application, the JVM heap memory allocation process is associated with the contextPath and/or the requestURI, so that the monitoring of the Java virtual machine memory by the requestURI and/or the contextPath is realized.
The size of the heap memory requested for allocation is not equal to the size of the actually used heap contents, and therefore, in some embodiments, the method further includes: obtaining a fourth heap memory size used by the Java virtual machine within a predetermined time, for example, by calling a Java. And determining the size of a fifth heap memory actually used by the requestURI and/or the contextPath according to the size of the fourth heap memory, wherein the size of the fifth heap memory is in direct proportion to the ratio of the size of the heap memory which is cumulatively applied and allocated by the requestURI and/or the contextPath in the preset time to the size of the heap memory which is cumulatively allocated by the Java virtual machine in the preset time.
By way of illustration, there are a total of n request URIs during a predetermined time (e.g., 30 minutes), if any1Cumulative application allocation memory is A1，URI2Cumulative application allocation memory is A2，URInCumulative application allocation memory is AnAnd if the size of the fourth heap memory used by the Java virtual machine is recorded as H, the URIiThe actual heap memory occupied may be approximated as: hi= （Ai / ∑Ai) H, where, Σ AiIs a URI1To URInThe sum of the allocated memories is accumulated.
In some embodiments, intercepting an HTTP request comprises: the HTTP request is intercepted by the invoke method of Tomcat's request interceptor interface.
In some embodiments, intercepting an HTTP request comprises: the HTTP request is intercepted by a service method of an interception service connector (Servlet) by using a bytecode injection mechanism.
In some embodiments, the first bank memory size and the second bank memory size are obtained by a com.
Fig. 2 is a flowchart of another implementation of a method for monitoring a memory of a Java virtual machine according to an embodiment of the present application, where as shown in fig. 2, the method for monitoring a memory of a Java virtual machine includes: step S202 to step S210.
Step S202, intercepting a business method corresponding to the HTTP request.
Step S204, recording the method name and the occurrence time of the service method.
In step S206, the heap memory size (sixth heap memory size) accumulatively allocated by the Java virtual machine for the thread corresponding to the HTTP request is obtained.
Step S208, before the service method returns, the heap memory size (seventh heap memory size) accumulatively allocated by the Java virtual machine for the thread corresponding to the HTTP request is obtained.
In step S210, it is determined that the heap memory size (eighth heap memory size) allocated by the business method application is the difference between the two heap memory sizes (the difference between the seventh heap memory size and the sixth heap memory size).
According to the embodiment of the application, the JVM heap memory allocation process is associated with the business method, and monitoring of the memory of the Java virtual machine by the business method is achieved.
In some embodiments, a service method corresponding to the HTTP request is intercepted by a Java bytecode injection mechanism.
In some embodiments, the heap memory size (sixth and seventh heap memory sizes) cumulatively allocated by the Java virtual machine for the thread corresponding to the HTTP request is obtained by a com.
The embodiments of the present application will be described below with reference to several examples.
Example 1: URI and application granular heap memory monitoring under Apache Tomcat
Apache Tomcat opens a request interceptor (Valve) interface, in this example, HTTP request interception is realized by customizing Valve, and monitoring related logic is added before and after HTTP request response. The realization process is as follows:
in this example, the Tomcat configuration uses the conventional BIO mode. Under the BIO mode, the execution mechanism of Tomcat always uses the same thread to execute a request from beginning to end, and thread switching does not occur.
In this example, the invoke method of the Valve interface is opened by reloading Tomcat, and the interception of the HTTP request is implemented, where the complete signature of the invoke method is: public void invoke (Request, Response) through IOException, ServeleException.
In this example, the invoke method of the ValveBase is rewritten, the time when the HTTP Request occurs is recorded at the beginning of the invoke method, the requestURI and the contextPath in the Request are obtained (the contextPath of Tomcat corresponds to an application deployed under the container), and meanwhile, the getthreadallcatebytes method of the ThreadMXBean is called to obtain the cumulative allocation heap memory size of the current thread (the thread corresponding to the HTTP Request), which is recorded as: m0.
In this example, getNext (). invoke (request, response) is called and the business code is executed. Calling the getThreadAllatedBytes method of the ThreadMXBean again to obtain the accumulated allocation heap memory size of the current thread (the thread corresponding to the HTTP request), and recording as: m1.
In this example, in the BIO mode, because the execution mechanism of Tomcat is used, one request is always executed by using the same thread from beginning to end, and no thread switching occurs, so the difference between M1 and M0 (M1-M0) is the size of the heap memory applied and allocated from the JVM during the execution of the current request service code. And recording the time of the request, the requestURI, the contextPath and the heap memory size allocated by the application.
In this example, the time of each HTTP request, the requestURI, the contextPath, and the heap memory size to be allocated for application are recorded, and the summarized values of the heap memory to be allocated for application in the reqestURI and contextPath dimensions are counted respectively by using (time + requestURI) and (time + contextPath) as dimensions, so that the memory allocation size monitoring of the URI and contextPath (application) granularity can be realized.
The size of the heap memory to which allocation is applied is not equal to the size of the heap memory actually used, but generally speaking, the size of the heap memory to which allocation is applied and the size of the heap memory actually usedThe storage has approximate linear relation, if the accumulated size of the heap memory allocated by a certain URI or a certain application is larger, the actual heap memory occupation is also larger, and in the actual application, developers often pay attention to the application or method of the first few memory killers, for example, if the request URI is set to be n in total, within the last 30 minutes, if the request URI is set to be1Cumulative application allocation memory is A1，URI2Cumulative application allocation memory is A2By analogy, URInCumulative application allocation memory is AnIf the JVM used heap memory has been H in the last 30 minutes, then the URIiThe actual heap memory occupied may be approximated as: hi= （Ai / ∑Ai）* H。
Example 2: bytecode injection based heap memory monitoring of URI/contextPath granularity
In this example, interception and monitoring of arbitrary methods is achieved using the mechanism of Java Instrumentation. By using a Java Instrumentation mechanism and matching with a CGLIB or ASM byte code modification tool, memory monitoring codes are added before and after calling any method, so that heap memory monitoring of method granularity and URI granularity is realized. The specific monitoring implementation logic is as follows:
a service method for intercepting servlets inserts a code segment at the beginning of the service method, records the time when an HTTP Request occurs, acquires a requestURI and a contextPath in a Request, calls a getThreadAllcateBytes method of ThreadMXBean, acquires the accumulated allocation heap memory size of the current thread (the thread corresponding to the HTTP Request), and records the accumulated allocation heap memory size as: m0.
Before the service method returns, inserting a code segment, calling the getthreadallockedbytes method of ThreadMXBean again, obtaining the accumulated allocation heap memory size of the current thread (the thread corresponding to the HTTP request), and recording as: m1.
The difference (M1-M0) between M1 and M0 is the size of the heap memory applied and allocated from the JVM in the current HTTP request service code execution process. And recording the time of the request, the requestURI, the contextPath and the heap memory size allocated by the application.
In this example, the time of each HTTP request, the requestURI, the contextPath, and the heap memory size for the application allocation are recorded. Taking (time + requestURI) and (time + contextPath) as dimensions, respectively counting the summary values of the application allocation heap memory in the dimensions of reqestURI and contextPath, so as to realize the statistical data of the allocation memory of URI and contextPath granularity.
Further, within the last 30 minutes, a total of n request URIs are set, and if the URI is found to be1Cumulative application allocation memory is A1，URI2Cumulative application allocation memory is A2By analogy, URInCumulative application allocation memory is AnWhen the current JVM used heap memory is H, URIiThe actual heap memory occupied may be approximated as: hi= （Ai / ∑Ai）* H。
Example 3: heap memory monitoring of business method granularity based on bytecode injection
Dynamically embedding codes into an interested business method, inserting a code segment at the beginning of the business method to be monitored, recording a timestamp and a method name of the method, calling a getthreadmatch bytes method of threadMXBean to obtain the accumulated allocation heap memory size of the current thread (the thread corresponding to the HTTP request), and recording the accumulated allocation heap memory size as: m0.
And calling the original service method. Before the method returns, the getThreadAllockedBytes method of ThreadMXBean is called again, and the accumulated allocation heap memory size of the current thread (the thread corresponding to the HTTP request) is obtained and recorded as: m1.
The difference (M1-M0) between M1 and M0 is the size of heap memory requested and allocated from the JVM during the execution of the current service request method.
In this example, the timestamp and the memory allocation size of each call of each business method are recorded. And counting the statistical data of the distributed memory of each method granularity by taking the method name as a dimension. And during display, the distributed memory sum values of each method are arranged from large to small.
The embodiment also provides a computer device, such as a smart phone, a tablet computer, a notebook computer, a desktop computer, a rack server, a blade server, a tower server or a rack server (including an independent server or a server cluster composed of a plurality of servers) capable of executing programs, and the like. The computer device 20 of the present embodiment includes at least, but is not limited to: a memory 21, a processor 22, which may be communicatively coupled to each other via a system bus, as shown in FIG. 3. It is noted that fig. 3 only shows the computer device 20 with components 21-22, but it is to be understood that not all shown components are required to be implemented, and that more or fewer components may be implemented instead.
In the present embodiment, the memory 21 (i.e., a readable storage medium) includes a flash memory, a hard disk, a multimedia card, a card-type memory (e.g., SD or DX memory, etc.), a Random Access Memory (RAM), a Static Random Access Memory (SRAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a programmable read-only memory (PROM), a magnetic memory, a magnetic disk, an optical disk, and the like. In some embodiments, the storage 21 may be an internal storage unit of the computer device 20, such as a hard disk or a memory of the computer device 20. In other embodiments, the memory 21 may also be an external storage device of the computer device 20, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), or the like, provided on the computer device 20. Of course, the memory 21 may also include both internal and external storage devices of the computer device 20. In this embodiment, the storage 21 is generally used for storing an operating system installed in the computer device 20 and various application software, such as program codes of a Java virtual machine memory monitoring method. Further, the memory 21 may also be used to temporarily store various types of data that have been output or are to be output.
Processor 22 may be a Central Processing Unit (CPU), controller, microcontroller, microprocessor, or other data Processing chip in some embodiments. The processor 22 is typically used to control the overall operation of the computer device 20. In this embodiment, the processor 22 is configured to execute the program code stored in the storage 21 or process data, for example, the program code of the Java virtual machine memory monitoring method, so as to implement the Java virtual machine memory monitoring method.
The present embodiment also provides a computer-readable storage medium, such as a flash memory, a hard disk, a multimedia card, a card-type memory (e.g., SD or DX memory, etc.), a Random Access Memory (RAM), a Static Random Access Memory (SRAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a programmable read-only memory (PROM), a magnetic memory, a magnetic disk, an optical disk, a server, an App application mall, etc., on which a computer program is stored, which when executed by a processor implements corresponding functions. The computer readable storage medium of this embodiment is used for storing a JAVA virtual machine memory monitoring program, and is executed by a processor to implement the steps of the JAVA virtual machine memory monitoring method.
According to the method and the device, when the same JVM runs a plurality of applications (for example, a plurality of applications are deployed in Web containers such as Tomcat, Weblogic and the like) and the memory allocation and use condition of each application is monitored, even if the application runs singly, the memory allocation and use condition is monitored frequently according to URI (for Web applications) or function levels, so that the memory use problem can be rapidly checked and positioned.
It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The above-mentioned serial numbers of the embodiments of the present invention are merely for description and do not represent the merits of the embodiments.
Through the above description of the embodiments, those skilled in the art will clearly understand that the method of the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but in many cases, the former is a better implementation manner. Based on such understanding, the technical solutions of the present invention may be embodied in the form of a software product, which is stored in a storage medium (such as ROM/RAM, magnetic disk, optical disk) and includes instructions for enabling a terminal (such as a mobile phone, a computer, a server, an air conditioner, or a network device) to execute the method according to the embodiments of the present invention.
While the present invention has been described with reference to the embodiments shown in the drawings, the present invention is not limited to the embodiments, which are illustrative and not restrictive, and it will be apparent to those skilled in the art that various changes and modifications can be made therein without departing from the spirit and scope of the invention as defined in the appended claims.

Claims (10)

1. A Java virtual machine memory monitoring method is characterized by comprising the following steps:
intercepting an HTTP request;
recording the request occurrence time of the HTTP request;
acquiring a requestURI and/or contextPath of the HTTP request;
acquiring the size of a first stack of memory accumulatively allocated by the Java virtual machine for the thread corresponding to the HTTP request;
after executing the service code corresponding to the HTTP request, acquiring the size of a second heap memory accumulatively allocated by the Java virtual machine for the thread corresponding to the HTTP request;
determining that a third heap memory size applied and allocated by the requestURI and/or the contextPath to execute the service code is a difference between the second heap memory size and the first heap memory size;
and recording the corresponding relation between the requestURI and/or the contextPath, the request occurrence time and the third heap memory size.
2. The method for monitoring the memory of the Java virtual machine according to claim 1, further comprising:
acquiring the size of a fourth heap memory used by the Java virtual machine in preset time;
and determining the size of a fifth heap memory actually used by the requestURI and/or the contextPath according to the size of the fourth heap memory, wherein the size of the fifth heap memory is in direct proportion to the ratio of the size of the heap memory which is accumulatively applied and allocated by the requestURI and/or the contextPath in the preset time to the size of the heap memory which is accumulatively allocated by the Java virtual machine in the preset time.
3. The method for monitoring the memory of the Java virtual machine according to claim 1, wherein intercepting the HTTP request comprises: the HTTP request is intercepted by the invoke method of Tomcat's request interceptor interface.
4. The method for monitoring the memory of the Java virtual machine according to claim 1, wherein intercepting the HTTP request comprises: and intercepting the HTTP request by a service method of an interception service connector Servlet by utilizing a byte code injection mechanism.
5. The method according to claim 1, wherein the first heap memory size and the second heap memory size are obtained by a com.
6. The method for monitoring the memory of the Java virtual machine according to any one of claims 1 to 5, further comprising:
intercepting a business method corresponding to the HTTP request;
recording the method name and the occurrence time of the service method;
acquiring the size of a sixth heap of memory accumulatively allocated by the Java virtual machine for the thread corresponding to the HTTP request;
before the business method returns, acquiring the size of a seventh heap memory accumulatively allocated by the Java virtual machine for the thread corresponding to the HTTP request;
and determining that the size of the eighth heap of memory applied and allocated by the business method is the difference between the size of the seventh heap of memory and the size of the sixth heap of memory.
7. The method for monitoring the memory of the Java virtual machine according to claim 6, wherein the method for intercepting the service corresponding to the HTTP request comprises the following steps: and intercepting a business method corresponding to the HTTP request through a Java byte code injection mechanism.
8. The method for monitoring the memory of the Java virtual machine according to claim 6, wherein the sixth heap memory size and the seventh heap memory size are obtained by a com.
9. A computer device, characterized in that the computer device comprises:
a memory, a processor, and a computer program stored on the memory and executable on the processor;
the computer program when executed by the processor implementing the steps of the Java virtual machine memory monitoring method of any of claims 1 to 8.
10. A computer-readable storage medium, wherein a Java virtual machine memory monitor is stored on the computer-readable storage medium, and when executed by a processor, the Java virtual machine memory monitor implements the steps of the Java virtual machine memory monitor method according to any one of claims 1 to 8.
CN202010952285.4A 2020-09-11 2020-09-11 Java virtual machine memory monitoring method, computer equipment and storage medium Active CN112148428B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010952285.4A CN112148428B (en) 2020-09-11 2020-09-11 Java virtual machine memory monitoring method, computer equipment and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010952285.4A CN112148428B (en) 2020-09-11 2020-09-11 Java virtual machine memory monitoring method, computer equipment and storage medium

Publications (2)

Publication Number Publication Date
CN112148428A CN112148428A (en) 2020-12-29
CN112148428B true CN112148428B (en) 2021-04-16

Family

ID=73890179

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010952285.4A Active CN112148428B (en) 2020-09-11 2020-09-11 Java virtual machine memory monitoring method, computer equipment and storage medium

Country Status (1)

Country Link
CN (1) CN112148428B (en)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109257449A (en) * 2018-11-22 2019-01-22 四川长虹电器股份有限公司 A method of the Web in Nginx based on URI loads distribution

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9426152B2 (en) * 2014-07-08 2016-08-23 International Business Machines Corporation Secure transfer of web application client persistent state information into a new domain
CN105868079B (en) * 2016-04-21 2019-02-26 中国矿业大学 It is a kind of to use detection method using the Java Memory Low Usage for propagating analysis based on memory
CN107783881B (en) * 2017-09-13 2020-09-25 杭州天翼智慧城市科技有限公司 Website dynamic performance monitoring method and system based on memory queue

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109257449A (en) * 2018-11-22 2019-01-22 四川长虹电器股份有限公司 A method of the Web in Nginx based on URI loads distribution

Also Published As

Publication number Publication date
CN112148428A (en) 2020-12-29

Similar Documents

Publication Publication Date Title
Rellermeyer et al. Concierge: a service platform for resource-constrained devices
US8601469B2 (en) Method and system for customizing allocation statistics
US7774741B2 (en) Automatically resource leak diagnosis and detecting process within the operating system
US7698397B2 (en) Method and framework for providing system performance information
US20040019887A1 (en) Method, system, and program for loading program components
CN111427773A (en) Web application resource monitoring method, electronic device and computer readable storage medium
US20160259712A1 (en) System and method for determination of code coverage for software applications in a network environment
CN114661580A (en) Flow recording playback method and device, computer equipment and storage medium
CN113900896B (en) Method, device, equipment and storage medium for monitoring code operation
CN113722114A (en) Data service processing method and device, computing equipment and storage medium
CN111538483B (en) Data processing method, device, server and readable storage medium
CN112148428B (en) Java virtual machine memory monitoring method, computer equipment and storage medium
CN114006891A (en) Information reporting method, device, equipment and storage medium
US10417121B1 (en) Monitoring memory usage in computing devices
CN112860235B (en) Method, device, equipment and storage medium for processing text
CN115374083A (en) Data source switching method and device, electronic equipment and storage medium
CN111309402A (en) Data monitoring and application program processing method, device and equipment
CN115509861A (en) Process monitoring method, system, computer device and storage medium
CN111176930B (en) Component operation data processing method and device, computer equipment and storage medium
CN111078257B (en) H5 application package loading method and related device
CN112527318A (en) Service processing method and device and online service system
CN111984618A (en) Log compression method and device
CN111488230A (en) Method and device for modifying log output level, electronic equipment and storage medium
EP1221085A2 (en) Method and system for dynamic injection of execution logic into a windowed operating system
CN111352748B (en) Interface calling method and device, electronic equipment and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant