STL(Standard Template Library,标准模板库),从根本上说,STL是一些“容器”的集合,这些“容器”有list,vector,set,map等,STL也是算法和其他一些组件的集合。
谈及组件,那么我们就首先来简单谈下STL六大组件,其相关的设计模式使用,以及各组件之间的协作关系。
六大组件简单介绍
- 空间配置器:内存池实现小块内存分配,对应到设计模式–单例模式(工具类,提供服务,一个程序只需要一个空间配置器即可),享元模式(小块内存统一由内存池进行管理)
2.迭代器:迭代器模式,模板方法
3.容器:STL的核心之一,其他组件围绕容器进行工作:迭代器提供访问方式,空间配置器提供容器内存分配,算法对容器中数据进行处理,仿函数伪算法提供具体的策略,类型萃取 实现对自定义类型内部类型提取。保证算法覆盖性。其中涉及到的设计模式:组合模式(树形结构),门面模式(外部接口提供),适配器模式(stack,queue通过deque适配得 到),建造者模式(不同类型树的建立过程)。
4.类型萃取:基于范型编程的内部类型解析,通过typename获取。可以获取迭代器内部类型value_type,Poter,Reference等。
5.仿函数:一种类似于函数指针的可回调机制,用于算法中的决策处理。涉及:策略模式,模板方法。
6适配器:STL中的stack,queue通过双端队列deque适配实现,map,set通过RB-Tree适配实现。涉及适配器模式。
关于六大组件之间的具体关系如图简单描述
STL空间配置器产生的缘由:
在软件开发,程序设计中,我们不免因为程序需求,使用很多的小块内存(基本类型以及小内存的自定义类型)。在程序中动态申请,释放。
这个过程不好控制,于是出现以下两个问题:
问题1:就出现了内存碎片问题。
问题2:一直在因为小块内存而进行内存申请,调用malloc,系统调用产生性能问题。
注:
内碎片:因为内存对齐/访问效率(CPU取址次数)而产生 如 用户需要3字节,实际得到4或者8字节的问题,其中的碎片是浪费掉的。
实现策略
用户申请空间大于128?
yes:调用一级空间配置器
no:调用二级空间配置器
大致实现为:
二级空间配置由内存池以及伙伴系统:自由链表组成
一级空间配置器直接封装malloc,free进行处理,增加了C++中的set_handler机制(这里其实也就是个略显牵强的装饰/适配模式了),增加内存分配时客户端可选处理机制。
可配置性:
客户端可以通过宏__USE_MALLOC进行自定义选择是否使用二级空间配置器。
一级空间配置器就主要封装malloc,添加handler机制了,这里就不罗嗦了,相信各位都是可以通过源码了解到的
关于二级空间配置器:
使用Trace进行跟踪,打印数据流向,逻辑走向,文件,函数,方法,行位置。那么我们就能根据这个记录进行程序的排错以及调优了。
具体Trace简单如下
#pragma once
#define ___TRACE(...) fprintf(fout, "file[%s]line[%u]func[%s]::",__FILE__,__LINE__,__func__);\
fprintf(fout,__VA_ARGS__)
利用宏打印文件,行,函数位置,然后利用可变参数列表方式接收代码中具体位置的记录跟踪。
如下是代码摘取的Alloc中的跟中。
static void *Allocate(size_t n)
{
___TRACE("__MallocAllocTemplate to get n = %u\n",n);
void *result = malloc(n);
if (0 == result)
{
result = OomMalloc(n);
}
return result;
}
源码在网上可以搜到
这里有一前辈git可以看
https://github.com/langya0/llhProjectFile/tree/master/STL
文件:Alloc.h
间配置器的遗留问题
1.仔细探究源码之后,你一定会发现一个问题,
貌似二级空间配置器中的空间重头到尾都没看到他归还给系统。那么问题就是,内存池空间何时释放?
对于这个问题,在回头浏览一下源码及结构图,你就会发现
大于128的内存,客户程序Deallocate之后会调free释放掉,归还给了系统。
但是呢……………
内存池中获取的空间,最终,假定用户都调用Dealloc释放调了,那么他们又在哪里呢?
没有还给系统,没有在内存池,在自由链表中。
Got it:程序中不曾释放,只是在自由链表中,且配置器的所有方法,成员都是静态的,那么他们就是存放在静态区。释放时机就是程序结束。