Java加载图片触发java.lang.OutOfMemoryError错误排查求助

排查程序运行异常时始终无法定位问题根源，目前已知该错误由部分图片体积过大、系统无法为其分配足够内存触发，但耗时多日排查仍未找到具体是哪张图片导致错误抛出，对应错误堆栈信息如下：

java.lang.OutOfMemoryError: 

• 在所有图片加载、解码的入口处加前置日志，记录当前待处理图片的来源路径、磁盘文件大小、原始宽高，同时按当前使用的位图格式计算解码后预估内存占用（比如常用的ARGB_8888格式单像素占4字节，内存占用=宽高4）。日志同时打在加载启动、加载失败两个节点，OOM触发前最后一条被记录的图片，就是导致问题的目标文件。
• 给图片解码逻辑加块级异常捕获，在OOM触发的catch逻辑里，直接把当前正在处理的图片全量上下文信息（路径、尺寸、来源）随异常堆栈一起输出，之前定位不到问题的核心原因是原始异常栈没有携带业务上下文，补完这层信息后不需要额外排查，异常抛出时就能直接拿到问题图片信息。
• 本地复现时把JVM堆内存参数调至生产环境堆大小的1/2甚至更低，放大内存不足的触发概率，不需要跑全量业务流程，只要遍历所有会加载图片的页面/功能点，通常几分钟就能复现问题，比在线上蹲日志效率高很多。
• 直接批量扫描所有业务涉及的图片存储路径（包括项目内置静态资源、用户上传目录、缓存目录），把宽高超过业务常规阈值的文件先筛出来——比如普通业务场景下的头像、内容配图宽高超过4096像素的，基本都是未做压缩的原图，这类图哪怕磁盘大小只有几MB，解码后内存占用也可能达到上百MB，是触发这类OOM的最高频原因。

注意：不要仅凭磁盘文件大小判断图片是否会触发OOM，高压缩率的JPG、WebP格式文件磁盘占用很小，但解码后的位图内存占用和同尺寸的无压缩位图完全一致，这是多数人排查这类问题时最容易漏的点。

内容的提问来源于stack exchange，提问作者Elparaguas