Redisson Map踩坑姿势

使用Java的Redisson客户端时，踩了一些坑，分享再次，供大家参考。

因此引发的一次故障及排查过程参见： 记一次线上“内存泄露”故障

 

• RMapCache的坑

RMapCache的坑要从Redisson中Map结构的元素淘汰机制说起，详见 Redisson元素淘汰，为了能够实现对Map中每个元素单独设定 有效时间 和 最长闲置时间，Redisson会创建很多的EvictionTask【由Redisson的EvictionScheduler持有】来执行元素淘汰操作，这些Task实际是交给netty执行ScheduleTask【由netty的NioEventLoop持有】。

    坑一：当大面积使用带有元素淘汰机制的Map类型时候（那些Map类型有元素淘汰功能，详见 Redisson元素淘汰），尤其是持续不断的大量新建时，在客户端会创建大量的Task，这些task会持有很多string类型的key。
        ○ EvictionTask持有的task，可以通过显式的调用Map上的destroy()方法释放，如果不显式释放，Redisson的EvictionScheduler持有了EvictionTask会导致内存泄露
        ○ 由于EvictionTask会交给netty进行Schedule，这些task会一直等到擦除任务执行完成后才会释放，这些key也不会释放【即使显示的调用destroy()也没用】。同时，netty的调度本身也会创建很多的task对象（FutureTask、ScheduleTask等），也会额外占用很多内存。
    坑二：如果创建了带有淘汰机制的Map对象的应用，中途宕机，并且后续对应的Map不会再被使用到（通过Redisson从Redis里面读出来），那么这些Map将一直在Redis中，不会再被清除（造成Redis存储容量泄露），如下各key均未在Redis层面设置过期时间。
    

    【下图中，09:15-09:25之间生成的数据后，09:30中止应用，到了10:00后，数据仍然未被释放】
    
    
    坑三：Redisson的擦除机制执行时，由于并不是用的redis的过期机制，在向Redis写入Map数据的时候，会同时写入很多其他的控制信息，会导致redis的指令执行数量也同步增长。下图为从RMapCache[有擦除]改为RMap[无擦除]后的执行执行数量对比：
    

 

• RMap的坑

    
    
    redisson的RMap过期时间设置，不能在RMap为空时设置，否则不会生效到redis中，必须要在put了至少一个元素之后，如图