记一次OOM排查
项目测试环境正常，预发OOM，这究竟是道德的沦丧还是……
新建的项目上预发没多久以后，接口就报了Handler dispatch failed; nested exception is java.lang.OutOfMemoryError: Metaspace，然后疯狂GC；
很奇怪，预发环境分配的是1G内存，metaspace是128M，测试环境会更小，但是测试环境跑了那么久也没出现过问题，预发一上就出了个OOM。
立马让运维dump，但是看了dump文件，没发现异常，没有大对象，也没有异常的加载。
心下一沉，想到了第一次遇到线上CPU打满的那次，也是dump文件下来没发现任何问题，顶多就是不断在打日志，日志内容也没啥问题，最后实在是查不出来，只能无脑加机器。
这回赶紧让运维加了机器的配置，然后就没出什么问题了，当然也有可能是预发的流量本就不大。
那么问题就来了，为什么测试环境更小的配置，但是没出现OOM的问题呢？ 询问运维得知，我们测试环境是用k8s部署的，JVM使用的是默认的配置，一个项目大概分配500～900M，排查陷入了僵局。
后经同事提醒，查询发现JDK1.8对于Metaspace的max的默认值就是无穷大
再找了大佬帮忙查了测试环境现在 Metaspace 的使用量，发现基本在128M徘徊，至此，原因终于找到了。
总的来说。
测试环境 用的k8s，走的默认配置，JDK1.8对于Metaspace的max的默认值就是无穷大，所以不会出现 Metaspace OOM的情况。
预发环境 在请求不是很多的情况下，Metaspace能达到100M以上，所以预发配置的128M很快就满了。
