baiyan
全部视频:https://segmentfault.com/a/11...
源视频地址:http://replay.xesv5.com/ll/24...
malloc和free函数思考
- 字符串的非二进制安全:如果存的字符串内容中带有\0,那么它会被当做字符串结束标志,提前判定字符串结束,而并非到字符串末尾正常结束。
- malloc一块内存之后,它的size是存在哪里的?
- free一块内存,如何知道free多大的内存?
- 解决方案:在分配的内存地址空间附近额外分配一块内存记录size。
- malloc()系统调用是非常慢的,相当于你去面包店买一个面包,需要和面、发酵...等等一系列繁琐的工作,为了避免多次从用户态切换到内核态进行内存分配,PHP会先向操作系统内核申请一块大的内存空间,然后由用户态的PHP虚拟机所实现自己的一套内存管理机制,来管理这一大块内存。以后再申请内存,只需要PHP虚拟机来实现具体的内存分配操作即可,不用再向内核申请。这样就减少了向操作系统申请内存的次数,以空间换时间,避免频繁的进行系统调用,提高了性能。
操作系统内存基本概念
- chunk:2MB大小内存
- page:4KB大小内存
- 二者关系:一个chunk由512个page组成(2MB/4KB = 512)(512 = 2^9,4KB = 2^12,2MB = 2^21)。
- mmap():系统调用,将一个文件或者其它对象映射进内存,分配chunk。
- 内存不够用怎么办:选择一个占用内存大的进程并挂起,并将其使用的内存置换到硬盘上,分配给新进程使用。当挂起进程被唤醒的时候,唤醒进程会到内存中找对应的页,但是无法找到,故产生缺页中断,操作系统会将硬盘中的页置换回内存,供唤醒进程继续运行。
PHP内存分配
PHP内存分类:small/large/huge
- small:size <= 3KB(有30种规格)
- large:3KB < size <= 2MB - 4KB
- huge:size >= 2MB - 4KB
- 思考:为什么large规格内存是 <= 2MB - 4KB?
答:在small和large内存分配规格中,首先会分配一个chunk,chunk的第一个page中存有一个结构体,用来保存chunk中每一个page的相关存储信息(即zend_alloc.h中的mm_heap结构体)。但是huge规格不需要,直接拿来用即可(因为huge内存已经大于2MB(即一个chunk)),无需记录内部存储细节信息)。思考一个问题:一个page有4KB,至于用这么大的空间去存吗?
struct _zend_mm_heap {
#if ZEND_MM_CUSTOM
int use_custom_heap;
#endif
#if ZEND_MM_STORAGE
zend_mm_storage *storage;
#endif
#if ZEND_MM_STAT
size_t size; /* 当前使用内存(PHP库函数memory_get_usage()方法就是取此字段的值)*/
size_t peak; /* 内存使用峰值 */
#endif
zend_mm_free_slot *free_slot[ZEND_MM_BINS]; /*它是一个大小为ZEND_MM_BINS = 30的数组,每个存储单元是一个单向链表,用来挂载30种不同规格的small内存(下面会讲)*/
#if ZEND_MM_STAT || ZEND_MM_LIMIT
size_t real_size; /* current size of allocated pages */
#endif
#if ZEND_MM_STAT
size_t real_peak; /* peak size of allocated pages */
#endif
#if ZEND_MM_LIMIT
size_t limit; /* memory limit */
int overflow; /* memory overflow flag */
#endif
zend_mm_huge_list *huge_list; /* list of huge allocated blocks */
zend_mm_chunk *main_chunk;
zend_mm_chunk *cached_chunks; /* list of unused chunks */
int chunks_count; /* number of alocated chunks */
int peak_chunks_count; /* peak number of allocated chunks for current request */
int cached_chunks_count; /* number of cached chunks */
double avg_chunks_count; /* average number of chunks allocated per request */
int last_chunks_delete_boundary; /* numer of chunks after last deletion */
int last_chunks_delete_count; /* number of deletion over the last boundary */
#if ZEND_MM_CUSTOM
union {
struct {
void *(*_malloc)(size_t);
void (*_free)(void*);
void *(*_realloc)(void*, size_t);
} std;
struct {
void *(*_malloc)(size_t ZEND_FILE_LINE_DC ZEND_FILE_LINE_ORIG_DC);
void (*_free)(void* ZEND_FILE_LINE_DC ZEND_FILE_LINE_ORIG_DC);
void *(*_realloc)(void*, size_t ZEND_FILE_LINE_DC ZEND_FILE_LINE_ORIG_DC);
} debug;
} custom_heap;
#endif
};
- 重点关注中文注释的部分,我们看到zend_mm_heap结构体并不是很大,那么继续关注其中重点的zend_mm_chunk结构体:
struct _zend_mm_chunk {
zend_mm_heap *heap;
zend_mm_chunk *next;
zend_mm_chunk *prev;
uint32_t free_pages; /* number of free pages */
uint32_t free_tail; /* number of free pages at the end of chunk */
uint32_t num;
char reserve[64 - (sizeof(void*) * 3 + sizeof(uint32_t) * 3)];
zend_mm_heap heap_slot; /* used only in main chunk */
zend_mm_page_map free_map; /* 512 bits or 64 bytes */
zend_mm_page_info map[ZEND_MM_PAGES]; /* 2 KB = 512 * 4 */
};
- 1个chunk有512个page。
- 第一个heap字段是zend_mm_heap类型的结构体指针,方便在512个page中直接找到第一个存储额外信息的page。下面两个next和prev字段构成一个双向链表,用于chunk与chunk之间的连接。
- 重点关注倒数第二个字段zend_mm_page_map类型的字段,有512bit(即64B),每一个bit用来存储当前这个chunk中的每一个页(因为一共有512个页)是否使用。
- 除了看它是否使用,还要看每个page的具体使用的大小和其他相关情况并记录相关信息。
- 最后一个zend_mm_page_info类型的字段解决了上述问题。ZEND_MM_PAGES = (ZEND_MM_CHUNK_SIZE / ZEND_MM_PAGE_SIZE) = 2MB/4KB = 512个存储单元,每个存储单元是typedef uint32_t zend_mm_page_info类型,即4B大小用来存储额外的使用情况信息,这个字段一共是2KB。用来存储使用的大小和额外信息,所以这里2KB加上剩余字段,差不多会使用4KB的空间,所以chunk的第一个page需要留出来记录这些信息。
- 那么这个page_info(uint32_t),这里32位是如何利用的呢,先看如何标记内存规格
#define ZEND_MM_IS_FRUN 0x00000000
#define ZEND_MM_IS_LRUN 0x40000000
#define ZEND_MM_IS_SRUN 0x80000000
- 第32位为1代表small内存,即0x8。然后低5位(2^5 > 30种规格)存储bit_num(即ZEND_MM_BINS_INFO宏的索引,以便快速找到所需页的数量等信息(下面会讲))
- 第31位为1代表large内存,即0x4。然后低10位表示分配的页数(>= 512即可)为什么不用9位呢?2^9 = 512足够了???
- 第31、32位都是1,即0xC,低5位表示bit_num,这里3KB规格就是29,16~25bit表示偏移量。以申请3KB为例,一定是3个4KB的page,分为4个3KB(见下文)。第一个3KB就是0xC作为连续分配4个3KB的起始标记(约定),偏移量是0,bit_num是29;第二个3KB就是0x8,偏移量是1,bit_num同样是29;第3、4个3KB内存同理,只是偏移量不同。
- _emalloc() -> zend_mm_alloc_heap() ->分配三种内存规格的其中一种:
static zend_always_inline void *zend_mm_alloc_heap(zend_mm_heap *heap, size_t size ZEND_FILE_LINE_DC ZEND_FILE_LINE_ORIG_DC)
{
void *ptr;
if (size <= ZEND_MM_MAX_SMALL_SIZE) {
ptr = zend_mm_alloc_small(heap, size, ZEND_MM_SMALL_SIZE_TO_BIN(size) ZEND_FILE_LINE_RELAY_CC ZEND_FILE_LINE_ORIG_RELAY_CC);
return ptr;
} else if (size <= ZEND_MM_MAX_LARGE_SIZE) {
ptr = zend_mm_alloc_large(heap, size ZEND_FILE_LINE_RELAY_CC ZEND_FILE_LINE_ORIG_RELAY_CC);
return ptr;
} else {
return zend_mm_alloc_huge(heap, size ZEND_FILE_LINE_RELAY_CC ZEND_FILE_LINE_ORIG_RELAY_CC);
}
}
small内存
- 注意一个page可以包含多个small内存块,首先满足一次性分配的page总量必须能够除尽分配的规格大小。换句话说,尽量不要有内存碎片。例如:分配3KB的small内存,不能只分配1个page,因为会剩下1KB大小的内存碎片,不能够再次利用并分配。所以需要求得一个规格和4KB的最小公倍数,作为总的分配空间。但是如果最小公倍数过大,导致所需要的page太多,那么退而求其次,即使留有很少的内存碎片,也算是可以满足需求的。下面举几个例子:
- 例1:假如分配8B规格的small内存:我们先找最小的可以除尽8B的page大小。因为4KB可以除尽8B,所以我们取1个page就够了,故一共正好可以分成512个8B的内存。我们取1个8B内存返回给用户,然后剩余511个8B内存会挂在zend_mm_heap结构体的zend_mm_free_slot *free_slot[ZEND_MM_BINS]字段中。这里ZEND_MM_BINS宏 = 30,恰好这30个数组单元对应30种small内存规格,共有30个单向链表,每一个单向链表都是挂载的多分配的内存。如上例中的8B内存,就会挂载剩下多分配的511个8B内存。当下次再次有分配请求的时候,直接从链表上拿即可,不用再去重新分配。同时也避免了内存碎片的产生。当释放内存的时候,直接利用头插法(相比尾插法复杂度O(1))插入到链表头部即可。
- small内存最小的分配规格就是8B,因为指针在64位系统下是8B,能够满足free_slot字段单向链表的需求。
- 例2:假如分配3KB规格的small内存:我们同样先找可以整除3KB的page大小。因为4KB不可以除尽3KB,所以1个page虽然可以满足3KB的分配需求,但是还是会留有1KB的内存碎片,所以我们不能直接拿1个page来用。我们取最小的可以整除3KB的4KB倍数,求得该值为3(4KB * 3 / 3KB = 4)个3KB大小的内存块。那么同样我们取1个3KB内存返回给用户,剩余3个3KB内存挂在上面的zend_mm_heap结构体中free_slot字段的链表上,等待后续的分配请求。
例3:假如分配40B规格的small内存,为什么下面代码也仅仅用了1个page,那是因为4KB和40B的最小公倍数过大,导致一次性申请的page太多,所以不能一味的找二者的最小公倍数,所以退而求其次,只分配1个page。虽然4096/40 = 102.5,代码中直接取了102作为最终分配的数量。第1个返回给用户,剩下101个挂在free_slot链表上等待后续的分配请求。
- 下面是所有的small内存分配规格:
/* bin_num, size, count, pages */
/*数组下标,分配规格大小,共能分配多少个这样规格大小的内存块,需要的页的数量*/
#define ZEND_MM_BINS_INFO(_, x, y) \
_( 0, 8, 512, 1, x, y) \
_( 1, 16, 256, 1, x, y) \
_( 2, 24, 170, 1, x, y) \
_( 3, 32, 128, 1, x, y) \
_( 4, 40, 102, 1, x, y) \
_( 5, 48, 85, 1, x, y) \
_( 6, 56, 73, 1, x, y) \
_( 7, 64, 64, 1, x, y) \
_( 8, 80, 51, 1, x, y) \
_( 9, 96, 42, 1, x, y) \
_(10, 112, 36, 1, x, y) \
_(11, 128, 32, 1, x, y) \
_(12, 160, 25, 1, x, y) \
_(13, 192, 21, 1, x, y) \
_(14, 224, 18, 1, x, y) \
_(15, 256, 16, 1, x, y) \
_(16, 320, 64, 5, x, y) \
_(17, 384, 32, 3, x, y) \
_(18, 448, 9, 1, x, y) \
_(19, 512, 8, 1, x, y) \
_(20, 640, 32, 5, x, y) \
_(21, 768, 16, 3, x, y) \
_(22, 896, 9, 2, x, y) \
_(23, 1024, 8, 2, x, y) \
_(24, 1280, 16, 5, x, y) \
_(25, 1536, 8, 3, x, y) \
_(26, 1792, 16, 7, x, y) \
_(27, 2048, 8, 4, x, y) \
_(28, 2560, 8, 5, x, y) \
_(29, 3072, 4, 3, x, y)
- 思考:给一个size,如何确定它的bin_num(也就是索引),从而快速找到count和pages?
static zend_always_inline int zend_mm_small_size_to_bin(size_t size)
{
...
unsigned int t1, t2;
if (size <= 64) {
/* we need to support size == 0 ... */
return (size - !!size) >> 3;
} else {
t1 = size - 1;
t2 = zend_mm_small_size_to_bit(t1) - 3;
t1 = t1 >> t2;
t2 = t2 - 3;
t2 = t2 << 2;
return (int)(t1 + t2);
}
#endif
}
- 当size <= 64的时候,size会递增8,那么直接>>3位(除以8)就可以得到索引的偏移量,很好理解。这里的!!size是为了兼容size = 0的情况,这样在右移3位之前就不会出现负值;减去!!size(即减1)是为了兼容size为8B规格等边界情况。
- 当size > 64的时候,详情参考:small内存规格的计算 核心思想:可以将size看成等差数列,按照公差分组。首先找出当前size属于哪个组,在组内的偏移量是多少,最终把二者相加。
- small内存分配流程:
static zend_always_inline void *zend_mm_alloc_small(zend_mm_heap *heap, size_t size, int bin_num ZEND_FILE_LINE_DC ZEND_FILE_LINE_ORIG_DC)
{
...
if (EXPECTED(heap->free_slot[bin_num] != NULL)) {
zend_mm_free_slot *p = heap->free_slot[bin_num];
heap->free_slot[bin_num] = p->next_free_slot;
return (void*)p;
} else {
return zend_mm_alloc_small_slow(heap, bin_num ZEND_FILE_LINE_RELAY_CC ZEND_FILE_LINE_ORIG_RELAY_CC);
}
}
- 如果free_slot上挂载的多余分配的内存不是空,那么直接从free_slot链表的第一个位置上拿就可以了,然后链指针向后移,等待下次内存分配。否则调用zend_mm_alloc_small_slow函数,注意这个slow就代表重新申请chunk、分配page等等,这里暂不展开。
内存对齐
- 内存对齐:所申请的内存返回的起始地址都是逻辑地址(下面会讲),且该地址一定是2MB的整数倍,这就是内存对齐。在PHP中,可以判定一定是申请的huge规格的内存。因为small和large内存的第一个page存放了zend_mm_heap结构体,肯定不是2MB地址的整数倍。这样可以快速计算出当前地址属于第几个chunk。比如地址是4096,就属于第3个chunk。
- 所以内存对齐的优点就是如果对齐了,就可以直接判断是huge规格,不需要额外存储用于以后判断的字段。
- x64体系结构的计算机的地址共有64位,任何一个内存地址都可以分为首地址 + 偏移量,如1019地址(10进制) = 1000(首地址) + 19 (偏移量);从二进制角度来看,2MB = 10 0000 0000 0000 0000 0000,低21位全部为0(偏移量为0),高43位为首地址(第22位为1,高64-22 = 42位全部为0)就构成了64位的逻辑地址。这样可以方便地进行逻辑地址与物理地址的转换。
- 向操作系统申请内存都是以页为单位,所以申请的内存都是4KB的整数倍,不会出现4K+1这种逻辑地址。
- 思考:PHP向操作系统申请内存是以chunk为单位,但是操作系统只返回4KB整数倍的内存起始地址,并不是2MB内存的起始地址,一个chunk中,分配到2MB整数倍起始地址是1/512概率,如何让操作系统申请的地址直接是2MB的整数倍呢?
- 答案:多申请一部分存储空间,掐头去尾,保证起始地址2MB对齐。
gdb调试相关
- gdb需要指定一个可执行的二进制程序来进行调试,相关命令用法google即可,常用r/b/n/s/p
- 当利用gdb b main的时候,为什么php没有main()入口函数却仍可以正常执行上述gdb命令?因为虚拟机会默认帮助你加一个main()和return
- 编译器优化:将inline函数直接注入到函数里面去,把宏进行替换等等,所以编译的时候为方便调试需要禁用编译器优化
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。