Reprinted: https://blog.csdn.net/x_i_y_u_e/article/details/51137492
1. Why does memory leak occur?
How does java detect intrinsic leaks? We need some tools to detect and find memory leaks, otherwise downtime problems are prone to occur.
The most convenient place to write a java program is that we do not need to manage the allocation and release of memory, everything is handled by the jvm, when the java objects are no longer used, when the heap memory is not enough, the jvm will perform garbage collection to clear the occupation of these objects If the object is always used, the JVM cannot recycle it. When creating a new object, it cannot obtain enough memory from the Heap to allocate it to the object, which will lead to memory overflow. Where memory leaks occur, objects are generally stored in the container, and the container has no corresponding size limit or clearing mechanism. It is easy to cause memory overflow.
When the server application occupies too much memory, how to quickly locate the problem? Now, with the advent of Eclipse MAT, this problem has become very simple. EclipseMAT is a tool contributed by the well-known SAP company, which can be downloaded from the Eclipse website, completely free of charge.
To locate the problem, first you need to get a memory snapshot of the server jvm at a certain moment. The jmap that comes with jdk can get a snapshot of the memory at a certain time. After exporting it as a dmp file, you can use Eclipse MAT to analyze it and find out which object uses too much memory.
2. The phenomenon of memory leak:
Often, the first sign of a program memory leak occurs after an error, getting an OutOfMemoryError in your program. This typically happens in a production environment, where you want as few memory leaks as possible and the possibility of debugging to a minimum. Maybe your test environment and the system environment of the product are different, and the leak will only be exposed in the product. In this case, you need a low-load tool to monitor and find memory leaks. At the same time, you also need to link the tool to your system without restarting it or mechanizing your code. Perhaps more importantly, when you're doing analysis, you need to be able to separate from the tool so that the system doesn't get disturbed.
An OutOfMemoryError is often a sign of a memory leak, and it is possible that the application is indeed using too much memory; at this point, you can neither increase the size of the JVM's heap nor change your program so that it uses less memory. However, in most cases, an OutOfMemoryError is a sign of a memory leak. One solution is to keep monitoring GC activity to see if memory usage increases over time, and if so, there must be a memory leak in the program.
3. Find memory leaks
1. jstat -gc pid
Can display gc information, check the number of gc, and time.
The last five items are the number of young gc, the time of young gc, the number of full gc, the time of full gc, and the total time of gc.
2.jstat -gccapacity pid
It can display the usage and size of the three generations (young, old, perm) objects in the VM memory,
For example: PGCMN shows the minimum perm memory usage, PGCMX shows the perm maximum memory usage,
PGC is the current newly generated perm memory usage, PC is the previous perm memory usage.
Others can be analogized according to this, OC is the pure occupancy in old.
3.jstat -gcutil pid
Statistics gc information statistics.
4.jstat -gcnew pid
Information about young generation objects.
5.jstat -gcnewcapacity pid
Information about young generation objects and their occupancy.
6.jstat -gcold pid
Information about the old generation object.
7.stat -gcoldcapacity pid
Information about old generation objects and their occupancy.
8.jstat -gcpermcapacity pid
Information about the perm object and its occupancy.
9.jstat -class pid
Displays information such as the number of loaded classes and the space they occupy.
10. jstat -compiler pid
Displays information such as the number of VM real-time compilations.
11.stat -printcompilation pid
Information about the current VM execution.
Chinese explanation of some terms:
S0C: The capacity of the first survivor (survivor area) in the young generation (bytes)
S1C: The capacity of the second survivor (survivor area) in the
young generation (bytes) S0U: The first survivor (survivor area) in the young generation ) currently used space (bytes)
S1U: currently used space of the second survivor (survivor area) in the
young generation (bytes) EC: capacity of Eden (Eden) in the young generation (bytes)
EU: in the young generation Eden (Eden) currently used space (bytes)
OC: Old generation capacity (bytes)
OU: Old generation currently used space (bytes)
PC: Perm (persistent generation) capacity (bytes)
PU: Perm (Persistent Generation) Currently used space (bytes)
YGC: The number of gcs in the young generation
from the application startup to the sampling time YGCT: The time from the application startup to the sampling time for the GC in the young generation (s)
FGC: From the application startup Up to the sampling time of the old generation (full gc) GC times
FGCT: the time from the application startup to the sampling time old generation (full gc) gc (s)
GCT: from the application startup to the sampling time The total time used by gc (s)
NGCMN: Initialized (minimum) size (bytes) in young generation (young)
NGCMX: young generation (young) maximum capacity (bytes)
NGC: current capacity (bytes) in young generation
OGCMN: initialized (minimum) size in old generation (bytes)
OGCMX: the maximum capacity of the old generation (bytes)
OGC: The current newly generated capacity of the old generation (bytes)
PGCMN: Initialized (minimum) size in perm generation (bytes)
PGCMX: Maximum capacity of perm generation (bytes)
PGC: The current newly generated capacity of the perm generation (bytes)
S0: The percentage of the current capacity used by the first survivor (survivor area) in the young generation
S1: The percentage of the current capacity used by the second survivor (survivor area) in the young generation
E: The percentage of the current capacity used by Eden (Eden) in the young generation
O: The percentage of the current capacity used by the old generation
P: The percentage of the current capacity used by the perm generation
S0CMX: The maximum capacity of the first survivor (survivor area) in the young generation (bytes)
S1CMX: The maximum capacity of the second survivor (survivor area) in the young generation (bytes)
ECMX: Maximum capacity of Eden in young generation (bytes)
DSS: The capacity (bytes) of the survivor (survivor area) currently required (the Eden area is full)
TT: Hold times limit
MTT: Maximum number of holdings limit
If I locate the memory leak problem, I usually use the following command:
Jstat -gcutil15469 2500 70
[root@ssss logs]# jstat -gcutil 15469 1000 300
S0 S1 EOP YGC YGCT FGC FGCT GCT
0.00 1.46 26.54 4.61 30.14 35 0.872 0 0.000 0.872
0.00 1.46 46.54 4.61 30.14 35 0.872 0 0.000 0.872
0.00 1.46 47.04 4.61 30.14 35 0.872 0 0.000 0.872
0.00 1.46 65.19 4.61 30.14 35 0.872 0 0.000 0.872
0.00 1.46 67.54 4.61 30.14 35 0.872 0 0.000 0.872
0.00 1.46 87.54 4.61 30.14 35 0.872 0 0.000 0.872
0.00 1.46 88.03 4.61 30.14 35 0.872 0 0.000 0.872
1.48 0.00 5.56 4.62 30.14 36 0.874 0 0.000 0.874
1000 represents how often the interval is displayed,
100 means display once.
S0 — Survivor space 0 area on the Heap is the percentage of used space
S1 — Percentage of used space in Survivor space 1 area on the Heap
E — The percentage of used space in the Eden space area on the Heap
O — The percentage of used space in the Old space area on the Heap
P — Perm space used space percentage
YGC — The number of times Young GC occurred from application startup to sampling time
YGCT – The time (in seconds) spent by Young GC from application startup to sampling time
FGC — the number of times a Full GC occurred from application startup to sampling time
FGCT – Time from application startup to Full GC when sampling (in seconds)
GCT — total time (in seconds) used for garbage collection from application startup to sampling
If there are a large number of FGCs, it is necessary to check whether there is a memory leak problem. The number of FGCs in the figure is relatively large, and the execution time is long, which will lead to a long system response time. If the memory setting of the jvm is large , then the time to perform an FGC may be longer.
If in order to better prove the impact of FGC on server performance, we can use java visualVM to take a look:
From the above figure, it can be found that there is no FGC before 3:10 pm, and then a large number of FGCs appear.
The above picture shows the usage of jvm heap memory. The memory recovery before 3:10 pm is reasonable, but after that, a large amount of memory cannot be recovered, which eventually leads to less and less memory, resulting in a large amount of full gc.
Let's take a look at the impact of a large number of full GCs on server performance. Below is a screenshot of the corresponding time I used loadrunner to stress test our project:
It can be seen from the figure that after the full GC, the corresponding time of the system has increased significantly, and the click rate and throughput have also decreased significantly. Therefore, the impact of Java memory leaks on system performance cannot be ignored.
3. Locate memory leaks
Of course, through the above methods, we can find the memory leak problem of java, but as a qualified senior engineer, I am definitely not willing to hand over such a conclusion to the development. Of course, this conclusion is also handed over to the development, and the development is difficult to locate. Question, in order to better provide our own status in the company, we must provide development engineers with more in-depth test conclusions. Let's get to know MemoryAnalyzer.exe. Java memory leak checking tool tool.
First of all, we must dump the jvm heap memory. Only by getting this file can we analyze what is stored in the jvm heap memory and what is it doing?
I will not explain the users of MemoryAnalyzer one by one here, and there are also instructions in my blog. The following is a successful picture of my test:
The dark blue part is the part of the memory leak. The heap memory of java is only 481.5M in total, and the part of the memory leak occupies 336.2M alone, so the memory leak this time is obvious, then I will take a look at the memory caused by that method. leakage:
From the above figure, we can find that the method circled in red occupies 67.75% of the heap memory. If we can hand over the test results to the development, the development should be well positioned. So as a senior test engineer, we have a lot to learn.
Although it is not sure that it must be a memory leak, it can accurately tell the cause of the development problem, which is convincing.
I have just completed the training and learning of cloud storage architects
Reprinted from: http://blog.csdn.net/gzh0222/article/details/8538727
Reference memory analysis tools: http://blog.csdn.net/fenglibing/article/details/6411953