您好，这里是「码农镖局」掘金小站，欢迎您来，欢迎您再来～
在互联网大厂中，对每天亿级流量的日志进行清洗、整理是非常常见的工作。在某个系统中，需要对用户的访问日志做脱敏处理，也就是清洗掉姓名、身份证号、手机号等个人隐私信息后在保存到数据库中或者交付给其他应用使用。
系统的设计者是直接从kafka中获得的日志数据，再交由清洗系统进行处理。结构图是在这样的：
一段时间后，发现系统运行越来越慢，还出现了卡顿现象。经过调取GC日志文件后发现，业务代码中出现了大量的递归操作。于是又通过MAT工具分析OOM快照，定位递归代码产生的地方。最终，得出的结论是：递归调用次数并不是很多，几十次而已，完全在合理范围内。但递归所创建的总的char\[\]数组大小1G左右。由此可知，并不一定全是代码问题。继续顺着问题往下查，通过排查JVM参数的设置，发现JVM的堆内存设置过小，仅有1G，而且年轻代内存也过小。这才导致系统频繁卡顿，原来是在不停地执行GC。
所以，解决方案就非常明确了。
该系统部署在Tomcat中。解决了年轻代的问题没过多久，又出现了经常假死，但过一会又能正常访问。这就有点让人费解了。起初以为是硬件资源不足，所以使用top命令检查机器资源使用情况。针对机器配置（4C8G）和资源状况（1%CPU和50%+RAM）对系统问题进行初步排查定位。然后用通过jstat分析，没有发现新的OOM和异常的GC。通过导出内存快照，使用MAT进行分析，最终发现有太多的ClassLoader，而且每个ClassLoader都加载了大量的byte\[\]数组。原来，为了在系统启动时就做一些业务上的干预，开发工程师对ClassLoader做了一些自定义的修改而没有顾忌对性能的消耗。因此，解决方案也非常简单：
1、修改自定义ClassLoader的加载方式；
2、限制ClassLoader的创建数量。
再来稍微回顾一下：
GC问题定位一般会采取：
1、分析GC日志；
2、使用jstat工具；
3、使用jmap工具。
而OOM问题的分析解决，则一般会采取：
1、线上系统监控；
2、用MAT工具。
这两种方法来解决。
感谢您的大驾光临！欢迎骚扰，不胜荣幸～