哈喽~明天带你们理解python3.6当前字典为什么有序并且效率更高呢？
在Python 3.5（含）以前，字典是不能保障程序的，键值对A先插入字典，键值对B后插入字典，然而当你打印字典的Keys列表时，你会发现B可能在A的后面。
然而从Python 3.6开始，字典是变成有程序的了。你先插入键值对A，后插入键值对B，那么当你打印Keys列表的时候，你就会发现B在A的前面。
不仅如此，从Python 3.6开始，上面的三种遍历操作，效率要高于Python 3.5之前：
python">for key in 字典 for value in 字典.values() for key, value in 字典.items()
从Python 3.6开始，字典占用内存空间的大小，视字典外面键值对的个数，只有原来的30%~95%。
Python 3.6到底对字典做了什么优化呢？为了阐明这个问题，咱们须要先来说一说，在Python 3.5（含）之前，字典的底层原理。
当咱们初始化一个空字典的时候，CPython的底层会初始化一个二维数组，这个数组有8行，3列，如上面的示意图所示：
my_dict = {}
'''
此时的内存示意图
[[---, ---, ---],
[---, ---, ---],
[---, ---, ---],
[---, ---, ---],
[---, ---, ---],
[---, ---, ---],
[---, ---, ---],
[---, ---, ---]]
'''
当初，咱们往字典外面增加一个数据：
my_dict['name'] = 'kingname' ''' 此时的内存示意图 [[---, ---, ---], [---, ---, ---], [---, ---, ---], [---, ---, ---], [---, ---, ---], [1278649844881305901, 指向name的指针, 指向kingname的指针], [---, ---, ---], [---, ---, ---]] '''
这里解释一下，为什么增加了一个键值对当前，内存变成了这个样子：
首先咱们调用Python 的hash函数，计算name这个字符串在以后运行时的hash值：
>>> hash('name')
1278649844881305901
特地留神，我这里强调了『以后运行时』，这是因为，Python自带的这个hash函数，和咱们传统上认为的Hash函数是不一样的。Python自带的这个hash函数计算出来的值，只能保障在每一个运行时的时候不变，然而当你敞开Python再从新关上，那么它的值就可能会扭转，如下图所示：
假如在某一个运行时外面，hash(‘name’)的值为1278649844881305901。当初咱们要把这个数对8取余数：
>>> 1278649844881305901 % 8 5
余数为5，那么就把它放在刚刚初始化的二维数组中，下标为5的这一行。因为name和kingname是两个字符串，所以底层C语言会应用两个字符串变量寄存这两个值，而后失去他们对应的指针。于是，咱们这个二维数组下标为5的这一行，第一个值为name的hash值，第二个值为name这个字符串所在的内存的地址（指针就是内存地址），第三个值为kingname这个字符串所在的内存的地址。
当初，咱们再来插入两个键值对：
my_dict['age'] = 26 my_dict['salary'] = 999999 ''' 此时的内存示意图 [[-4234469173262486640, 指向salary的指针, 指向999999的指针], [1545085610920597121, 执行age的指针, 指向26的指针], [---, ---, ---], [---, ---, ---], [---, ---, ---], [1278649844881305901, 指向name的指针, 指向kingname的指针], [---, ---, ---], [---, ---, ---]] '''
那么字典怎么读取数据呢？首先假如咱们要读取age对应的值。
此时，Python先计算在以后运行时上面，age对应的Hash值是多少：
>>> hash('age')
1545085610920597121
当初这个hash值对8取余数：
>>> 1545085610920597121 % 8 1
余数为1，那么二维数组外面，下标为1的这一行就是须要的键值对。间接返回这一行第三个指针对应的内存中的值，就是age对应的值26。
当你要循环遍历字典的Key的时候，Python底层会遍历这个二维数组，如果以后行有数据，那么就返回Key指针对应的内存外面的值。如果以后行没有数据，那么就跳过。所以总是会遍历整个二位数组的每一行。
每一行有三列，每一列占用8byte的内存空间，所以每一行会占用24byte的内存空间。
因为Hash值取余数当前，余数可大可小，所以字典的Key并不是依照插入的程序寄存的。
留神，这里我省略了与本文没有太大关系的两个点：
1.凋谢寻址，当两个不同的Key，通过Hash当前，再对8取余数，可能余数会雷同。此时Python为了不笼罩之前已有的值，就会应用凋谢寻址技术从新寻找一个新的地位寄存这个新的键值对。
2.当字典的键值对数量超过以后数组长度的2/3时，数组会进行扩容，8行变成16行，16行变成32行。长度变了当前，原来的余数地位也会发生变化，此时就须要挪动原来地位的数据，导致插入效率变低。
在Python 3.6当前，字典的底层数据结构产生了变动，当初当你初始化一个空的字典当前，它在底层是这样的：
my_dict = {}
'''
此时的内存示意图
indices = [None, None, None, None, None, None, None, None]
entries = []
'''
当你初始化一个字典当前，Python独自生成了一个长度为8的一维数组。而后又生成了一个空的二维数组。
当初，咱们往字典外面增加一个键值对：
my_dict['name'] = 'kingname' ''' 此时的内存示意图 indices = [None, 0, None, None, None, None, None, None] entries = [[-5954193068542476671, 指向name的指针, 执行kingname的指针]] '''
为什么内存会变成这个样子呢？咱们来一步一步地看：
在以后运行时，name这个字符串的hash值为-5954193068542476671，这个值对8取余数是1：
>>> hash('name')
-5954193068542476671
>>> hash('name') % 8
1
所以，咱们把indices这个一维数组外面，下标为1的地位批改为0。
这里的0是什么意思呢？0是二位数组entries的索引。当初entries外面只有一行，就是咱们刚刚增加的这个键值对的三个数据：name的hash值、指向name的指针和指向kinganme的指针。所以indices外面填写的数字0，就是刚刚咱们插入的这个键值对的数据在二位数组外面的行索引。
好，当初咱们再来插入两条数据：
my_dict['address'] = 'xxx'
my_dict['salary'] = 999999
'''
此时的内存示意图
indices = [1, 0, None, None, None, None, 2, None]
entries = [[-5954193068542476671, 指向name的指针, 执行kingname的指针],
[9043074951938101872, 指向address的指针，指向xxx的指针],
[7324055671294268046, 指向salary的指针, 指向999999的指针]
]
'''
当初如果我要读取数据怎么办呢？如果我要读取salary的值，那么首先计算salary的hash值，以及这个值对8的余数：
>>> hash('salary')
7324055671294268046
>>> hash('salary') % 8
6
那么我就去读indices下标为6的这个值。这个值为2.
而后再去读entries外面，下标为2的这一行的数据，也就是salary对应的数据了。
新的这种形式，当我要插入新的数据的时候，始终只是往entries的前面增加数据，这样就能保障插入的程序。当咱们要遍历字典的Keys和Values的时候，间接遍历entries即可，外面每一行都是有用的数据，不存在跳过的状况，缩小了遍历的个数。
老的形式，当二维数组有8行的时候，即便无效数据只有3行，但它占用的内存空间还是 8 24 = 192 byte。但应用新的形式，如果只有三行无效数据，那么entries也就只有3行，占用的空间为3 24 =72 byte，而indices因为只是一个一维的数组，只占用8 byte，所以一共占用 80 byte。内存占用只有原来的41%。
转载请注明原文链接：关于python:带你了解Python-36以后字典为什么有序并且效率更高
