缓存几乎成了Java后端架构中的标配。提到Spring Boot中的缓存，绝大多数人的第一反应就是那个简单好用的@Cacheable注解。确实一行代码就Neng把方法结果塞进Redis或者Caffeine里kan起来简直是开发者的福音。

但是老司机们dou知道，缓存这东西，用好了是锦上添花，用不好就是埋雷。有多少次你在深夜被运维的 一、 基础配置与序列化：那些让人摸不着头脑的“低级错误”

hen多时候，问题并不出在复杂的业务逻辑上，而是出在Zui基础的配置里。这些坑往往Zui隐蔽，因为它们不会报错，只会默默地“不工作”。

1. 忘记开启“总开关”：@EnableCaching去哪了？

这简直是新手必踩的第一个坑。你信心满满地写好了Service层代码，加上了@Cacheable，结果一运行，发现Redis里空空如也，每次请求还是老老实实地去查数据库。

原因其实简单到令人发指：你根本没告诉Spring要开启缓存功Neng！这就好比你买了一辆法拉利，却忘了加钥匙。

避坑指南：一定要在你的启动类或者配置类上加上@EnableCaching这个注解。少了它，后面所有的缓存注解dou只是摆设。

@SpringBootApplication
@EnableCaching  // 别忘了这个“灵魂”注解！
public class Application {
    public static void main {
        SpringApplication.run;
    }
}

2. 缓存Key的“乌龙”：为什么所有人查到的dou是同一个人的数据？

有时候你会发现，明明传入的是用户ID 1001，结果返回的却是用户ID 1002的数据，甚至所有用户查到的结果dou一样。这通常是因为你的Key写“死”了。

Ru果你把Key写成了常量字符串，比如key = "'user'"，那么无论方法参数怎么变，Springdou认为这是同一个缓存项。这就好比去图书馆借书，不管你要什么书，管理员dou只给你同一本。

避坑指南：利用SpEL表达式动态生成Key。让Key包含方法参数，这样才Neng精准定位。

// ❌ 错误示范：所有人共享同一个缓存
@Cacheable
public User getUser {
    return userMapper.selectById;
}
// ✅ 正确姿势：动态拼接参数
@Cacheable
public User getUser {
    return userMapper.selectById;
}
// ✅ 进阶玩法：多参数组合
@Cacheable
public List listByType {
    return userMapper.selectList;
}

3. Redis里的“天书”：序列化异常与乱码

当你满怀期待地去Redis里查kan缓存数据时却发现存进去的是一堆类似\xAC\xED\x00\x05t\x00\x05User的乱码，或者反序列化时直接抛出Could not read JSON异常。这通常是因为序列化配置没对齐。

Spring默认使用JDK序列化，虽然效率还行，但可读性极差，而且占用空间大。geng糟糕的是Ru果你的实体类没有实现Serializable接口，或者跨语言调用时就会直接报错。

避坑指南：手动配置RedisTemplate，强制使用JSON序列化。同时确保你的实体类实现了Serializable接口。

@Configuration
@EnableCaching
public class RedisConfig {
    @Bean
    public RedisTemplate redisTemplate {
        RedisTemplate template = new RedisTemplate<>;
        template.setConnectionFactory;
        // 使用StringRedisSerializer来序列化key
        template.setKeySerializer);
        template.setHashKeySerializer);
        // 使用JSON序列化value
        template.setValueSerializer);
        template.setHashValueSerializer);
        template.afterPropertiesSet;
        return template;
    }
}

二、 数据一致性：缓存与数据库的“相爱相杀”

解决了存取问题，接下来就是Zui让人头疼的一致性问题。数据库变了缓存没变；或者缓存删了数据库没变。这种不一致在业务上往往是不可接受的。

4. geng新操作的误区：@CachePut还是@CacheEvict？

hen多同学在geng新数据时习惯性地用@CachePut，想着“把新结果放进去不就行了”。但这里有个巨大的陷阱：@CachePut会强制执行方法体，并将返回值写入缓存。Ru果你的方法逻辑比较复杂，或者返回值处理不当，hen容易导致缓存里存进去的是脏数据。

geng推荐的Zuo法是使用@CacheEvict，直接把旧缓存删掉。下次查询时触发@Cacheable，自然就会从数据库拉取Zui新数据。这就是经典的Cache Aside模式。

@Service
public class UserService {
    // 查询 - 缓存读取
    @Cacheable
    public User getUser {
        return userMapper.selectById;
    }
    // geng新 - 删除缓存
    @CacheEvict
    public void updateUser {
        userMapper.updateById;
    }
    // 删除 - 删除缓存
    @CacheEvict
    public void deleteUser {
        userMapper.deleteById;
    }
}

5. 并发场景下的“双删”策略

即使是Cache Aside模式，在高并发下也可Neng出问题。比如线程A删了缓存，还没来得及geng新数据库，线程B就来查询，发现缓存空，于是读了旧数据并写回缓存。这下好了数据库是新的，缓存是旧的，数据不一致产生了。

为了解决这个问题，经验丰富的架构师通常会采用延迟双删策略：先删缓存，geng新数据库，休眠一小会儿，再删一次缓存。

public void updateUser {
    // 1. 先删缓存
    redisTemplate.delete);
    // 2. 再geng新数据库
    userMapper.updateById;
    // 3. 延迟双删
    try {
        Thread.sleep; // 视业务情况调整
    } catch  {
        Thread.currentThread.interrupt;
    }
    redisTemplate.delete);
}

三、 高并发下的“三座大山”：穿透、击穿与雪崩

当流量洪峰袭来缓存系统会面临三大经典考验。Ru果处理不好，数据库瞬间就会被打爆。

6. 缓存穿透：查不到数据的“恶意攻击”

想象一下有人一直在请求一个不存在的ID。因为缓存里没有，每次请求dou会穿透缓存直接打到数据库。Ru果有几千个这样的并发请求，数据库基本就宣告阵亡了。

解决方案：

缓存空值：当数据库查不到时依然将Null值缓存起来设置较短的过期时间。

布隆过滤器：在缓存层之前加一道屏障，拦截掉一定不存在的Key。

// 缓存空值策略
@Cacheable
public User getUser {
    return userMapper.selectById;
}

7. 缓存击穿：热点Key的“瞬间坍塌”

某个热点Key极其火爆，突然在这一刻过期了。此时成千上万的请求同时发现缓存失效，像饿狼一样扑向数据库。

解决方案：

互斥锁：只让一个线程去查数据库，其他线程等待。

逻辑过期：不设置TTL，而是在Value里包含过期时间。后台异步geng新，前台永远返回数据。

// 简单的互斥锁逻辑示例
public User getUser {
    String key = "user:" + id;
    User user = redisTemplate.opsForValue.get;
    if  {
        // 尝试获取锁
        String lockKey = "lock:user:" + id;
        Boolean locked = redisTemplate.opsForValue.setIfAbsent;
        if ) {
            try {
                // 双重检查，防止其他线程Yi经写入
                user = userMapper.selectById;
                if  {
                    redisTemplate.opsForValue.set;
                }
            } finally {
                redisTemplate.delete;
            }
        } else {
            // 没拿到锁，稍等片刻再重试
            try { Thread.sleep; } catch  {}
            return getUser; 
        }
    }
    return user;
}

8. 缓存雪崩：集体“罢工”的灾难

Ru果你在系统初始化时给大批量的Key设置了相同的过期时间，那么30分钟后这些Key会同时失效。这一瞬间，数据库的压力会呈指数级上升。

解决方案：在过期时间的基础上，增加一个随机值。比如30分钟 + 随机0-5分钟。这样就Neng让失效时间分散开来避免集体雪崩。

public void putWithJitter {
    // 基础时间30分钟 + 随机0-10分钟
    long baseSeconds = 30 * 60;
    long jitter = ThreadLocalRandom.current.nextLong;
    Duration ttl = Duration.ofSeconds;
    redisTemplate.opsForValue.set;
}

四、 运维与架构：容易被忽视的细节 9. 内存泄漏：只进不出的黑洞

有些同学为了省事，在配置RedisCacheManager时干脆不设置过期时间。结果就是Redis里的数据越来越多，Zui后把内存撑爆。这就像家里的垃圾桶，Ru果你永远不倒垃圾，房子迟早会被填满。

避坑指南：务必在配置中设置默认的过期时间，或者在注解中明确指定TTL。

@Configuration
@EnableCaching
public class CacheConfig {
    @Bean
    public RedisCacheManager cacheManager {
        RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig
            .entryTtl) // 全局默认30分钟过期
            .disableCachingNullValues;      // 可选：不缓存Null值
        return RedisCacheManager.builder
            .cacheDefaults
            .build;
    }
}

10. 分布式环境下的“各自为政”

在单机开发时一切douhen美好。但一旦部署了多实例，Ru果你用的是本地缓存，就会出大问题。实例Ageng新了数据，实例B根本不知道，导致用户一会儿kan到新数据，一会儿kan到旧数据。

避坑指南：在分布式系统中，请务必使用Redis等集中式缓存。Ru果必须用本地缓存，也要配合消息队列来广播缓存变geng消息。

一份给开发者的“避坑清单”

缓存虽好，可不要贪杯哦。为了防止大家 掉进同一个坑里我整理了一份简单的检查清单，建议大家在Code Review时对照着kan：

检查项	说明	推荐配置
✅ 启动类加 @EnableCaching	开启缓存功Neng	必选项
✅ key 表达式动态拼接	避免所有请求命中同一 key	#id、#p0
✅ 设置合理的过期时间	避免内存泄漏	15~60分钟
✅ 过期时间加随机值	防止缓存雪崩	base + random
✅ 缓存空值	防止穿透	unless + null 值过滤
✅ 热点数据互斥锁	防止击穿	分布式锁
✅ 先删缓存后geng新	保证双写一致	Cache Aside 模式
✅ 分布式环境用 Redis	本地缓存只适合单机	Redis Cluster
✅ 实体类实现序列化	防止反序列化失败	implements Serializable
✅ 监控缓存命中率	及时发现问题	Actuator + Metrics

Zui后想说技术本身没有银弹。理解原理，结合业务场景，才是解决问题的关键。希望这篇文章Neng帮你少踩几个坑，早点下班！

---