对于 Metaspace 没有设置 MaxMetaspaceSize 值，导致使用过多，本次问题是因为还没触发 FGC，就 OOM 了。
参考：http://lovestblog.cn/blog/2016/10/29/metaspace/

是的，我在 TCL 呀

1. JMV 内存在 02 段落写清楚了，大概使用了 561MB，还没达到 GC 的条件，所以没继续看；

2. Metaspace 正常情况下，本来就不会被 GC 回收，GC 回收的是堆栈空间；

3. 在解决方案中有提到减少业务的处理数据量，分批处理，减少反射的集中使用。其实在日常的业务代码中，也不提供过多的使用反射，对类的安全性也是个入侵。

4.因为很多代码处理逻辑的底层，使用了反射（包括上面提到的 spring 的 BeanUtils 的拷贝对象，json 的序列化） --没说 BeanUtils 处理 Json，而是说这两个都用到了反射；

感谢讨论。

接口文档完整 --这个基础就有很多团队做不到的。

在有完善的前置条件下，接口自动化当然适合开展，性价比也最高。

交付类的项目，给到工厂部署后，基本上就不会再动了，除非业务的工艺流程发生变化。

而且维护也交付给工厂的 IT 部门了，所以不太适合花时间去搞自动化。

水不水的，大家看着就好，不同水平的人本来知识结构就不一样。可能你懂的多，我的文章不就水了嘛。

不过确实是公众号同步过来的。

流量回放的技术成本更高，更加依赖基础设施。

测试左移其实也是为了更好的做测试，最基本的，左移能够保证你的测试用例是相对更准确和靠谱的。

左移不影响你测试能力的提升。有的人从技术层面去提升，有的人从业务的角度出发。在当下的互联网环境中，可能对技术的提升需求更显著。但是在实业或者制造业，一个慢懂 MES 或者 WMS 业务流的测试，价值远高于会技术的测试。笔者现在就在实业，比较清楚业务的价值。

所以不是所有人都适合 Leader 的，如果只是传声筒的作用，要他干什么。

活可以接，但该出的声音还是得出，能怼的还是得好好说

理论肯定是象和简化了部分场景，大方向上应该是没什么问题的。

缺人的情况下，更得注意做事方法，有些成本还是得花的，比如左移的时间、和开发对齐的时间，主动点。

无非是把时间花在提测前还是提测后。