记录一次线上oom问题排查

昨天有小伙伴过来求助，公司的一上线产品最近不规律地出现运行一段时间就宕掉的情况。运维团队已经排查一整天，从服务器环境到最近的release配置等等，始终定位不到问题，客户火冒三丈。

分析过程略坎坷，主要是被误导到了最近才使用的加密工具身上，浪费了点时间，产品和运维也不知道到底是什么样的操作导致的。后来拿到了jvm的dump文件，分析后定位到了这么一段代码：

这是个从云服务上获取文件，并下载的功能。很明显了，问题就在于这byte数组上，一个超大的文件，一次性读入这个数组，就直接导致这个数组去申请超大的heap空间，jvm报出oom，服务不可用。修改代码，改成流对拷的方式，问题解决。

总结下，首先，测试团队没做到位。其次，开发人员写代码的时候，还是不要太随性，得有为每行代码负责的态度，另外leader的代码Reveiw也不能偷懒。