这次是测试环境，处理问题的时间比较充裕。同样和之前堆内存溢出一样，arthas attach failure。不同的是这次attach过程报错显示 OutOfMemoryError：Metaspace。
随即想到是不是配置JVM的MaxMetaspaceSize配置过小，查看了下docker-compose.yml，如下：
MaxMetaspaceSize=128M，增加MaxMetaspaceSize的大小当然能解决问题，但是当时时间充裕，还是想找到根本原因，便添加了一些JVM启动参数，重启测试。
一开始想通过-verbose：class参数看看有没什么异常的类加载，无奈没发现什么异常。渐渐的项目直接无响应，登录接口直接超时了，再次用top命令查看后端服务的机器系统性能情况，CPU一直在100%以上，有时甚至达到200%以上。
由于添加了GC日志和OOM的参数，此时gc日志文件和堆dump文件都到手了。第一时间就是去gceasy.io网站上分析了gc日志。
现在可以断定就是元空间内存不足导致的了。接着把dump文件装载入MAT分析看看内存的情况，其中一个problem suspect发现和类加载密切相关
dominator_tree中最大的对象是LaunchURLClassLoader，和类加载也相关，元空间出问题了肯定和类加载相关这个是无需质疑的。元空间在JVM规范中是叫方法区，元空间是HotSpot对JVM规范中定义方法区的实现，JDK8以下中则是叫永久代。
此时根本原因还是没找到，再导入到JVisualVM看看还有什么可利用的信息，观察到线程栈快照日志貌似和nacos以及Grpc有关系：
咨询了一下架构师原来是nacos版本升级了，用新版本的协议是Grpc，可能是新版本需要加载的类比较多，Metaspace空间也就调到了256MB，问题也算是解决了。
参考：Java Virtual Machine Specification
标签：27,MaxMetaspaceSize,内存,JVM,空间,日志,溢出,加载 From： https://www.cnblogs.com/road2master/p/16866742.html