前段时间跳槽了，刚入职没3、4个月，我所在的小组次要负责DSP零碎，我主攻DSP中的dist-orders服务
先说一下DSP是干嘛的，项目组所在的公司次要是从事医药行业的，在淘宝、天猫、京东......很多渠道都有自家的店铺，他们本人还有一套ERP，次要是进销存那一套，DSP就是负责连贯ERP和各个渠道之间传递信息的，什么订单啦、库存啦......
前几周，leader收到线上某某某个机子系统OOM的邮件，leader就顺手丢给我，让我去没事的时候去查查
那我间接登堡垒机去服务器上看看，各种乌七八糟命令就开始用，什么top、jstack、jinfo、jstat、jmap...后果发现一个都不行，不是命令不行，是我没权限查看......
不说我只不晓得该申请什么样子的权限，就算是晓得了，运维也曾经重启完了，那还查个屁
最终心愿只能放在堆转储文件上，堡垒机是能够下载服务器上的文件，奈何文件太大，6G多，基本下不下来，寻求运维组的共事帮忙，各种发邮件、拉群、最终在我的软磨硬泡下，终于是给到了我
废话不多说，间接上jdk自带的jvisualvm软件进行剖析，（jvisualvm在你装置jdk的bin目录下）
交给jvisualvm进行解析剖析，我电脑是16G内存，剖析6G的堆转储文件，差点没给我电脑送走......
这里除了导致OOM线程 和 零碎属性之外 没什么太重要的信息
点开 显示零碎属性 发现JVM也没设置什么参数（最大堆、最小堆、GC一些参数等等）
咱们来看 类
发现char[]和String占了大头，双击char[]，进去看看
emmm，不晓得怎么回事有的中央是乱码，而且临时也没看到有用的信息
点过去点过来，看了良久，最终决定换个软件
用IBM heapanalyzer试试（下载地址：https://www.ibm.com/support/pages/node/1109955?mhsrc=ibmsearch_a&mhq=heapanalyzer）
是个jar包，间接java -jar -Xmx15g xxx.jar启动（这里的-Xmx多少内存本人定，如果剖析过程中OOM就是你给的内存太少），或者你能够轻易写个启动的脚本
将堆转储文件载入进来，最终就是这个样子了
他这里有个 疑似泄露的点，是DisOrderItemBO对象，占了2.8G内存，约58.74%
再往后下看ArrayList，大概猜想就是ArrayList装载了太多的DisOrderItemBO
让他以树结构模式展现：
没跑了，就是ArrayList汇合内DisOrderItemBO元素太多，看解析是有1936459个DisOrderItemBO的实例，总共占用了2G多内存
看似失去后果了，实则还是不晓得从哪下手，因为DisOrderItemBO用到的中央太多了，基本不晓得是哪个中央引发的
于是，我又又又换了一个软件
MemoryAnalyzer（下载地址：https://www.eclipse.org/downloads/download.php?file=/mat/1.12.0/rcp/MemoryAnalyzer-1.12.0.20210602-win32.win32.x86_64.zip）
加载进来就是这个样子了
这里也有一个 疑似内存透露的点，点击去查看，列出了具体的信息：
首先是哪个线程呈现的问题，其次是哪些对象导致的内存增长且回收不掉
发现和上一个软件剖析的后果差不多，都是ArrayList汇合内DisOrderItemBO元素太多
当初是已知DisOrderItemBO对象产生的太多(在一个线程内)，且回收不掉，ArrayList间接就摈弃掉了，因为他自身没问题，只是承载了太多的DisOrderItemBO对象，当初我只须要晓得是哪个线程，刚好这个软件能够看（或者前两个也能看，我没找到吧）
http-nio-7210-exec-9线程，我没记错的话，应该是Tomcat工作线程池的线程吧，当初又能够确定一件事，就是导致OOM的必定不是零碎中的异步工作或者是什么JOB等等，其实这里曾经给出了答案，怪就怪在我懒，没往下持续看
线程信息外面给出了我的Service绝对应的类的全包名以及对应的controller的全包名
依据信息间接找到代码，略微捋了一下代码逻辑，在本地启动试试，我去线上日志摸了一个申请报文，用postman申请一下，试了几次怎么玩都不会呈现很多DisOrderItemBO对象
而后我就想，如果参数为空（本来代码就不会对必填参数校验），我就试了一下，控制台打出sql之后，我拿着去线上DB中执行这个sql
去掉不必要的查问列，以及排序，只看个数（一条数据对应一个DisOrderItemBO示例），同理如果查出来了后面剖析的1936459个示例，那么就对上了
为了谨严，我在where条件多了一个创立工夫，工夫截止到这个堆转储文件产生的前10分钟（产生OOM时产生的堆转储文件会很慢）后果查问进去了1936374个条数据，尽管没对上，然而误差也没有很多，当初看来，大差不差就是这里除了问题了
尽管找到了，然而疑难点是，这个接口是查问订单详情，在页面上操作不应该呈现没有必填参数（订单主体ID）的状况呀，这个疑难我始终没想通......
如果过了几周半个月的，我没有更新后续持续排查的文章，就阐明曾经把这个问题完满解决了