之前的文章里介绍过c++的allocator。既然c++标准库已经有一份标准实现，我们为什么还要自己去实现allocator呢？出于性能的考虑，很多程序都会实现自己的allocator，避免使用标准库allocator。标准库allocator究竟在那些方面会影响程序性能，下面一一分析：
1.标准allocator会涉及system call，导致程序出现user - kernel - user的模式切换。模式切换需要额外的cpu周期。频繁地使用标准allocator分配内存(例如在一个while循环内)，模式切换所消耗的cpu周期就会叠加。自定义的allocator使用预分配内存池，避免发起system call，提升内存分配及回收的效率。
2.标准allocator发起system call，除了引起模式切换外，还会引发另一个更严重的问题：线程状态切换——由执行切换为等待(阻塞)。首先，system call是操作系统控制线程状态切换的一个入口点，只要线程发起了system call，就等于告诉操作系统，可以进行状态切换，至于是否切换，就要看操作系统的调度策略。其次，如果这个system call发起了长时间的操作，那么，这个线程必然会切换到阻塞状态。不要忘记，内存分配可能是一个长时间的操作，例如，当前物理内存紧缺，需要换页的时候(引发磁盘IO)。当一段关键代码(在临界区)或者一段界面线程执行的代码由于使用标准allocator而导致线程切换为阻塞状态，后果可想而知。
3.标准allocator可能会引起内存碎片化。碎片化后，极端情况下会引起一些连锁反应：首先，导致换页频繁，继而影响内存分配效率(可能会进入阻塞状态，见第2点)；其次，当碎片情况继续恶化，被换出的内存除了堆内存外，还可能包括程序的工作集。当程序的工作集也换出后，线程的一个jmp就可能被切换到阻塞状态(jmp的目标地址已被换出)，程序执行效率大大降低。