redission使用的那些坑-hash结构_java_我们都爱松松吧-云原生

故障现象： 应用隔2-3天就回导致一次CPU飙到600%+（容器，宿主8核），随后宕机。

排查过程：

首先明确CPU飙升原因

第一步： top -Hp 查看占用CPU进程

发现13~20线程占用大量CPU资源

第二步： jstack 查看实际占用cpu的进程（与top命令中线程关系nid(hex)=pid(dec)）

发现CPU占用方均为GC线程。

第三步： jstat -gcutil 查看gc执行情况，发现

Old区占用达100%
在频繁的执行Full GC操作
每次Full GC操作几乎释放不出Old区空间
确认代码中的确没有System.GC()显式操作

结合此时old区占用已经达到99.9%，基本可以确定是内存占满导致频繁的FullGC，CPU高居不下，最后响应异常，被健康检查进程杀掉。

进一步分析堆栈，查找FullGC诱因，

第四步： dump堆分析，内存占用按数量分布如下

其中，如下几类数量上十分可疑，


    
    
      
      
       
       
      
      
      
      
       
       
        
        java.util.LinkedList$Node
       
       
      
      

      
      
       
       
      
      
      
      
       
       
        
        java.util.concurrent.ConcurrentHashMap$Node
       
       
      
      

      
      
       
       
      
      
      
      
       
       
        
        java.util.LinkedList
       
       
      
      

      
      
       
       
      
      
      
      
       
       
        
        io.netty.util.concurrent.ScheduledFutureTask
       
       
      
      

      
      
       
       
      
      
      
      
       
       
        
        io.netty.util.concurrent.PromiseTask$RunnableAdapter
       
       
      
      

      
      
       
       
      
      
      
      
       
       
        
        org.redisson.eviction.MapCacheEvictionTask
       
       
      
      

      
      
       
       
      
      
      
      
       
       
        
        复制代码

从数量上，基本可以认为是同一个根导致的级联泄露，关联分析，情况属实.

源码级排查，深层分析原因，

第五步： Redisson源码排查应用中大量使用了Redisson客户端（Redisson implements RedissonClient）的getMapCache方法，生成了大量的RedissonMapCache（RMapCache）对象（RedissonClient->getMapCahce）。

而Redisson对象恰恰是EvictionScheduler的持有者，依赖路径 Redisson -> EvictionScheduler -> C-HashMap ->Node -> MapCacheEvictionTask -> LinkedList(sizeHistory)。

但是实际排查中，RedissonMapCache的数量并没有泄露，原因在于EvictionScheduler是RedissonClient持有，注入给RedissonMapCache的，虽然RedissonMapCache生命周期结束后被gc回收了，但是EvictionScheduler持有的大量task，并没有被释放，需要手工显式调用destory释放。

此外，一个EvictionScheduler会同时占用6个字符串，这也解释了String类型变了数量为827（~136万 * 6）万的原因。而char[]类型中，占比99%均是EvictionTask所持有的那些真实字符。

第六步： try to fix 由前面分析得知，造成泄露的根源就是EvictionScheduler->tasks属性持有的Task造成了相关数据（主要是redisson自用的key串）引用无法释放。 RMapCache的擦除调度机制（EvictionScheduler工作机制参见https://github.com/redisson/redisson/wiki/7.-distributed-collections#eviction）；

此问题，可使用RedissonMapCache->destory方法可以显式移除task。

第七步： 验证->失败，同样泄露，，，继续分析：：：但是，此时EvictionScheduler->tasks列表中，元素确实已经变空，也就是说由tasks导致的泄露已经通过RedissonMapCache->destory方法消除。

并且，dump后查看MapCacheEvictionTask的数量，的确降低了很多，并且现存的MapCacheEvictionTask里面，绝大部分元素均没有再被EvictionScheduler->tasks持有。说明上面的destroy()确实对其释放有帮助。如图：

但是ScheduleFutureTask&PromiseTask相关对象并未释放，联想到前面 Redisson的Eviction机制，猜测是RMapCache进行擦除（过期）任务导致在netty调度时，出现：

RMapCache过期前，netty仍然会持有MapCacheEvictionTask（275973个），此时虽然Redisson这边不在泄露task，但是如果请求很密集，光redisson的key占用的字符空间，就有可能占满jvm堆空间，如下图，此时jvm Old区占用已达90%+。

但是庆幸的是，这种情况下，执行一次FGC基本可以释放出大量空间（99.9%时执行了一次FGC，Old区释放了40%+多的空间）：

ScheduleFutureTask及PromiseTask在netty执行调度时，本身任务管理上也存在问题，大量的任务（ScheduledFutureTask/PromiseTask）占用着内存空间。（redisson的EvictionScheduler其实是把任务交给netty的NioEventLoopGroup进行调度）（代码路径： redissonClient::getMapCache new RedissonMapCache evictionScheduler.schedule() new MapCacheEvictionTask -> put it to EvictionScheduler.tasks MapCacheEvitionTask.schedule() ConnectionManager->getExcutor() get EventLoopGroup ->schdule [netty的NioEventLoopGroup]开始调度）

如下图展示的对象引用关系，NioEventLoop持有了大量的Task造成了内存负担。

--目前为止，此问题，未找到redisson相关高级接口手动释放下放到netty层面的task对象。决定使用RMap替代RMapCache，不使用redisson的Eviction功能。

使用RMap代替RMapCache，更新应用后，故障解除。