BruceChao5211的博客

近期遇到线上出现504报错，查看gc情况发现频繁oldgc，于是尽快回滚线上代码，然后开始排查问题原因。本期需求中优化了一些数据缓存组件，一度怀疑是这里导致的问题，几经排查还是不能确定。于是在运维老师那里启动了一个容器来部署本期最新代码的服务，并把nacos下线，避免线上流量进入。在容器内部查看内存、CPU信息完全正常，定时任务执行也很正常，于是模拟调用线上接口，一段时间后终于发生了oldGC，查看占用cpu较高的线程为GC线程，dump堆内存进行分析，终于发现了问题所在：前四个线程占用内.

关于String.intern()方法，源码中有很完善的描述 /** * Returns a canonical representation for the string object. * <p> * A pool of strings, initially empty, is maintained privately by the * class {@code String}. * <p> * When t

问题的发现 听云监控显示JVM堆内存老年代经过多次FullGC仍然无法回收，gc次数过多且STW过长，会影响线上业务，暂时联系运维老师重启了服务器（-Xmx4G -Xms4G） 问题排查 通过导出的dump文件分析了解到占用内存最大的对象是alibaba.fastjson的ParseConfig对象及其内部的IdentityHashMap对象，当前现象与测试环境dump结果一致 ParseConfig及IdentityHashMap对象的作用 项目中在使用fastjson进行反序列化的时候会调用p