架构之较小整数处理

本文通过常见面试题来试图分析不同语言或软件服务中利用小的整数来节省内存的现象

常见面试题

[java面试] Integer a1 = 100; Integer a2 = 100; a1 == a2的运行结果及原因?
解答: a1 == a2的结果是true
原因是Integer 内部用到了一个"享元模式"的设计, 针对-128到127之间的数字做了一个缓存, 使用Integer a1 = 100这种方式赋值的时候.Java默认会通过valueOf这个方法对100这个数字进行一个装箱操作, 从而触发了一个缓存机制.使得a1和a2指向了同一个Integer的内存地址.

[Python面试]：假设你使用的是官方的CPython，说出下面代码的运行结果。
点评：下面的程序对实际开发并没有什么意义，但却是CPython中的一个大坑，这道题旨在考察面试者对官方的Python解释器到底了解到什么程度。

a, b, c, d = 1, 1, 1000, 1000
print(a is b, c is d)

def foo():
    e = 1000
    f = 1000
    print(e is f, e is d)
    g = 1
    print(g is a)

foo()

运行结果：

True False
True False
True

上面代码中a is b的结果是True但c is d的结果是False，这一点的确让人费解。CPython解释器出于性能优化的考虑，把频繁使用的整数对象用一个叫small_ints的对象池缓存起来造成的。small_ints缓存的整数值被设定为[-5, 256]这个区间，也就是说，在任何引用这些整数的地方，都不需要重新创建int对象，而是直接引用缓存池中的对象。如果整数不在该范围内，那么即便两个整数的值相同，它们也是不同的对象。

CPython底层为了进一步提升性能还做了另一个设定，对于同一个代码块中值不在small_ints缓存范围内的整数，如果同一个代码块中已经存在一个值与其相同的整数对象，那么就直接引用该对象，否则创建新的int对象。需要大家注意的是，这条规则对数值型适用，但对字符串则需要考虑字符串的长度，这一点大家可以自行证明。

扩展：如果你用PyPy（另一种Python解释器实现，支持JIT，对CPython的缺点进行了改良，在性能上优于CPython，但对三方库的支持略差）来运行上面的代码，你会发现所有的输出都是True。

[redis面试] redis中哈希的实现方式?
哈希对象的编码可以是 ziplist 或者 hashtable。

当使用ziplist，也就是压缩列表作为底层实现时，新增的键值对是保存到压缩列表的 表尾.
hashtable 编码的哈希表对象底层使用字典数据结构，哈希对象中的每个键值对都使用一个字典键值对。
当同时满足下面两个条件时，使用ziplist（压缩列表）编码：
1、列表保存元素个数小于512个
2、每个元素长度小于64字节
不能满足这两个条件的时候，使用 hashtable 编码。