如果你仔细研究过 Redis 中各种实现细节，你会发现为了性能，Redis 真的是不遗余力。

作为一种高性能的键值存储系统，Redis 广泛用于缓存、会话管理、消息队列等多种场景。

为了提高 Redis 在处理大量数据时的性能和效率，Redis 设计并实现了对象共享池（Shared Object Pool）这一内部机制。

那么接下来松哥就和大家详细说一说 Redis 中的对象共享池。

一 设计目的

Redis 的对象共享池主要用于复用一些常用的数据对象，以减少内存的开销。

在 Redis 中，一些常用的数据对象，主要是小整数（如 0 到 9999）等，是不会被改变的，因此可以安全地共享使用而无需重复创建。

例如你设置 set k1 99 和 set k2 99，这时 k1 和 k2 其实指向的是同一个对象。

通过共享这些对象，Redis 能够显著降低内存的使用量，并减少对象的创建和销毁时间，从而提升整体性能。

二 工作原理

在 Redis 服务器启动时，会预先创建并存储一些常用的对象到一个全局的哈希表中，这个哈希表就是对象共享池。

当 Redis 需要处理一个键值对时，会首先检查这个键值对中的值是否已经在对象共享池中。如果已存在，Redis 将直接引用该对象，而不是创建一个新的对象。

三 支持的对象类型

目前主要是支持小整型，也就是 0～9999 之间的整数，浮点型数据不支持。

四 应用场景

对象共享池在多种场景下都能显著提升 Redis 的性能和效率，特别是在处理大量重复数据时。例如，在 Web 应用中，许多缓存的键值对可能包含相同的值，通过对象共享池，这些值可以被多个键值对共享，从而节省大量内存。

注意事项

五 实际案例

为了通过实际案例证明 Redis 中对象共享池的存在，我们可以结合 Redis 的内部机制和一些实际操作来进行分析。虽然 Redis 的官方文档没有直接提及“对象共享池”这一术语，但我们可以从 Redis 如何处理整数对象的共享中看到其背后的共享机制。

假设我们有一个 Redis 服务器，它用于存储和访问大量的键值对。在这些键值对中，有一部分键对应的值是常见的小整数。

我们来执行以下命令：

 k1 OBJECT REFCOUNT k1 k2 OBJECT REFCOUNT k1

这里我要跟大家解释下。

OBJECT REFCOUNT 命令理论上可以查看某一个 key 对应的 value 被引用的次数。

所以我们期望第一次执行 OBJECT REFCOUNT k1 的时候返回 1，第二次执行 OBJECT REFCOUNT k1 的时候返回 2，但是实际上却并非如此，每次都是返回 2^31-1。

虽然这里并没有返回我们想要的值，但是大家可以看到，OBJECT REFCOUNT k1 返回的值确实和 value 为字符串的 key 的返回值是不同的。

松哥来解释下原因。

通过分析 Redis 源码，松哥发现新版本的 redis 中 OBJ_SHARED_INTEGERS 变量定义了共享整数 10000，并且定义不被销毁的全局对象的引用数量 OBJ_SHARED_REFCOUNT 为 INT_MAX，INT_MAX = 2^31 - 1 =2147483647。

源码位置在：。

并且从源码中可以看到当把一个对象设置为共享时候就会把 refcount 设置为 INT_MAX。

源码位置在：。

从这里就能看出，如果某个对象的引用次数是 2^31-1，那么就说明这个对象是一个引用对象。

Redis 实战

Redis 博大精深，然而很多时候我们说到 Redis，却只知道缓存或者分布式锁，面试的时候也只能从这两个角度去准备。

但是在实际面试中，Redis 这块能够发挥的地方可太多了：

还有很多，我就不一一列举了。