This article Source: Byte view, is the second contributor grandfather students
Problems
Occasionally latest new on-line system will be reported FullGC long time (> 1s) of the alarm log view GC, as shown below:
See GC log, I at first was not time-consuming GC, GC reasons but triggering: the Metadata GC Threshold
That is the reason FullGC triggered because the GC Metaspace size reaches a threshold. In the monitoring system which looked at Metaspace size trends, as shown below:
According to past experience, Metaspace in operation for some time after the system is stable space should be relatively stable fishes, but from the map view, Metaspace clearly showed substantial fluctuations. why?
related information
We know that the metadata Metaspace main storage class, such as we loaded a class, the class information will be according to certain data structures stored in Metaspace in.
The size and number of Metaspace loaded class has a lot more loaded class, the greater the Metaspace take up memory.
Metaspace outer space is allocated in the heap, the default maximum space is only limited by the physical memory system. The more important it is saying two JVM parameters related to:
-XX:MetaspaceSize -XX:MaxMetaspaceSize复制代码MaxMetaspaceSize, we would have guessed from the name refers to Metaspace maximum.
And MetaspaceSize may be more misleading as Metaspace minimum, in fact, it refers to the initialization trigger threshold FullGC when Metaspace expansion.
Metaspace will be dynamically adjusted after GC: GC if this release a lot of space, then it appropriate to reduce the value, if it is appropriate to release less space to increase this value, of course, its value is not greater than MaxMetaspaceSize.
Another related knowledge is: what conditions Metaspace the class needs to meet to be able to be treated as garbage is unloaded recovered?
Condition is quite severe, the need to meet the following three conditions of the class will be uninstalled:
All instances of this class have been recovered;
ClassLoader loaded class has been recovered;
Corresponding to the class java.lang.Class object is not referenced anywhere.
Investigation process
We can go back and re-look GC logs can be seen Metaspace memory used in the FullGC significantly smaller (372620K -> 158348K), explained Metaspace FGC after unloading a lot of class.
From this point of view, we have reason to suspect that the system may generate a large number of frequently "one-off" category, resulting in Metaspace occupied space is growing, it grows to GC threshold trigger FGC.
So what are these recycled class is it?
In order to clarify this point, I increased the load to observe the following two classes JVM startup parameters, uninstall information:
-XX:TraceClassLoading -XX:TraceClassUnloading复制代码The addition of these two parameters, the system is run for some time, we found that a large amount of logs from the following catalina.out Tomcat log in:
This is almost certain Metaspace growth is the culprit of these classes, these classes
sun.reflect.GeneratedSerializationConstructorAccessorXXX
Why is it? Where is the introduction to it? I also look ignorant to force ~ ~
According to Google the name of a class, find the @ Cold Spring child wrote, "comes from the reflection principle with GC murder," the article to explain the source of these classes are very thorough. Here I briefly summarized as follows:
Method method = XXX.class.getDeclaredMethod(xx,xx);method.invoke(target,params);复制代码These classes are the source of reflection, reflection code similar to that shown above everyone should have written or read, we used most frameworks such as Spring, Dubbo and so extensive use of reflection.
For performance reasons, the JVM will after a certain number of reflection code execution, by dynamically generating classes to be "reflected calls" to "non-reflective call", to achieve better performance. And Examples of these classes are dynamically generated by the soft reference SoftReference referenced.
We know that an object only soft references SoftReference, if memory space is insufficient, will reclaim the memory of these objects; if enough memory, the garbage collector does not reclaim it. As long as the garbage collector does not reclaim it, the object can be used.
So, what at what time will it be recycled?
SoftReference clock has a global variable representative of the last time point GC, there is a timestamp attribute, at each visit SoftReference, will be provided through the clock timestamp value.
When GC occurs, the following factors affect whether an object is recovered SoftReference references:
SoftReference how long the object instance is not accessible by clock - timestamp about how objects come from lack of access;
Memory size of the free space;
SoftRefLRUPolicyMSPerMB constant value;
SoftReference whether to keep the reference object is determined with reference to expression, true is not recycled, false is recovered:
clock - timestamp <= freespace * SoftRefLRUPolicyMSPerMB复制代码Description:
Clock - timestamp : the difference between the last time and GC SoftReference timestamp of the object instance attribute. This is probably how SoftReference reference object Kumi visited the
FreeSpace : JVMHeap free space size, in MB.
SoftRefLRUPolicyMSPerMB : SoftReference objects per 1M free space can maintain the survival of the length of time (in ms). This parameter is a constant, the default value 1000, by parameters: -XX: SoftRefLRUPolicyMSPerMB set.
We see a bit JVM system configuration parameters, we found that the SoftRefLRUPolicyMSPerMB set to 0, and thus leading to a soft reference object was quickly recovered. Leading to dynamic class need be regenerated frequently.
In order to verify this hypothesis, I SoftRefLRUPolicyMSPerMB into a 6000 observation, found that indeed was right.
Metaspace use of space essentially unchanged soon after the system is up and running again after a few days did not appear because Metaspace size reaches a threshold trigger FGC. So far the problem is solved.
References
False stupid to say - it comes from the reflection principle with GC murder:
https://mp.weixin.qq.com/s/5H6UHcP6kvR2X5hTj_SBjA?
Java's strong references, soft references, weak references, phantom references and usage scenarios:
http://blogxin.cn/2017/09/16/java-reference/
END
Personal Public Number: Huperzine architecture notes (ID: shishan100)
Welcome to long press the map No public concern: the architecture of huperzine notes!
No reply public background information , access to exclusive secret of learning materials
Huperzine architecture notes, BAT architecture experience purse