一、案件背景
近日，一个线上应用开始频繁报警：异常日志、接口rt超时、load高、tcp重传率高等等。现场监控如下：
从基础监控来看，cpu使用率不算特别异常，而load高说明等待cpu资源的线程队列长，配合rt上涨来看，推测是线程出现了堆积，而线程堆积一般有两种情况：
- 线程内部处理耗时变长：比如缓存未命中、被下游请求block、慢sql、循环逻辑耗时等。
- JVM因GC、锁擦除等jvm操作原因触发stop the world，导致线程等待。
下面进一步定位问题。
二、问题定位
线程耗时变长？
因为应用重度依赖缓存，一起排查问题的同学发现tair成功率也有下降，于是找tair同学开始排查。
tair的同学表示集群正常，观察同机房其他应用读写tair也正常，推测问题还是出在应用自身。（其实应用自身负载高时，会引起tair超时和序列化失败，表象来看都像tair有问题，心疼下tair的同学。。。）
另外从db监控来看也没有慢sql出现，近期也没有逻辑改动较大的发布，暂时从其他方向看看。
STW
接下来比较醒目的就是GC监控了，监控如下：
可以看到问题期间GC次数和耗时明显上升，这里需要注意，因为GC监控里CMS(或G1)和Full GC都会归到Full GC里，所以登到机器上看看gc.log。
这里看到Metadata GC Threshold引起Full GC的字样较多，回收情况也很差（382626K->381836K）再通过jstat看下使用情况：
这里看到M区(metaspace)使用率是73.22%，而FGC平均每秒一次，GC前后O区(old gen)变化不大，可以确定是metaspace泄漏导致的Full GC。
值得注意：M区没到100%（73.22%），为什么会频繁触发fullGC呢？原因是classloader加过多时，会引起metaspace的碎片化问题。后面会进一步解释classloader过多原因。
到此，原因可以确定是FullGC伴随的大量STW引起了线程堆积。下面继续定位为什么metaspace会出现泄漏。