很多同学工作了三四年都不一定遇到OOM，一来是业务逻辑简单，数据量少，二是Java 生态的发展，各种开源的中间件可以帮助提高系统性能。
近期加入一个电商行业特定细分领域一个创业工作，客户数量飞速发展，有些知名大客户会把自己的海量数据放入公司的系统，这就导致线上部分场景会发生OOM。
如果线上OOM 一定要配置dump文件，通过日志结合dump 文件可以迅速定位到问题。
背景
系统中某个重要客户在使用我们提供的行业网盘的时候，对某个文件夹进行了移动操作，类似window 操作系统中 剪切，由于是行业定制化的网盘存储，网盘中不仅仅保存可文件信息，父子关系，还保存了很多 文件的权限、层级、文件特征信息等数据，正是由于这些特征数据导致在文件夹移动的过程中 需要吧所有移动的数据读入到内存，并在内存中处理好移动逻辑，并一次性写到文件存储服务。
之类在把某个大文件夹下所有的子文件读入到内存的过程中导致了OOM
分析工具MAT
首先dump文件的分析工具很多，我选择了经典的MAT
overview 会展示出内存的大概分布情况
这里线上配置了 最小1G 最大2G 的jvm 可以看到基本上 1G的时候就会发生内存溢出（后期分析）
Dominator Tree 支配树
展示内存中对象属性结构分布，这里能清楚看到哪个线程占用的内存
点开线程可以确定具体哪些对象占用了内存
这里有经验的情况下基本可以确定发生oom 时内存中大部分是什么数据
Leak Suspects
Leak Suspects? Leaks? Problem Suspect 1? Description? Thread Stack and Involved Local Variables
这里基本可以确定执行到哪一行代码发生了OOM
以上信息再结合业务逻辑就可以知道在哪些场景下，哪些代码逻辑会发生OOM
OOM 问题分析dump 文件一定要结合业务逻辑，后期解决方案也要在业务逻辑的框架内存解决。