外碎片问题

外碎片问题 

　　在内存的管理中，如果频繁地请求和释放不同大小的内存，会导致在内存池存在很多碎片化的内存区域。简单地说，因为释放的内存不是连续的，导致这里释放一块，那里释放一块。这样就很容易出现问题，当一个请求过来，需要开辟5M的内存空间，在内存池中有很多4M的，就是没有5M的，即没有足够大的空闲连续内存区域满足要求，这就是外碎片问题。

　　InnoDB的外碎片问题的发生是因为内存池存在太多的碎片区域导致无法分配一个大块的连续内存。

　　Linux内核的外碎片问题是因为分配页框的内存块中分散了许多小块的空闲页框，即使这些页框空闲的，其他需要分配连续页框的应用也很难得到满足。

相同点：所使用的伙伴系统在原理一致 

　　InnoDB在解决外碎片问题上是模仿Linux内核的内存管理系统使用的伙伴系统，所以两者在原理上是一致。

　　伙伴系统的核心思想：将内存池中的内存以2的幂分区，这样就产生了1个单位、2个单位、4个单位、8个单位......的内存区，每个内存区就是相同单位的集合，将相同单位的内存连接成一个链表。内存就分成了N个内存区链表。当你需要申请64个单位的时候，就再64个单位的链表上查找，如果有空闲的内存，就直接返回。如果没有，就128个单位的链表上查找。如果存在128个单位的内存，就将此内存分成两个64个单位的内存，将一个64个单位返回给需求，将另外一个64个单位的内存挂到64个单位链表中。所谓的伙伴系统的伙伴，就是指分割体之间的关系。如果在128个单位链表中找不到，如继续往上找，真的没有，就只能SORRY了。

不同点 

　　1.针对的对象不同。InnoDB的伙伴系统使用在通用内存池中，针对的是内存区域。Linux内核的伙伴系统使用在页框中。其实页框也是内存模型，所以两者的针对的对象可以说是一致的，但是在叫法上不同，这里就勉强的列为不同点之一。

　　2.分区数目不同。InnoDB分为64个内存区链表，Linux内核是分为11个块链表。

　　3.单位不同。InnoDB的内存区直接以字节为单位，Linux内核以页框为单位，最大的有连续1024个页框，对应4M的内存大小。

对伙伴系统的思考 

　　碎片问题的产生是因为在内存上分配上没有规则，对于一块内存就一直按照顺序分配下去，这样的无节制的分配导致了释放后再分配的时候内存大小的随机性。伙伴系统的解决核心就是制定一个规则，按照这个规则走，使内存变得可控了许多。

　　伙伴系统是不是外碎片问题的最佳解决方案呢？我觉得应该还有更好的。毕竟伙伴系统在分配问题上没有做到物尽其用。就用InnoDB来说，你每次申请时候只能是2的N次幂，并不能说我指定要61B的内存，你就给我这么多，你给的还是64B给我，所以在这个问题上我觉得应该还有优化的地方，但至今我还没有一个好的想法，请让我慢慢酝酿......