这是典型的堆内存暴死，由视频二进制数据误入本地缓存导致；应立即禁止视频key写入堆缓存，改存元信息并用mappedbytebuffer等零拷贝方式处理。
这种情况属于典型的堆内存溢出，不是缓慢泄漏，而是“暴死”——几秒内耗尽堆空间、GC 失效、JVM 直接抛 java.lang.OutOfMemoryError: Java heap space 并崩溃。关键在于：**视频二进制数据本不该进堆，更不该进多级缓存的本地层（如 Caffeine、Guava Cache 或静态 HashMap）**。
确认是否真由视频二进制导致暴死
别猜，先验证：
- 查日志开头几行：看 OOM 报错前最后几条业务日志，是否刚处理过视频上传/预览/转码请求？是否有类似
loadVideoBytes("xxx.mp4")的调用痕迹 - 看错误堆栈位置：OOM 异常抛出点是否在缓存 put 操作附近？例如
LocalCache.put(...)、ConcurrentHashMap.put(...)或自定义缓存 wrapper 的cacheVideo(...) - 用
jstat -gc <pid></pid>在崩溃前快速观察：Eden 区几乎瞬时填满、YGC 频率飙升但回收量趋近于 0 —— 这是大对象连续分配的典型特征
定位具体哪段代码把视频塞进了堆
重点排查缓存写入路径，尤其是“本地缓存”这一层：
- 搜索所有含
byte[]、ByteBuffer、InputStream.readAllBytes()、Files.readAllBytes()的缓存写入逻辑 - 检查缓存 key 是否包含视频 ID，value 是否直接是
byte[]（而非String url或Path） - 特别注意“降级逻辑”：当远程缓存（如 Redis）未命中时，是否直接读取本地磁盘视频并
put到本地缓存？这类代码往往藏在getVideoData(id)方法末尾 - 示例危险代码：
cache.put(videoId, Files.readAllBytes(videoPath)); // 单个 500MB 视频 → 一次分配 500MB 堆对象
立即止损与临时缓解
线上已暴死，先保服务，再修代码：
- 加 JVM 参数限制单次分配上限（治标）：
-XX:+UseG1GC -XX:G1HeapRegionSize=4M -XX:MaxGCPauseMillis=200（让 G1 更早触发 GC，减缓暴死节奏） - 紧急绕过本地缓存视频数据（推荐）：
在缓存 get 方法中增加判断：if (key.startsWith("video:")) return fetchFromRemoteOnly();，彻底禁止视频类 key 写入本地堆 - 重启应用后，用
jmap -histo:live <pid></pid>快速确认：排名前 3 的 class 是否含[B（byte[]）且 instance 数量突增、total bytes 超过 200MB
根治方案：视频数据绝不进 JVM 堆
视频是流式资源，必须脱离堆管理：
- 本地缓存只存元信息：如
VideoMeta { id, size, duration, localPath, etag }，真实文件走FileChannel或RandomAccessFile零拷贝传输 - 若需“缓存加速”，用 OS page cache + 内存映射：
MappedByteBuffer buffer = FileChannel.open(path).map(READ_ONLY, 0, fileSize);—— 占用的是直接内存（Direct Memory），不走堆，也不受-Xmx限制 - 强制分块加载：任何视频操作必须带 offset/length，禁用
readAllBytes()；播放器请求某一段，就只读对应区间 - 加守卫校验：在缓存 put 前插入大小拦截：
if (data.length > 5 * 1024 * 1024) throw new IllegalArgumentException("Refuse video binary > 5MB into heap cache");
