[if !supportLists]1、 [endif]问题现象描述
国际化中台新增文案，编辑文案20用户并发时，部分请求结果返回502 bad geteway错误，
[if !supportLists]2、 [endif]问题定位过程
2.1、初步怀疑是nignx服务器问题，查看nignx日志，定位是后端应用报错
[if !vml]
[endif]
2.2、查看if-zaif-cps-copywriting-agent-mock-dev应用服务器有重启记录。
确认是在重启时，请求返回失败。
[if !vml]
[endif]
2.3、再查看重启原因是因为内存资源消耗完，日志存在OutOfMemoryError的报错信息，容器对服务进行的重启。
[if !vml]
[endif]
2.3、分析内存资源耗尽的原因，在Linxu后端使用命令查看内存GC情况
Jstat -gcutil 6 1000
[if !vml]
[endif]
结果分析，E — Heap上的 Eden space 区已使用空间的百分比消耗非常快，不停进行YGC，但是内存基本不释放。待old区内存百分比被占满后开始Full gc，不能释放内存，多次尝试FULL gc仍不能释放内存，容器重启该服务。
[if !supportLists]3、 [endif]问题分析过程
3.1、使用—命令生成dump文件。对内存进行分析
jmap -dump:format=b,file=/tmp/dump.dat PID或jmap-dump:live,format=b,file=aaa.hprof 22400
3.2、down到本地后使用MAT工具对dump文件分析
[if !vml]
[endif]
初步定位内存泄漏的代码位置
3.3、在Leak
Suspects页面会给出可能的内存泄露，进入Leak Suspects，查看那些类可能发生内存泄露
[if !vml]
[endif]
点击Details发现有自己的代码。
[if !vml]
[endif]
3.4、线程池的问题，进入Details查看详情：
在详情页面Shortest Paths To the Accumulation
Point表示GC root到内存消耗聚集点的最短路径，如果某个内存消耗聚集点有路径到达GC root，则该内存消耗聚集点不会被当做垃圾被回收
[if !vml]
[endif]
查看前面占用大的class
[if !vml]
[endif]
如果类的Objects占用很大，极可能就是这里的问题。
[if !vml]
[endif]
[if !supportLists]4、 [endif]问题解决方案
[if !vml]
[endif]
[if !vml]
[endif]
如上只是修改其中一个可能存在性能问题的代码
[if !supportLists]5、 [endif]优化后结果
具体问题暂未彻底优化，当前性能结果满足生产业务量，且存在双实例，不影响生产业务，对生产环境进行监控观察后根据情况再审视是否再次优化。
