Redisson中Kryo序列化与Spring Cache NullValue的兼容性问题解析

问题背景

在使用Redisson作为Spring Cache的分布式缓存实现时，开发人员可能会遇到一个与序列化相关的微妙问题。这个问题主要出现在使用Kryo5Codec作为Redisson的编解码器时，与Spring框架的org.springframework.cache.support.NullValue类产生兼容性问题。

问题本质

Spring Cache的抽象层AbstractValueAdaptingCache中有一个关键方法fromStoreValue，它通过==操作符直接比较缓存值与NullValue.INSTANCE单例实例。当使用Kryo序列化时，Kryo会通过反射创建新的NullValue实例，而不是保留原始的单例引用，导致==比较失败。

技术细节分析

1. Spring Cache的设计：

   • Spring Cache使用NullValue.INSTANCE作为空值的标记对象
   • 依赖Java的单例模式实现，通过readResolve()方法保证反序列化时返回同一实例
   • 使用==进行严格比较以提高性能

2. Kryo序列化机制：

   • Kryo默认使用无参构造函数创建对象实例
   • 通过反射修改构造函数访问权限
   • 不调用readResolve()方法，破坏了单例模式

3. Redisson的集成角色：

   • 作为缓存实现，负责对象的序列化/反序列化
   • 使用配置的编解码器处理缓存值
   • 在JCache实现中传递反序列化后的对象

解决方案比较

方案一：使用JavaSerializer

// 在Kryo5Codec的createKryo方法中添加
if (Util.isClassAvailable("org.springframework.cache.support.NullValue")) {
   kryo.addDefaultSerializer(
       Class.forName("org.springframework.cache.support.NullValue"), 
       new JavaSerializer());
}

优点：

• 保持Spring依赖的可选性
• 利用Java原生序列化机制维护单例
• 实现简单，改动量小

缺点：

• Java原生序列化性能略低于Kryo
• 需要处理ClassNotFoundException

方案二：自定义序列化器

public class NullValueSerializer extends FieldSerializer<NullValue> {
    public NullValue read(Kryo kryo, Input input, Class type) {
        return (NullValue) NullValue.INSTANCE;
    }
}

优点：

• 保持Kryo的高性能
• 精确控制反序列化行为

缺点：

• 需要显式依赖Spring类
• 实现相对复杂
• 需要维护自定义代码

最佳实践建议

对于大多数项目，推荐采用第一种方案，即使用JavaSerializer来处理NullValue类。这种方案：

1. 保持了框架的灵活性，不强制引入Spring依赖
2. 对NullValue这类不频繁操作的小对象，性能影响可忽略
3. 维护成本低，代码简洁
4. 符合Redisson的设计理念

对于性能极其敏感且大量使用NullValue的场景，可考虑第二种方案，但需要注意处理依赖关系。

扩展思考

这个问题实际上反映了分布式缓存设计中几个重要考量：

1. 单例对象的序列化：在分布式环境中维护单例特性需要特殊处理
2. 框架兼容性：底层实现需要适应上层框架的特定约定
3. 性能与正确性的权衡：有时需要为正确性牺牲少量性能

开发者在选择序列化方案时，应当充分了解各方案的特性及其与上层框架的交互方式，才能避免这类隐蔽的问题。