In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-01-16 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Internet Technology >
Share
Shulou(Shulou.com)06/01 Report--
This article mainly introduces java dependency package abuse System.gc() caused by frequent Full GC how to do, the article is very detailed, has a certain reference value, interested friends must read!
introduced
A colleague in the business department had a strange Full GC problem, where a service migrated to a new application and had frequent Full GC. The configuration of the new application machine is 4c 8g, the old application is 4c 4g, the old application GC is very normal, and the code has not changed, so it is strange.
phenomenon
The problem phenomenon is that there has been a large number of Full GC from the monitoring chart.
investigation
When encountering this problem, it is generally first to look at the memory occupation of each area:
Old Gen, Young Gen and Perm Gen can be seen from the monitoring chart. There is no problem and Full GC will not be triggered. Of course, whether each Gen will trigger Full GC needs to be seen in combination with JVM parameter configuration.
By the way, I also looked at the GC log, which has been violent CMS GC log, and you can see that the space used in the old age is not large, carefully you can find that a large number of CMS GC are mixed with the recovery of Young and Perm areas, so it is actually Full GC. GC logs are as follows:
JVM parameter configuration for older applications
JVM Parameter Configuration for New Applications
Based on the above observations, there are several possibilities for triggering CMS GC in general:
Old Gen uses a certain ratio, the default is 92%, here see CMSInitiatingOccupancyFraction=80%, but the actual use of less than 2%(see the monitoring chart), so exclude this situation.
CMSClassUnloadingEnabled is configured, and the usage rate of Perm Gen reaches a certain level. The default is 92%. Here, CMSInitiatingPermOccupancyFraction=80%, but the actual usage rate is less than 30%(see the monitoring chart), so this situation is excluded.
System.gc() is called when ExplicitGCInvokesConcurrent is configured and DisableExplicitGC is not configured.
Hotspot itself decides whether to violate laws based on estimates, such as CMS pessimism, which can be analyzed by GC logs.
It is likely that System.gc() caused the problem, but how to locate the code that called System.gc()? At that time, I thought that if it was a frequent Full GC caused by System.gc(), the jstack thread stack should be able to see some information, and sure enough, it was indeed found through the thread stack.
Jstack has a very large effect, many problems can be found here, and it is relatively lightweight and has no impact on the application. A certain jstack information only represents the thread stack at that time. Sometimes you can only see a jstack information and you may not see any problems. Generally, you can jstack several times more, and then compare it to see that you can basically find some problems. (Of course, this problem may not be frequent Full GC, it may not be located by jstack, you can jstat -gccause pid 1000 to see the gc cause.)
Obviously, the problem is caused by the close method in the jxl package showing calls to System.gc().
Following the code, naturally there is this code, but there is a setting switch that can disable this function, so when you use it, you can set setGCDDisabled (true) to turn off the trigger System.gc().
But why is there no problem with the old application, mainly because it-XX:+DisableExplicitGC, shielding the System.gc() action, the new application JVM does not have this configuration.
We all know that System.gc() triggers Full GC, so why keep doing CMS GC (via GC logs)? Mainly because of this parameter-XX:+ExplicitGCInvokesConcurrent, after opening this parameter, parallel Full GC will be done, only when the parameter-XX:+ UseConcepMarkSweepGC is configured, this parameter will take effect. Therefore, CMS GC will be performed in the Old zone when System.gc(), which can improve Full GC efficiency.
The above is "Java dependency package abuse System.gc() caused by frequent Full GC how to do" all the content of this article, thank you for reading! Hope to share the content to help everyone, more relevant knowledge, welcome to pay attention to the industry information channel!
Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.