1. 项目概述从“会用”到“用好”的RedisTemplate操作指南在Java后端开发里RedisTemplate几乎是连接Spring应用与Redis缓存的标准桥梁。很多朋友在项目里都配置过它也知道用opsForValue().set()存个字符串用opsForList().leftPush()往列表里塞点数据。但说实话我见过太多项目里的Redis操作代码还停留在“能跑就行”的阶段性能隐患和潜在Bug就像房间里的大象大家心照不宣却没人去处理。今天我们不聊怎么配RedisConnectionFactory也不讲序列化器选哪个就聚焦在opsForValue和opsForList这两个最常用、也最容易被轻视的操作接口上。我会结合自己踩过的坑和线上调优的经验把这两个接口从简单的API调用拆解成一套包含设计考量、性能陷阱和最佳实践的完整操作手册。无论你是刚接触Spring Data Redis的新手还是想优化现有代码的老鸟相信都能找到一些立刻就能用上的干货。2. RedisTemplate操作接口的设计哲学与核心思路2.1 为什么是“opsForXxx”而不是直接的方法第一次接触RedisTemplate时你可能会觉得它的API设计有点绕为什么不直接在RedisTemplate上提供set、get、lpush这些方法而是要先调用opsForValue()、opsForList()拿到一个操作接口再通过这个接口去执行命令这背后其实是Spring Data Redis在抽象层次上的一次重要取舍目的是在便利性和类型安全之间找到平衡。Redis本身支持的数据结构比较丰富有String、List、Hash、Set、Sorted Set等。如果所有操作都堆在RedisTemplate一个类里这个类会变得极其臃肿方法名也可能产生冲突比如是操作String的get还是操作Hash的get。更关键的是直接操作缺少了编译期的类型约束。opsForValue()方法返回的是一个ValueOperationsK, V接口这个接口泛型化了键K和值V的类型。当你通过这个接口调用set时IDE和编译器能基于上下文推断出值的类型如果你试图存入一个类型不匹配的值在编译阶段就可能发现问题。而如果所有方法都放在RedisTemplate里这种类型安全就难以保障。这种设计也符合“接口隔离”原则。作为使用者你通常只关心某一种数据结构的操作。当我只需要操作List时我拿到一个ListOperations对象它的方法列表是干净、专注的全是关于List的命令lPush,rPop,range等不会受到其他数据结构方法的干扰代码的意图也更清晰。从框架维护的角度看这种结构也便于扩展和维护每种数据结构的操作逻辑被封装在独立的类中。2.2 理解“操作接口”与“连接”的生命周期分离这里有一个非常重要的细节但官方文档很少强调opsForValue()、opsForList()这些方法每次调用返回的是一个新的操作接口实例吗它们和底层的Redis连接是什么关系答案是操作接口如ValueOperations本身是无状态的、轻量的辅助对象真正的重头戏是RedisTemplate本身持有的RedisConnectionFactory和执行模板方法。当你调用redisTemplate.opsForValue().set(“key”, “value”)时实际发生的事可以拆解为几步redisTemplate.opsForValue()这里调用的是RedisTemplate的一个方法它内部通常会从缓存比如一个ConcurrentHashMap中获取或新建一个ValueOperations的实现类实例通常是DefaultValueOperations。这个操作接口实例内部持有了对redisTemplate本身的引用。set(“key”, “value”)这个set方法是ValueOperations接口定义的。在DefaultValueOperations的实现里它会将调用委托给其持有的redisTemplate实例的execute方法。redisTemplate.execute(...)这是核心执行引擎。它会处理序列化将Java对象“value”转换成字节数组、从连接工厂获取或借用Redis连接、执行底层SET命令、处理反序列化如果需要返回值、管理连接释放归还到连接池等一系列复杂操作。所以你可以反复调用opsForValue()这开销很小。真正消耗资源的是execute方法中涉及的连接获取、命令网络传输和序列化。理解这一点就能明白为什么我们关注的重点应该是如何高效、正确地使用这些操作接口而不是担心创建它们的成本。同时这也解释了为什么所有通过opsForXxx()配置的序列化器实际上都是RedisTemplate级别配置的操作接口只是“借用”了这套序列化机制。3. opsForValue远不止是简单的SET和GETValueOperations对应Redis的String类型但千万别被“Value”这个名字骗了它可不是只能存字符串。在Redis里String类型是二进制安全的意味着它可以存储任何字节序列这为存储序列化后的Java对象提供了可能。opsForValue是使用频率最高的接口但也是最容易产生性能问题和数据错误的地方。3.1 基础操作set/get的“隐藏参数”与正确用法最基本的set(K key, V value)和get(Object key)大家都会用。但我想问你在用set的时候考虑过过期时间吗考虑过当键已存在或不存在时的行为差异吗这些才是工程实践中需要关注的点。set方法有一系列重载最完整的一个是set(K key, V value, long timeout, TimeUnit unit)。我强烈建议除非你有明确的理由不设置过期时间否则永远使用这个带超时参数的重载。内存是宝贵的资源没有过期时间的缓存键是“内存泄漏”的典型来源之一随着时间推移会塞满Redis引发OOM错误。超时时间的设置需要结合业务逻辑用户会话token可能设置30分钟热点数据可能设置5-10分钟并配合后台刷新逻辑一些临时锁可能只设置几秒钟。除了带过期时间的set还有两个原子性操作非常重要setIfAbsent(K key, V value)对应Redis的SETNX命令。仅在键不存在时设置值。这是实现分布式锁、防止缓存击穿同一Key大量未命中导致请求穿透到DB的基石。例如在缓存预热时可以用它来确保只有一个线程去数据库加载数据。setIfPresent(K key, V value)对应Redis的SETXX命令。仅在键存在时设置值。这在一些状态更新的场景下有用比如只更新已登录用户的会话信息。get操作看似简单但也有坑。它可能返回null原因有两个一是键确实不存在二是键对应的值本身就是null如果你存了null进去。最佳实践是永远不要通过RedisTemplate向Redis存储null值。这会让缓存逻辑变得混乱。我们约定缓存里有的键其值一定是有效的业务对象返回null只代表“未缓存”。通常我们会用Optional包装返回值或者在Service层进行清晰的空值判断和后续处理如回源到数据库。3.2 原子计数与位操作高性能统计的利器ValueOperations提供了increment/decrement方法用于对整数值进行原子性的增减。这利用了Redis单线程执行命令的特性是完美的高并发计数器。比如统计文章阅读量、用户点赞数、实时在线人数等。这里要注意序列化问题用作计数的键其值必须能被序列化和反序列化为数字类型如Long。如果你用的默认JdkSerializationRedisSerializer它序列化出来的东西INCR命令是读不懂的。通常我们需要为这类计数器键专门配置StringRedisSerializer或者确保你的自定义序列化器能正确处理数字。// 假设redisTemplate的value序列化器是StringRedisSerializer ValueOperationsString, String ops redisTemplate.opsForValue(); ops.increment(“article:view:123”, 1L); // 文章123阅读量1 // 获取当前值注意返回的是Long Long views Long.parseLong(ops.get(“article:view:123”));另一个容易被忽略的功能是位操作BitMap通过setBit和getBit方法实现。一个BitMap本质上是一个String但你可以把它当作一个巨大的比特数组来操作。每个用户只占一个比特这使得它极其节省空间。典型的应用场景是大规模用户的布尔状态标记例如用户签到系统Key可以是sign:202310偏移量offset是用户ID需要做哈希映射或使用自增ID值0/1代表是否签到。统计当月签到总数可以用bitCount命令RedisTemplate需通过execute调用。活跃用户统计记录每天哪些用户活跃过。注意位操作的偏移量offset非常大时比如基于分布式用户ID可能会创建一个非常大的字符串值瞬间占用较多内存。需要提前评估偏移量的范围。3.3 批量操作提升吞吐量的关键在需要处理多个键值对的场景下循环调用单个set或get是性能杀手因为每个命令都对应一次网络往返RTT。multiSet和multiGet就是为了解决这个问题而生的。multiSet(Map? extends K, ? extends V map)一次性设置多个键值对。在缓存预热、批量更新配置时非常高效。它对应Redis的MSET命令是原子性的要么全部成功要么全部失败。multiGet(CollectionK keys)一次性获取多个键的值。返回值是一个ListV顺序与传入的keys集合顺序一致。如果某个键不存在对应的列表位置就是null。使用multiGet有一个非常重要的优化技巧过滤掉已知为null或无效的键。如果你传入一个包含100个键的集合其中20个在缓存中肯定不存在那么Redis服务器仍然会为这20个键分配响应资源返回nil。在客户端序列化器也会尝试对nil进行反序列化可能失败或产生null。最坏的情况下如果这100个键都不存在你会得到一个包含100个null的列表处理起来很麻烦。因此在调用multiGet前应该尽可能确保键集合是“干净”的或者对返回的列表进行健壮的处理。ListString keys Arrays.asList(“key1”, “key2”, “key3”); ListObject values redisTemplate.opsForValue().multiGet(keys); if (values ! null) { for (int i 0; i values.size(); i) { Object value values.get(i); if (value ! null) { // 处理有效值 processValue(keys.get(i), value); } else { // key不存在记录日志或触发回源加载 log.warn(“Cache miss for key: {}”, keys.get(i)); asyncLoadFromDB(keys.get(i)); } } }4. opsForList当列表不只是“列表”ListOperations对应Redis的List类型它是一个简单的字符串列表按插入顺序排序你可以从头部左边或尾部右边添加、弹出元素。在Java中我们很容易把它想象成LinkedList但在Redis的语境下它的用途要广泛得多。4.1 基础列表操作与阻塞式弹出leftPush/rightPush和leftPop/rightPop是核心。它们组合起来可以实现栈LIFO同侧Push/Pop或队列FIFO异侧Push/Pop。比如一个简单的任务队列可以这样实现// 生产者 listOps.rightPush(“task_queue”, new Task(“job1”)); // 消费者 Task task listOps.leftPop(“task_queue”); if (task ! null) { process(task); }但这里有个问题如果队列是空的leftPop会立刻返回null。消费者需要不断地轮询busy-waiting这很浪费CPU。解决方案是使用阻塞式弹出leftPop(K key, long timeout, TimeUnit unit)。它会在队列为空时阻塞等待直到有元素可用或超时。这是实现高效消费者工作线程的经典模式。// 消费者线程 while (!Thread.currentThread().isInterrupted()) { // 阻塞等待最多5秒 Task task listOps.leftPop(“task_queue”, 5, TimeUnit.SECONDS); if (task ! null) { process(task); } else { // 超时返回null可以做一些清理或检查线程状态 log.debug(“Pop timeout, check thread status...”); } }实操心得使用阻塞弹出时一定要处理好线程中断。在Spring应用中通常结合PreDestroy或监听Context关闭事件优雅地通知消费者线程退出循环避免应用关闭时线程被强制中断导致数据不一致。4.2 定长列表、修剪与范围查询Redis的List可以非常长最多2^32-1个元素。但很多时候我们不需要一个无限增长的列表比如只保留最新的100条消息、最近20个登录IP等。trim命令对应ListOperations的trim方法就是干这个的trim(K key, long start, long end)。它保留指定区间内的元素区间外的全部删除。索引从0开始-1表示最后一个元素。// 在每次添加新日志后只保留最近50条 listOps.rightPush(“app_logs”, newLogEntry); listOps.trim(“app_logs”, -50, -1);range方法对应LRANGE命令用于获取列表的一个片段而不是弹出。这对于分页查看历史记录非常有用。比如获取聊天消息// 获取最新的20条消息假设消息按时间顺序从左侧插入 // 先获取列表长度 Long size listOps.size(“chat_room:1”); // 计算起始索引防止越界 long start Math.max(0, size - 20); ListChatMessage messages listOps.range(“chat_room:1”, start, -1);这里有一个性能陷阱对于超长的列表例如几十万元素频繁调用size()然后再range()实际上是两个命令如果列表长度变化不频繁可以考虑将长度也缓存起来或者直接使用一个固定的范围比如始终取最后1000条由前端或业务逻辑分页。4.3 列表作为多值缓存的误用与纠正我看到过一个常见的反模式为了缓存一个对象的所有属性把这个对象拆成多个字段然后用rightPush把这些字段值依次存入同一个List Key中。读取时再用range全部取出再手动组装成对象。// 反模式示例存储用户信息 listOps.rightPush(“user:100”, “张三”); listOps.rightPush(“user:100”, 30); listOps.rightPush(“user:100”, “北京”); // 读取 ListObject values listOps.range(“user:100”, 0, -1); User user new User((String)values.get(0), (Integer)values.get(1), (String)values.get(2));这种做法非常糟糕。首先它破坏了列表的语义列表应该是同质元素的集合。其次它失去了原子性存储三个字段需要三次网络往返中间可能被其他操作打断。最后读取和组装逻辑脆弱且低效。正确的做法是使用opsForHashHash数据结构。Hash可以完美地映射一个对象的字段HMSET和HMGET命令可以原子性地操作多个字段。或者如果对象结构稳定直接使用opsForValue将整个对象序列化后存成一个String值这是最常用、最清晰的做法。List应该留给真正的列表场景消息流、时间线、任务队列等。5. 序列化陷阱与性能调优实战opsForValue和opsForList的所有操作都严重依赖序列化器RedisSerializer。序列化器选不对轻则性能低下重则数据错乱、无法读取。5.1 默认的JDK序列化器为什么是“坑”Spring Boot早期版本中RedisTemplate的默认序列化器是JdkSerializationRedisSerializer。它能把任何实现了Serializable接口的对象变成字节流。但问题很多序列化结果体积大包含了完整的类信息、版本号等元数据比纯数据大很多。可读性为零在Redis CLI里用GET命令看到的是乱码无法直接调试。强耦合Java环境序列化后的数据严重依赖类的全限定名和serialVersionUID。一旦类名、包结构或字段发生改变反序列化就会失败。这在微服务多版本部署或项目重构时是噩梦。跨语言交互困难其他语言如Python、Go的应用无法读取这种格式的数据。因此在生产环境中几乎总是需要替换掉默认的JDK序列化器。5.2 常用序列化方案选型对比序列化器优点缺点适用场景StringRedisSerializer简单速度快人类可读跨语言友好。只能处理String类型的键和值。存储对象需手动转JSON字符串。键的序列化简单的字符串值计数器。Jackson2JsonRedisSerializer直接序列化对象为JSON可读性好跨语言体积相对较小。依赖Jackson库配置略复杂需提供JavaType。反序列化时需有无参构造函数。最通用的值序列化方案存储复杂对象。GenericJackson2JsonRedisSerializer在JSON中嵌入类类型信息可反序列化成具体类型无需提前指定。JSON体积稍大含类型信息有潜在的安全反序列化风险。值类型多变或无法在模板中固定类型的场景。KryoRedisSerializer序列化后体积小速度快。可读性差跨语言不支持类变更兼容性需自己处理。对性能和网络带宽有极致要求且为纯Java环境。配置示例Spring BootConfiguration public class RedisConfig { Bean public RedisTemplateString, Object redisTemplate(RedisConnectionFactory factory) { RedisTemplateString, Object template new RedisTemplate(); template.setConnectionFactory(factory); // 使用String序列化器 for KEY StringRedisSerializer stringSerializer new StringRedisSerializer(); template.setKeySerializer(stringSerializer); template.setHashKeySerializer(stringSerializer); // 使用Jackson序列化器 for VALUE Jackson2JsonRedisSerializerObject jsonSerializer new Jackson2JsonRedisSerializer(Object.class); // 可选配置ObjectMapper如关闭未知属性失败等 // jsonSerializer.setObjectMapper(...); template.setValueSerializer(jsonSerializer); template.setHashValueSerializer(jsonSerializer); template.afterPropertiesSet(); return template; } }5.3 大Value与慢查询规避无论使用哪种序列化器都要警惕“大Value”问题。Redis是内存数据库单线程处理命令。如果一个Value是几MB甚至几十MB的JSON字符串或序列化对象会导致网络传输慢获取或设置这个Key会占用大量网络带宽和时间。序列化/反序列化CPU开销大尤其是复杂的Jackson解析。阻塞其他命令Redis单线程处理这个大Key的GET/SET命令时其他所有命令都得等着。规避策略拆分对于大的对象考虑是否能用Hash拆分存储。例如一个包含大量属性的用户画像对象可以按模块拆成多个Hash Field。压缩对于文本类数据如JSON在客户端序列化后、存储前进行压缩如GZIP。但这会增加CPU开销需权衡。评估必要性问问自己真的需要把所有数据都塞进一个缓存项吗缓存应该是“热数据”的摘要而不是数据库的完整镜像。监控使用redis-cli --bigkeys或监控工具定期扫描及时发现并处理大Key。对于opsForList要警惕超长列表。一个包含几十万元素的列表执行LRANGE 0 -1或LTRIM操作可能会造成明显的延迟。对于仅用作队列的列表应确保消费者速度跟得上生产者避免堆积。对于存储历史记录的列表要定期用LTRIM修剪长度。6. 典型应用场景与代码实战剖析6.1 场景一分布式锁基于opsForValue.setIfAbsent这是setIfAbsent最经典的应用。但实现一个健壮的分布式锁需要考虑很多细节锁超时防止死锁、唯一标识防止误删、原子性释放等。虽然Redisson客户端是更好的选择但理解其原理很重要。public class SimpleDistributedLock { Autowired private RedisTemplateString, String redisTemplate; public boolean tryLock(String lockKey, String requestId, long expireSeconds) { // 使用setIfAbsent并设置过期时间 Boolean success redisTemplate.opsForValue().setIfAbsent(lockKey, requestId, expireSeconds, TimeUnit.SECONDS); return Boolean.TRUE.equals(success); // 注意Boolean和boolean的转换 } public boolean unlock(String lockKey, String requestId) { // 错误做法直接delete可能误删其他客户端持有的锁 // redisTemplate.delete(lockKey); // 正确做法使用Lua脚本保证“判断标识”和“删除锁”的原子性 String luaScript “if redis.call(‘get’, KEYS[1]) ARGV[1] then return redis.call(‘del’, KEYS[1]) else return 0 end”; DefaultRedisScriptLong script new DefaultRedisScript(luaScript, Long.class); Long result redisTemplate.execute(script, Collections.singletonList(lockKey), requestId); return result ! null result 0; } }注意这个简单实现仍有缺陷比如不具备可重入性、锁续期看门狗机制。对于生产环境建议直接使用Redisson或Spring Integration提供的分布式锁组件。6.2 场景二秒级滑动窗口限流基于opsForValue和List假设要限制一个用户每分钟只能请求10次。我们可以用List存储每次请求的时间戳。public boolean tryAcquire(String userId) { String key “rate_limit:” userId; long currentTime System.currentTimeMillis(); long windowMillis 60 * 1000L; // 1分钟 long limit 10; // 获取列表操作接口 ListOperationsString, String ops redisTemplate.opsForList(); // 移除时间窗口之外的旧时间戳 // 这里使用循环lpop实际生产中可以考虑Lua脚本保证原子性或使用Sorted Set更高效 String oldestTimeStr; while ((oldestTimeStr ops.index(key, 0)) ! null) { long oldestTime Long.parseLong(oldestTimeStr); if (currentTime - oldestTime windowMillis) { ops.leftPop(key); // 弹出过期的记录 } else { break; } } // 检查当前数量是否超限 Long size ops.size(key); if (size ! null size limit) { return false; // 超限拒绝 } // 未超限记录本次请求时间戳 ops.rightPush(key, String.valueOf(currentTime)); // 设置Key的过期时间避免冷数据永驻内存过期时间略大于窗口期 redisTemplate.expire(key, windowMillis / 1000 10, TimeUnit.SECONDS); return true; }这个例子结合了opsForList的索引查询、弹出和推送以及opsForValue的过期时间设置通过redisTemplate.expire实现了一个简单的滑动窗口计数器。更精确的实现可以使用Redis的ZSET有序集合来存储时间戳和分数用ZREMRANGEBYSCORE来清理旧数据性能更好。6.3 场景三消息队列与广播列表基于opsForList的阻塞操作实现一个简单的多消费者任务队列。生产者将任务放入列表多个消费者工作线程使用BLPOP阻塞左弹出来争抢任务。Component public class SimpleTaskQueue { Autowired private RedisTemplateString, Task redisTemplate; // 假设Task可序列化 private final ExecutorService workerPool Executors.newFixedThreadPool(5); PostConstruct public void startWorkers() { for (int i 0; i 5; i) { workerPool.submit(this::worker); } } private void worker() { ListOperationsString, Task ops redisTemplate.opsForList(); while (!Thread.currentThread().isInterrupted()) { try { // 阻塞式弹出超时时间5秒 Task task ops.leftPop(“global_task_queue”, 5, TimeUnit.SECONDS); if (task ! null) { processTask(task); } } catch (Exception e) { log.error(“Worker error”, e); // 可根据异常类型决定是否中断循环 } } } public void submitTask(Task task) { redisTemplate.opsForList().rightPush(“global_task_queue”, task); } // ... processTask 方法 }这个模式简单有效但它是一个“竞争消费者”模式一条消息只能被一个消费者处理。如果需要“发布-订阅”模式一条消息被所有消费者处理就需要使用Redis的Pub/Sub功能或者Stream数据类型这超出了opsForList的范畴。7. 常见问题、故障排查与调试技巧7.1 序列化错误最令人头疼的“ClassCastException”这是使用opsForValue和opsForList时最常见的一类错误。症状通常是数据存进去好好的取出来的时候报java.lang.ClassCastException。原因分析序列化器不一致存数据时用的Jackson2JsonRedisSerializer取数据时换成了JdkSerializationRedisSerializer或者反之。两者编码格式完全不同无法解析。类定义变更使用JDK序列化时修改了类的serialVersionUID或结构。使用Jackson序列化时修改了类的字段名或类型并且没有配置ObjectMapper忽略未知属性。多模板混用项目中有多个RedisTemplateBean配置了不同的序列化器但使用时不小心注入了错误的那个。排查步骤检查Redis中的数据直接用redis-cli连接到Redis用GET key或LRANGE key 0 -1看看数据长什么样。如果是乱码\xac\xed\x00\x05t\x00...那是JDK序列化如果是JSON字符串那是Jackson序列化。这能立刻判断序列化器是否匹配。统一配置确保整个应用尤其是存和取的两端比如不同的微服务使用完全相同序列化配置的RedisTemplate。在Spring Boot中最好通过一个Configuration类全局定义唯一的RedisTemplateBean。为Jackson配置容错在创建Jackson2JsonRedisSerializer时配置底层的ObjectMapper。ObjectMapper om new ObjectMapper(); om.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false); // 忽略未知字段 om.configure(SerializationFeature.FAIL_ON_EMPTY_BEANS, false); om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.NONE); om.setVisibility(PropertyAccessor.FIELD, JsonAutoDetect.Visibility.ANY); jsonSerializer.setObjectMapper(om);7.2 连接泄漏与性能陡降现象应用运行一段时间后Redis操作变慢甚至超时查看Redis监控发现连接数异常高。可能原因未使用连接池检查Lettuce或Jedis的连接池配置是否开启。Spring Boot默认会配置连接池但如果你手动创建RedisConnectionFactory可能会漏掉。未正确执行execute或executePipelined在低层次API使用中如果自己获取RedisConnection而没有正确关闭会导致连接泄漏。但使用opsForValue等高级接口一般不会因为它们内部会处理连接归还。慢查询阻塞如前面提到的“大Key”操作或复杂的Lua脚本会阻塞Redis单线程导致其他命令排队。管道Pipeline或事务Transaction使用不当管道用于批量发送命令但如果管道内的命令数量巨大会长时间独占连接。事务multi/exec也会在exec前独占连接。排查与解决使用redis-cli的slowlog命令查看Redis慢查询日志找到耗时的命令。检查连接池配置确保max-active、max-idle、min-idle设置合理并监控连接池状态。优化命令避免大Key将复杂操作拆解或使用更合适的数据结构。谨慎使用管道和事务明确其使用场景管道适合批量写入但不关心中间结果的场景事务用于保证一组命令的原子性。避免在管道或事务中放入过多命令。7.3 事务与管道中的opsForXxx操作RedisTemplate支持事务multi/exec和管道pipeline但opsForValue等操作在其中的行为需要特别注意。事务在RedisTemplate中事务需要将enableTransactionSupport设置为true并且事务行为与数据库事务不同。Redis事务是“打包执行”在multi和exec之间的命令会进入队列在exec时一次性执行。但是在事务内部你通过opsForValue().get()获取到的值是事务开始前的值而不是事务中已修改但未提交的值因为Redis不支持回滚和读已提交隔离。这可能会让习惯关系型数据库的开发者感到困惑。redisTemplate.setEnableTransactionSupport(true); redisTemplate.multi(); opsForValue.set(“a”, 1); Integer value opsForValue.get(“a”); // 这里get到的可能是null或旧值不是1 redisTemplate.exec();管道管道用于提升批量操作的吞吐量它将多个命令一次性发送到服务器减少RTT。RedisTemplate提供了executePipelined方法。在管道中opsForXxx操作返回的“结果”是一个占位符通常是null真正的结果会在管道执行完毕后以一个List的形式返回。ListObject results redisTemplate.executePipelined((RedisCallbackObject) connection - { for (int i 0; i 100; i) { String key “key:” i; String value “value:” i; connection.stringCommands().set(key.getBytes(), value.getBytes()); } return null; // 这里返回的值不重要 }); // results 列表包含了100个命令的返回值OK核心建议除非你非常清楚Redis事务和管道的语义并且有明确的性能需求或原子性需求否则在初期尽量使用简单的单命令操作。opsForValue和opsForList提供的单命令方法在绝大多数场景下已经足够高效和清晰。当需要批量操作时优先考虑multiSet/multiGet它们比循环单次调用或手动管道更简洁安全。