现象描述：
        SMP下 RTP程序跑在Core 4核的处理器上，测试RTP程序内创建了1000个任务（线程），每个任务会有一些涉及到内存申请（malloc）和释放（free）的操作，如STL vector的操作（任务间无互斥，vector为栈上对象），测试下来查看CPU占用率大概在30%左右，cpu spy查看4核CPU负载，明显地，CPU 0 出现了较高负载现象，其余核心负载较低。Suspend所有任务查看堆栈，发现几乎所有任务都在等待同一个互斥信号量，这个互斥信号量是VxWorks内部Mem Partition Alloc/Free调用的，应该是内存池的同一个分区内出现了大量申请和释放的操作，造成大量互斥现象的。
        同样的测试在Windows上进行，可以发现，Windows的CPU可以达到近乎多核满载的效果。看上去应该是VxWorks本身的内存管理对于多核不太友好（如同一内存区管理只用了一个互斥信号量，没有再做分区，去实现负载平衡），当然实际应用应该尽量避免高频次的内存分配释放去提升CPU的利用率。

那么，针对此现象，目前有三个方向
① 是否参数配置不合理，导致内存分配效率较低，如果不合理，如何改善
② 是否需要建立用户层的内存池，建立多个内存池，针对不同的内存申请释放位置进行优化，避免内存申请释放时阻塞在同一互斥信号量中
③ 减小用户层的malloc/free频次

针对①方向，查阅了相关文档，发现VxWorks，配置中有Memory caching component，该库提供了VxWorks内核堆管理器memPartLib的扩展，以提高经常执行动态内存分配的任务的执行速度。通过将争用减少到堆管理器的关键部分（由互斥信号量序列化）来实现加速。减少这种争用在多核（SMP）系统上尤为重要。该实现依赖于任务私有数据结构，因此任务通常可以分配和释放内存块，而无需使用锁。从概念上讲，这相当于内存块的缓存，可以在需要时快速重用。支持malloc / free的块大小如下：

1.     编号     块大小           适用块范围大小-----   ------------      -----------------------0       16 bytes          0 - 16 bytes1       32 bytes         17 - 32 bytes2       48 bytes         33 - 48 bytes3       64 bytes         48 - 64 bytes4       80 bytes         65 - 80 bytes5       96 bytes         81 - 96 bytes6       112 bytes        97 - 112 bytes7       128 bytes       113 - 128 bytes8       160 bytes       129 - 160 bytes9       192 bytes       161 - 192 bytesa       224 bytes       193 - 224 bytesb       256 bytes       225 - 256 bytesc       320 bytes       257 - 320 bytesd       384 bytes       321 - 384 bytese       448 bytes       385 - 448 bytesf       512 bytes       449 - 512 bytes

最大支持分配512字节空间，每种块最大支持8组，超过这两种限制的任一种情况时，仍会在系统Heap上进行分配。这一点比较可惜，毕竟不同的任务分配需求都有所不同，也许是VxWorks为了方便管理，这一Cache空间的大小，在创建任务时就会分配完成，但是有总比没有强，经过测试，在vector容量小于8时，1000条任务，确实不会再出现争夺互斥信号资源的现象，如果程序中经常使用std::string，或者申请一些堆上的短小资源且数量不多时（即使分组超过，有一部分也会存在在Cache中），可以考虑开启这个功能。会对程序运行效率有提升效果。