Redis 的 OBJECT 命令提供了一组用于查看键内部信息的子命令，其中 REFCOUNT 用来获取某个键所对应值对象的引用计数。这个数字反映了 Redis 内部有多少地方正在引用同一个值对象，是理解 Redis 内存共享和对象生命周期的重要窗口。通过 redis-cli 执行 OBJECT REFCOUNT mykey 即可快速得到结果，但很多使用者并不清楚这个返回值背后的具体含义，也不了解它在不同数据类型和场景下的表现差异。
本文将从引用计数机制的原理出发，逐步介绍 OBJECT REFCOUNT 命令的语法、返回值的各种情况，以及它在实际调试和优化中的适用边界。
引用计数机制在Redis中的核心作用
Redis 使用一个全局的引用计数系统来管理所有值对象（redisObject）的生命周期。每个值对象内部都有一个 refcount 字段，初始创建时为 1。当有新的键指向同一个值对象时，refcount 加 1；当某个键被删除、覆盖或过期时，对应值对象的 refcount 减 1。一旦 refcount 降为 0，Redis 就会立即释放该对象占用的内存。这种机制比垃圾回收器的延迟回收更实时，也更适合 Redis 这种内存数据库对低延迟的要求。
引用计数的另一个重要价值是支持对象共享。Redis 在启动时会预先创建从 0 到 9999 的一万个整数对象，并把这些对象的 refcount 设置为一个非常大的初始值（通常是 OBJ_SHARED_REFCOUNT，即 2147483647）。当执行 SET num 100 或 LPUSH list 200 这类命令时，如果值是可以被共享的整数，Redis 不会新创建一个整数对象，而是直接让键指向预创建的共享整数对象。因此，对这些键执行 OBJECT REFCOUNT 会返回 2147483647 或接近这个数字的结果。
需要注意的是，对象共享目前仅限于整数对象，并且只有在 maxmemory 未设置或未启用内存淘汰策略时才默认开启。字符串对象、列表、哈希等复合数据结构由于包含多个元素，无法安全地共享，所以它们的引用计数通常保持在 1。这一设计选择背后有并发修改安全性的考量，因为如果共享了复杂对象，任何修改都会影响所有引用者，而 Redis 的单线程模型也无法简单处理写时复制。
OBJECT REFCOUNT命令的语法与典型返回值
OBJECT REFCOUNT 命令的语法非常直接：OBJECT REFCOUNT key。它接受一个键名作为参数，返回该键所对应值对象的引用计数。如果键不存在，命令会返回 0。如果键存在但值为空字符串或空列表等，引用计数同样为 1，因为空对象也是独立创建的对象。
下面通过一组 redis-cli 示例来观察不同情况下的返回值。
# 连接 Redis redis-cli # 设置一个普通字符串 127.0.0.1:6379> SET greeting "hello" OK 127.0.0.1:6379> OBJECT REFCOUNT greeting (integer) 1 # 设置一个小整数（100 在共享范围内） 127.0.0.1:6379> SET num 100 OK 127.0.0.1:6379> OBJECT REFCOUNT num (integer) 2147483647 # 设置一个超过共享范围的整数 127.0.0.1:6379> SET bignum 12345 OK 127.0.0.1:6379> OBJECT REFCOUNT bignum (integer) 1 # 设置一个列表并查看引用计数 127.0.0.1:6379> RPUSH mylist "a" "b" "c" (integer) 3 127.0.0.1:6379> OBJECT REFCOUNT mylist (integer) 1
从上面的输出可以看到，字符串 greeting 和列表 mylist 的引用计数都是 1，说明它们各自拥有独立的值对象。而 num 因为值为 100，直接复用了 Redis 启动时创建的共享整数对象，引用计数显示为 2147483647。这个巨大的数字并不代表有这么多键引用了它，而是 Redis 用一个足够大的常量来标记共享对象，使得正常使用中引用计数永远不会减到 0，从而不会被错误释放。
另外，当使用 RENAME 命令重命名一个键时，值对象的引用计数不会变化，因为只是键名变了，值对象本身还是同一个。但如果使用 COPY 命令复制一个键，默认会创建值对象的新副本，引用计数为 1。可以通过 COPY 命令的 SHARED 选项（Redis 6.2 及以上）来尝试复制时共享值对象，此时引用计数会增加。
引用计数在调试与内存分析中的实际应用
在日常性能分析中，OBJECT REFCOUNT 可以帮助确认 Redis 是否正在利用共享整数对象来节省内存。例如，当业务中大量使用小整数作为缓存键的值时，如果这些整数落在 0 到 9999 范围内，Redis 可以复用同一批整数对象，从而避免为每个键单独分配内存。通过遍历一部分键并执行 OBJECT REFCOUNT，可以快速评估共享效果是否如预期。
不过，引用计数并不能等同于键的实际内存占用。Redis 中一个键的总内存开销包括：键名本身、值对象、以及可能存在的过期时间、内部字典节点等。OBJECT REFCOUNT 只反映值对象被引用的次数，既无法说明键名的大小，也无法说明值对象内部的具体编码方式。若要全面分析内存，应结合 MEMORY USAGE key 命令和 OBJECT ENCODING key 命令一起使用。OBJECT ENCODING 可以显示值对象当前使用的内部编码，例如 int、embstr、raw、ziplist、skiplist 等，这对判断内存优化空间更有帮助。
此外，引用计数在 RDB 持久化和主从复制期间可能会有特殊表现。在 RDB 加载过程中，Redis 会重建所有键值对象，此时共享对象可能不会立即被复用到，一些键的引用计数可能暂时为 1，直到加载完成后再进行对象共享处理。而在主从复制中，从节点执行相同的写命令，同样会经过对象共享逻辑，所以引用计数与主节点基本一致，但某些边缘版本中由于共享策略差异，从节点的返回结果可能略有不同。因此，OBJECT REFCOUNT 更适合在调试环境或低流量时段使用，不建议在线上高并发场景中频繁调用，以免对响应时间造成额外扰动。
OBJECT命令家族的其他子命令对比
OBJECT 命令家族除了 REFCOUNT 之外，还有 ENCODING 和 IDLETIME 两个常用子命令。ENCODING 返回键值对象的内部编码类型，例如字符串的 int、embstr、raw 编码，列表的 ziplist、linkedlist、quicklist 编码等。这个命令对于排查内存碎片和性能瓶颈非常有用，因为同一种逻辑数据结构在不同数据量和配置下可能采用完全不同的内部实现。
IDLETIME 返回自上次访问该键以来经过的秒数，可以用来发现冷数据。当 Redis 配置了 maxmemory 和 allkeys-lru 等淘汰策略时，IDLETIME 越大的键越有可能被优先淘汰。通过周期性采样 IDLETIME，可以更主动地掌握键的访问热度，但需要注意 IDLETIME 的精度受限于 Redis 内部的 LRU 时钟，大约每 100 毫秒更新一次，因此返回的秒数可能存在轻微误差。
将 REFCOUNT 与 ENCODING、IDLETIME 结合起来使用，可以构建一个更完整的键健康度检查工具。例如，对于一个值对象使用 embstr 编码且引用计数为 1 的字符串键，如果 IDLETIME 很高，说明它是一个长期未被访问的独立小对象，删除它可以释放一部分内存。而如果引用计数显示为 2147483647 且编码为 int，则说明它正在复用共享整数对象，即使删除该键也不会真正释放那部分整数对象占用的内存，因为其他键可能还在引用。
总之，OBJECT REFCOUNT 是一个轻量但含义深刻的调试命令。它揭示了 Redis 内部对象共享和引用计数的运行状态，对于理解 Redis 的内存模型和优化缓存设计很有价值。使用时应结合具体场景和命令限制，避免将引用计数误解为真实内存占用或键的活跃度指标。
Redis OBJECT REFCOUNT引用计数内存管理修改时间：2026-08-19 16:35:20