QVector的内存分配策略

我们都知道 STL std::vector 作为动态数组在所分配的内存被填满时。假设继续加入数据,std::vector 会另外申请一个大小当前容量两倍的区域(假设 n > size 则申请 n+当前容量 的空间)。然后把当前内容复制到新的内存,以达到动态扩容的效果:

   size_type
      _M_check_len(size_type __n, const char* __s) const
      {
        if (max_size() - size() < __n)
          __throw_length_error(__N(__s));

        const size_type __len = size() + std::max(size(), __n);
        return (__len < size() || __len > max_size()) ?

max_size() : __len;
      }

最直观的方式是写个客户程序看看:

vector<int> ve(4, 8);
    cout << "size : " << ve.size() << " capacity : " << ve.capacity() << endl;

    for ( int i = 0; i < 14; ++i )
    {
        ve.push_back(9);
        ve.push_back(0);
        cout << "size : " << ve.size() << " capacity : " << ve.capacity() << endl;
    }

输出例如以下。capacity 每次扩张为之前容量的两倍:

相似的,Qt在其 QTL 中也实现了相似的QVector,为了更方便地服务为 Qt 应用服务。它提供了隐式共享。写时复制等机制。并同一时候提供了 Java Style 和 C++ Style 的接口,相同功能的接口也就是换了个名字而已:

inline void push_back(const T &t) { append(t); }

那么,在 QVector 所分配的内存被填满时。它的内存又是以何种方式扩充的呢?我们能够在源代码中一探到底:

先看看 QVector::append():

const bool isTooSmall = uint(d->size + 1) > d->alloc;
    if (!isDetached() || isTooSmall) {
        QArrayData::AllocationOptions opt(isTooSmall ?

QArrayData::Grow : QArrayData::Default);
        reallocData(d->size, isTooSmall ? d->size + 1 : d->alloc, opt);
    }

isDetached()调用一个引用计数,用来推断该QVector是否独立(未被隐式共享)。假设该 QVector 是被共享的。那么我们此时想要在这个已被我们“复制”的 QVector 上调用 append() 时,当然须要真正分配一段新的内存并在该内存上进行加入元素的操作。也就是所谓的“写时复制”。

isTooSmall 则告诉我们当前szie加 1 之后是否超出了当前容量(d->alloc),假设是相同须要调用 reallocData 開始申请内存。

因为内存分配可能是由写时复制策略调用,因此依据 isTooSmall 參数的不同。reallocData()的參数也不同。

QVector::reallocData()函数调用了QTypedArrayData::allocate(),前者运行了begin(),end()等指针的又一次指向,原内存释放等工作。后者实际调用了 QArrayData::allocate(),其函数原型为:

static QTypedArrayData *allocate(size_t capacity,
            AllocationOptions options = Default) Q_REQUIRED_RESULT
    {
        Q_STATIC_ASSERT(sizeof(QTypedArrayData) == sizeof(QArrayData));
        return static_cast<QTypedArrayData *>(QArrayData::allocate(sizeof(T),
                    Q_ALIGNOF(AlignmentDummy), capacity, options));
    }

这里的 Q_ALIGNOF(AlignmentDummy) 十分关键。AlignmentDummy是以下这种一个class:

class AlignmentDummy { QArrayData header; T data; };

QArrayData 是 Qt 全部连续型容器实际存放数据的地方。包括以下几个数据成员,也就是说。在32位机器上(以下以此为默认环境),sizeof(QArrayData) 通常是16个字节长度:

QtPrivate::RefCount ref;
    int size;
    uint alloc : 31;
    uint capacityReserved : 1;

    qptrdiff offset; // in bytes from beginning of header

而 Q_ALIGNOF 在 gcc 下是 __alignof__ 的别名。而在MSVC下则为 __alignof。用来获得 AlignmentDummy 的内存对齐大小。由上面的数据成员能够知道 Q_ALIGNOF(QArrayData) 的值为4。当 Q_ALIGNOF(AlignmentDummy) 大于4 时。意味着该 QArrayData 的成员变量所占内存空间与实际 T 型数据间因为内存对齐将会存在间隙(padding),因此我们须要额外多申请 padding 的空间才干保证全部数据都能够被正确安放。

理解这一点后,我们就能够来看看QArrayData::allocate()

QArrayData *QArrayData::allocate(size_t objectSize, size_t alignment,
        size_t capacity, AllocationOptions options)
{
    // 检測aligment是否为2的阶数倍
    Q_ASSERT(alignment >= Q_ALIGNOF(QArrayData)
            && !(alignment & (alignment - 1)));

    ...

    // 获取 QArrayData 类为空时的大小
    size_t headerSize = sizeof(QArrayData);

    // 申请额外的 alignment-Q_ALIGNOF(QArrayData)大小的 padding 字节数
    // 这样就能将数据放在合适的位置上
    if (!(options & RawData))
        headerSize += (alignment - Q_ALIGNOF(QArrayData));

    // 假设数组长度超出容量则申请新的内存
    if (options & Grow)
        capacity = qAllocMore(int(objectSize * capacity), int(headerSize)) / int(objectSize);

    //一共须要申请的字节数
    size_t allocSize = headerSize + objectSize * capacity;

    QArrayData *header = static_cast<QArrayData *>(::malloc(allocSize));
    if (header) {
        ...
    }

    return header;
}

qAllocMore() 实如今 qbyteArray.cpp 文件里,这个函数返回一个整型数,返回数据内容所需的字节数:

int qAllocMore(int alloc, int extra)
{
    Q_ASSERT(alloc >= 0 && extra >= 0);
    Q_ASSERT_X(alloc < (1 << 30) - extra, "qAllocMore", "Requested size is too large!");

    unsigned nalloc = alloc + extra;

    // Round up to next power of 2

    // Assuming container is growing, always overshoot
    //--nalloc;

    nalloc |= nalloc >> 1;
    nalloc |= nalloc >> 2;
    nalloc |= nalloc >> 4;
    nalloc |= nalloc >> 8;
    nalloc |= nalloc >> 16;
    ++nalloc;

    Q_ASSERT(nalloc > unsigned(alloc + extra));

    return nalloc - extra;
}

函数开头告诉我们假设申请字节不能超过 2^30 - extra。注意这里的 extra 就是我们在上面求到的 sizeof(QArrayData) + sizeof(padding)。

alloc是我们存放实际数据区域的大小,nalloc即为我们总共须要的新内存容量。

以下的几排移位算法假设大家眼熟的话应该知道得到的 nalloc 的新值为比其原值大的一个近期的 2 的阶乘数。比方输入20。经过最后一步 ++nalloc 操作后,nalloc将变成 32。

拨开云雾见青天的时候最终要到了,回到我们最初的问题:QVector 在满容量之后继续插入,其内存增长策略怎样?

依照我们前面所示。大家心里或许有了答案:QVector的所申请内存大小依照 2^n 增长,也就是 2, 4, 8, 16, 32...OK,写測试代码的时候到了:

    QVector<int> ve(2, 8);
    qDebug() << "size : " << ve.size() << " capacity : " << ve.capacity();

    for ( int i = 0; i < 20; ++i )
    {
        ve.append(9);
        qDebug() << "size : " << ve.size() << " capacity : " << ve.capacity();
    }

输入例如以下:

似乎有些奇怪。容量(占用内存为 capacity * sizeof(int))并非 2 的 n 次方?还记得QArrayData类中的数据成员所占用的 sizeof(QArrayData) = 16 吗,正是这 16 个字节占用了我们这个QVector<int>的 4 个容量。也就是说。这个QVector<int>实际的容量应该为:

如今我们再考虑带有 padding 的情况,当我们创建一个 QVector<quint64> 时,因为内存对齐的关系,QArrayData的数据成员与实际存储数据之间应该存在间隙,导致不可用的空间超过 16 字节:

能够看到,实际空间占用比容量大了 3*8 = 24bytes,当中 16bytes 为 headerSize,余下 8bytes 则为间隙了。

这样应该非常清晰了吧(●‘?‘●)

那么,这个分配策略和 STL std::vector 的差异主要在哪呢,不也是每次翻倍吗?

使用int作为数组数据类型,直接给个输出结果哈:

相同向 100 个容量的满数组中加入一个数据,QVector扩容将申请 128*4 (124*4 数据容量 + 4*4个字节的headerSize) 个字节,而 std::vector 将申请 200*4 个字节。

能够预见,下次增长QVector将申请256*4个字节。而std::vector将申请400*4个字节。至于优劣。大家仁者见仁。智者见智咯。

就先到这里吧~

时间: 2024-12-21 21:55:12

QVector的内存分配策略的相关文章

垃圾收集器与内存分配策略

①对于java虚拟机来说,垃圾收集器主要关注的内存区域是 堆和方法区. ②垃圾收集器就是要收集那些已经“死了”的对象.如果判断一个对象是否存活? 对象引用计数法 对象引用增加一个,那么相应的计数器加1,否则,减1. 优点:实现简单 缺点:不能处理对象间的循环引用.a引用b,b同时引用a. 可达性分析 如果节点到root节点可达,则证明是存活的:否则,已死.所以对于下图的o5,o6,o7虽然他们是循环引用的,但是到root节点无可达,所以已死可清除. ③垃圾回收器对于不同类型引用的回收规则 强引用

【转载】Ogre的内存分配策略

原文:Ogre的内存分配策略 读这个之前,强烈建议看一下Alexandrescu的modern c++的第一章关于policy技术的解释.应该是这哥们发明的,这里只是使用. 首先列出涉及到的头文件:(这几个头文件彼此之间相关性挺大的,应该一起看) 只在调试期使用: OgreMemoryTracker.h 这个头文件中定义了MemoryTracker这个类,用来测试和调试Ogre的内存分配系统的.能跟踪内存的分配.回收.泄漏和统计信息.Ogre使用者不需要关注. OgreAlignedAlloca

JVM总结(二):JVM的内存分配策略

这节我们总结一下JVM中的内存分配策略.目录如下: 内存分配策略 对象优先在新生代Eden分配 大对象直接进入老年代 长期存活的对象将进入老年代 动态对象年龄判定 空间分配担保 内存分配策略 Java技术体系中所提倡的自动内存管理可以归结于两个部分:给对象分配内存以及回收分配给对象的内存. 我们都知道,Java对象分配,都是在Java堆上进行分配的,虽然存在JIT编译后被拆分为标量类型并简介地在栈上进行分配.如果采用分代算法,那么新生的对象是分配在新生代的Eden区上的.如果启动了本地线程分配缓

Memcache 内存分配策略和性能(使用)状态检查

前言: 一直在使用Memcache,但是对其内部的问题,如它内存是怎么样被使用的,使用一段时间后想看看一些状态怎么样?一直都不清楚,查了又忘记,现在整理出该篇文章,方便自己查阅.本文不涉及安装.操作.有兴趣的同学可以查看之前写的文章和Google. 1:参数 memcached -h memcached 1.4.14 -p <num> TCP端口,默认为11211,可以不设置 -U <num> UDP端口,默认为11211,0为关闭 -s <file> UNIX soc

垃圾收集器以及内存分配策略

垃圾回收 垃圾回收的三个问题: 哪些内存需要回收? 什么时候回收? 如何回收? 1.哪些对象需要回收? 判断对象是否存活的办法: 引用计数算法:给对象中添加一个引用计数器,有一个地方引用就+1,引用失效就-1.只要计数器为0则对象已死. 优点:简单易实现: 缺点:无法解决对象之间相互引用的问题.(JVM也因为此种原因没有使用它) 根搜索算法: 通过选取出一个GC Roots对象,已它作为起始点,如果对象不可达,则对象已死. GC Roots对象: 虚拟机栈中引用的对象 方法区中类静态属性引用的对

Java虚拟机垃圾收集器与内存分配策略

Java虚拟机垃圾收集器与内存分配策略 概述 那些内存需要回收,什么时候回收,如何回收是GC需要完成的3件事情. 程序计数器,虚拟机栈与本地方法栈这三个区域都是线程私有的,内存的分配与回收都具有确定性,内存随着方法结束或者线程结束就回收了. java堆与方法区在运行期才知道创建那些对象,这部分内存分配是动态的,本章笔记中分配与回收的内存指的就是:java堆与方法区. 判断对象已经死了 引用计数算法:给对象添加一个引用计数器,每当有一个地方引用它,计数器+1;引用失败,计数器-1.计数器为0则改判

AGG第七课 内存分配策略

说明 AGG采用new/delete函数操作堆内存,有时候并不是最佳的选择.另一方面,STL的内存分配策略太繁琐,因此没有采用.在agg_allocator.h文件中描述目前内存分配策略: template<class T> struct allocator { static T* allocate_array(unsigned size) { return new T [size]; } static void free_array(T* v, unsigned) { delete [] v

第三章 垃圾收集器与内存分配策略

书中笔记: 也许并不会死: 要宣告回收一个对象死亡,至少要经历两次标记过程: 当可达性分析发现一个对象不可达的时候,将标记第一次并进行筛选,筛选的条件是此对象是否有必要执行finalize()方法,当对象没有覆盖finalize或者已被调用过,则虚拟机认为此对象没必要执行finalize,  如果判断有必要执行,则此对象将会被放入一个F-Queue队列中,之后会被一个优先级比较低的Finalizer线程去调用,但是并不会等待他执行完毕,因为此对象的finalize并不可靠,可能会死循环之类的,如

第三章 垃圾收集器和内存分配策略

第三章 垃圾收集器和内存分配策略 对象已死吗 引用计算方法 可达性分析算法 通过一些列的GC roots 对象作为起始点,从这些节点开始向下搜索,搜索所走过的路径成为引用链,当一个对象到GC roots 没有任何引用链的则证明对象不可用的 虚拟机栈中的引用的对象 方法区中类静态属性引用的对象 方法去区中常量引用的对象 本地方法栈中JNI引用的对象 生存还是死亡 一次筛选,筛选是否有必要执行 finalize()方法 没有覆盖或者finalize()已经被调用过  视为没必要执行 放入一个F-Qu