JetCache中@Cached注解在接口方法上使用SpEL表达式失效问题解析

问题现象

在使用JetCache框架时，开发者发现当@Cached注解应用于接口方法并配合SpEL表达式作为key时，缓存功能会失效。具体表现为：

1. 当注解定义在接口方法上，并且使用了形如key = "#userId"的SpEL表达式时，每次调用都会穿透缓存直接访问方法体
2. 同样的注解配置如果移动到实现类方法上，则缓存功能正常工作
3. 如果在接口方法上不使用SpEL表达式，仅使用默认key生成策略，缓存也能正常工作

根本原因

经过分析，这个问题与Java编译参数密切相关。当使用SpEL表达式引用方法参数时（如#userId），JetCache需要能够获取方法的参数名称信息。而Java编译器默认不会保留方法参数名称，除非显式指定-parameters编译选项。

在接口和实现类表现不同的原因可能是：

1. 接口和实现类可能使用了不同的编译设置
2. IDE（如IntelliJ IDEA）可能对实现类有特殊处理，默认保留了参数名称信息
3. 项目构建工具（如Maven/Gradle）可能对接口和实现类应用了不同的编译配置

解决方案

要解决这个问题，需要确保编译时保留了方法参数名称信息。具体方法如下：

1. 使用-parameters编译选项

在Java编译时添加-parameters参数，这会保留方法参数名称信息。不同构建工具的配置方式：

Maven配置：

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
        <compilerArgs>
            <arg>-parameters</arg>
        </compilerArgs>
    </configuration>
</plugin>

Gradle配置：

tasks.withType(JavaCompile) {
    options.compilerArgs << '-parameters'
}

2. 统一编译环境

确保接口和实现类使用相同的编译设置，避免因编译环境不一致导致的行为差异。

3. 替代方案

如果无法修改编译参数，可以考虑：

1. 将@Cached注解移动到实现类方法上
2. 使用参数索引代替参数名称（如#p0表示第一个参数）
3. 使用默认的key生成策略，不自定义SpEL表达式

最佳实践

1. 统一编译配置：项目中的所有Java类应使用相同的编译参数，特别是涉及AOP和注解处理的场景
2. 参数命名规范：保持接口和实现类的方法参数名称一致
3. 编译参数检查：在CI/CD流程中加入检查，确保编译参数正确设置
4. 测试验证：添加缓存功能的单元测试，验证不同场景下的缓存行为

技术背景

Java 8引入了-parameters编译选项，允许编译器将方法参数名称信息保留在class文件中。这对于依赖参数名称的框架（如Spring、JetCache等）非常重要。当没有这个信息时，框架只能通过参数索引访问参数，而无法通过参数名称进行匹配。

JetCache在处理@Cached注解时，会解析SpEL表达式中的参数引用。如果无法获取参数名称信息，表达式解析就会失败，导致缓存功能失效。这就是为什么在接口方法上使用SpEL表达式时需要特别注意编译参数的原因。

总结

JetCache作为阿里巴巴开源的缓存框架，提供了强大的注解驱动缓存功能。在使用@Cached注解时，特别是当注解应用于接口方法并配合SpEL表达式时，务必确保编译时保留了方法参数名称信息。通过正确配置-parameters编译选项，可以避免这类问题的发生，确保缓存功能按预期工作。