首先是通过一段时间( jmap -heap, jmap -histo:live)观察老年代内存的不断增长,查看（jstat ）gc的情况
原本以为是修改之后内存占用多,堆内存由原来的1G修改为现在的2G,后来发现依然出现内存溢出
进行dump( jmap -dump:live,file=./web_01_202007110930_dump.hprof pid)进行dump线上内存快照,然后使用的是Eclipse的一个插件,这里下载了一个单独版进行分析MemoryAnalyzer,查出问题所在,分析图见下面;
找到内存泄露点,分别为Redirect的动态参数如return “redirect /?userId=111”,后面的参数是动态的,这样Springmvc中间在解析视图的时候会做一个缓存,也会把后面的参数进行缓存,这样每次缓存的路径大部分都是不一样的,时间久了就可能导致内存泄露的问题,晚上也找到的不同的解决方案,最终采用的是该代码的其中一种方案；这里随便从网上搜了一个连接丢到这了
还有一个点就是观察有一个异常ConnectException异常在不停的增加,通过Dump发现是MQ的连接的异常,刚开始项目引进了Rabiitmq但是没有开启Rabbitmq配置,启动还没有报错,但是在Dump中却发现连接Mq的异常不停的增加,（期间使用SpringBoot的排除RabbitMq的自动配置,删除掉Mq的配置,问题重现）,最后通过依赖关系查出猫腻,发现zipkin链路追踪中需要RabbitMq的连接;zipkin可以有选择的http,rabbitnq与zipkin进行通信,这里可以配置通信方式为http，我这边直接把zipkin的依赖暂时去掉了,其他方式自测,这里丢一个链接是解决此方式的方法
修改Redirect其他跳转方式之后,去掉zipkin依赖之后,问题解决,老年代内存平稳,不在持续增加到很高,并没有在此出现内存溢出;