Tomcat 8.5+Java 8引入Redis会话管理后出现OOM问题求助

核心问题定位 #

首先明确：你遇到的是Linux内核触发的系统级OOM（Out-of-Memory），日志中的java invoked oom-killer是内核为了释放系统内存，强制终止内存占用最高的进程（此处为JVM），而非JVM堆内存本身溢出（若为堆溢出会有java.lang.OutOfMemoryError: Java heap space类日志）。结合你的环境变更和监控数据，需从系统资源竞争和JVM内存配置/潜在泄漏两个维度分析：

1. 系统资源竞争的直接证据 #

• Redis与Tomcat共享服务器，且JVM占用了大部分内存，仅预留2GB给Redis及系统进程。Redis是内存型数据库，当缓存的用户会话数据持续增长时，会不断占用系统内存；加上JVM的非堆内存（直接内存、Metaspace、线程栈等）、系统缓存页等消耗，极易耗尽预留的2GB内存，触发内核OOM-killer。
• 首日GC能释放堆内存但JVM仍崩溃，说明JVM堆内内存可回收，但系统整体内存已无剩余，内核仍会终止进程。

2. JVM内存配置的潜在问题 #

• 次日老年代接近上限未触发Full GC：大概率是GC触发阈值设置不合理（如使用CMS时-XX:CMSInitiatingOccupancyFraction值过高，或G1的IHOP阈值未适配当前内存规模），导致堆内存接近耗尽才触发GC，加剧了系统内存的瞬时压力。

诊断步骤 #

第一步：确认系统内存占用细节 #

• 用free -h、top实时监控服务器内存，重点查看Redis的内存消耗：执行redis-cli info memory，关注used_memory_human字段，确认Redis是否占用了大部分预留内存。
• 查看OOM触发时的系统日志：检查/var/log/messages或dmesg输出，确认触发OOM时各进程的内存占比，明确是Redis还是JVM非堆内存耗尽了系统资源。

第二步：排查JVM内存是否存在泄漏 #

• 手动触发Full GC：执行jcmd <JVM进程ID> GC.run，观察老年代内存是否能有效下降。若释放后内存明显降低，说明是GC阈值配置问题；若内存仍居高不下，需导出堆快照（jmap -dump:format=b,file=heap.hprof <JVM进程ID>），用MAT/VisualVM分析是否存在对象泄漏（如Redisson会话对象、连接池对象未被正确释放）。
• 监控JVM非堆内存：执行jcmd <JVM进程ID> VM.native_memory summary，查看直接内存、Metaspace等非堆区域的占用情况，确认是否有非堆内存溢出。

第三步：验证资源竞争影响 #

• 临时调整内存分配：减少JVM堆内存1GB，让系统预留内存提升至3GB，观察是否还会触发OOM-killer。若问题消失，则可确认是系统资源竞争导致。

解决建议 #

针对系统资源竞争的优化 #

1. 重新规划内存分配：
   • 避免JVM堆内存占满服务器物理内存，预留足够空间给Redis、系统进程及缓存页。例如服务器总内存16GB时，JVM堆设置为10GB，预留6GB给Redis和系统。
   • 给Redis设置内存上限与淘汰策略：在redis.conf中配置maxmemory 2G（根据预留内存调整），并设置maxmemory-policy allkeys-lru，当Redis达到内存上限时自动淘汰冷数据，防止无限制占用内存。
2. 分离部署（长期方案）：若服务器内存不足，将Redis单独部署到另一台服务器，彻底避免资源竞争。

针对JVM内存配置的优化 #

1. 调整GC参数：
   • 切换为G1GC（Java8推荐）：添加-XX:+UseG1GC参数，G1会自动调整GC触发时机，更适合大内存场景；若坚持使用CMS，调整-XX:CMSInitiatingOccupancyFraction=70，让老年代占用70%时触发GC，避免内存接近上限才回收。
   • 限制非堆内存：设置-XX:MaxMetaspaceSize=256m防止Metaspace无限制增长；Redisson可能使用直接内存，需配置-XX:MaxDirectMemorySize=512m（根据实际情况调整）。
2. 优化Redisson配置：
   • 合理设置连接池大小：将connectionPoolSize调整为50-100（根据并发量），避免过多连接占用内存。
   • 配置会话过期与清理：设置expirationTimeout为合理值（如3600秒），开启Redisson的自动清理机制，确保过期会话被及时删除，减少Redis内存占用。

针对内存泄漏的排查 #

若堆快照分析发现特定对象（如Redisson会话对象、连接对象）持续增长，需检查代码：

• 是否存在静态集合持有会话对象引用，导致无法回收；
• Redisson客户端是否在使用后正确关闭连接，是否存在连接泄漏。

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