如何规避JVM内存缓存服务因OOM错误导致进程无响应问题

自研堆内内存缓存服务出现写入打满内存触发OOM的核心原因，是没有做前置的内存配额硬管控，把所有堆内存的使用权都开放给了写入请求，等内存耗尽时JVM已经没有多余资源维持服务运行。
绝对不要依赖捕获OutOfMemoryError实现拒写逻辑：OOM属于Error级别的系统异常，触发时已经有线程因内存申请失败终止，堆内可能残留半初始化对象、内存碎片，服务状态已经不可预期，捕获后恢复的稳定性极差，完全达不到可靠运行的要求。
可落地的管控方案如下：

• 启动时提前划分内存配额，不要把全部堆内存留给缓存存储。比如配置JVM最大堆内存为8G时，可将70%（约5.6G）设为缓存数据的最大占用阈值，剩下30%预留给网络通信栈、请求处理线程、JVM自身运行的基础开销，从根源上避免缓存占满所有内存。
• 写入前做精准的内存占用预校验。每个写入请求到达后，先计算本次要存储的条目总内存开销：包括对象头、key/value的实际字节长度、哈希表节点指针、过期时间等元数据的占用，累加当前已使用的缓存内存，如果超过预设阈值，直接向客户端返回写入失败响应，不执行实际的存入操作。如果自行计算对象大小成本过高，可借助java.lang.instrument提供的getObjectSize方法做递归计量，注意不要漏算嵌套引用对象的开销，也不要只统计value长度忽略元数据占用，否则计量值会远低于实际内存占用，依然存在OOM风险。
• 搭配内存淘汰机制做缓冲。当缓存已用内存达到阈值的80%时，提前触发LRU/LFU淘汰、过期key清理，优先释放冷数据、过期数据占用的内存，清理完成后如果剩余内存足够承载当前写入请求则正常写入，不足再执行拒写逻辑，减少不必要的请求拒绝。
• 单条大value做硬限制。不管当前剩余内存多少，只要单个写入的value大小超过预设的单条阈值（比如128M）就直接拒写，避免单个超大对象直接占满老年代触发Full GC甚至OOM。

Redis这类成熟内存缓存从设计上就避免了内存打满崩溃的问题，核心处理逻辑和上述方案思路一致：

• 启动时通过maxmemory配置项设置缓存数据的硬内存上限，这个值严格小于进程可支配的最大物理内存，预留足够内存给网络IO、主从复制、持久化、后台任务等非存储逻辑使用，永远不会让存储数据占满所有可用内存。
• 每次写入前做内存预计算：执行写入命令前先统计本次写入的key、value、元数据需要占用的内存量，累加当前已用内存如果超过maxmemory阈值，就先触发用户配置的淘汰策略（包括allkeys-lru、volatile-lru、allkeys-lfu、volatile-ttl等），如果执行完淘汰策略后依然没有足够空闲内存，默认的noeviction策略会直接向客户端返回写入错误，不会强行写入触发进程OOM。
• 超大请求防护：Redis官方本身建议单value大小不超过1MB，同时通过proto-max-bulk-len配置项设置单请求的最大允许长度（默认512MB），超过该长度的请求会被直接断开连接拒绝处理，避免单个超大payload直接打满内存。
• 底层内存分配优化：使用jemalloc做分池内存管理，按对象大小划分不同的内存池分配，减少内存碎片，同时后台线程会周期性统计内存使用率，不会等到内存完全耗尽才做干预。

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