1
2
3
4
5

-XX:NewSize=5242880 -XX:MaxNewSize=5242880 -XX:SurvivorRatio=8 
-XX:InitialHeapSize=10485760 -XX:MaxHeapSize=10485760 
-XX:PretenureSizeThreshold=10485760 
-XX:+UseParNewGC -XX:+UseConcMarkSweepGC 
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:gc.log

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

jstat -gc PID
参数说明：
S0C：这是From Survivor区的大小
S1C：这是To Survivor区的大小
S0U：这是From Survivor区当前使用的内存大小
S1U：这是To Survivor区当前使用的内存大小
EC：这是Eden区的大小
EU：这是Eden区当前使用的内存大小
OC：这是老年代的大小
OU：这是老年代当前使用的内存大小
MC：这是方法区（永久代、元数据区）的大小
MU：这是方法区（永久代、元数据区）的当前使用的内存大小
YGC：这是系统运行迄今为止的Young GC次数
YGCT：这是Young GC的耗时
FGC：这是系统运行迄今为止的Full GC次数
FGCT：这是Full GC的耗时
GCT：这是所有GC的总耗时

1
2
3
4

很多社交APP,日活百万用户，在晚高峰时，QPS很高。
而流量最大的模块，无非就是陌生人的个人主页，类似朋友圈之类的功能。
我们都知道一般这种肯定设置的是缓存，但是问题是这些数据都是比较大的，比如一个人发布了一些感悟，等等之类的。
这些数据都是比较大的。个人信息页展示的信息也是比较完全的。这些数据我们先预估5M.

1
2
3
4
5
6
7

由于参数设置错误，导致线上gc日志  
【Full GC（Metadata GC Threshold）xxxxx, xxxxx】
频繁清空元数据区，而这个区是存放一些加载类的信息的。
通过jstat，或者其他可视化工具
看起来Metaspace区域的内存呈现一个波动的状态，他总是会先不断增加，达到一个顶点之后，
就会把Metaspace区域给占满，然后自然就会触发一次Full GC，Full GC会带着Metaspace区域的垃圾回收，
所以接下来Metaspace区域的内存占用又变得很小了。