slab分配器补充

最新推荐文章于 2025-12-15 21:26:32 发布
原创 最新推荐文章于 2025-12-15 21:26:32 发布 · 987 阅读 · 15 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#linux kernel #内存管理 #slab

/proc/slabinfo

# name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>

字段解释

第一部分：对象统计

  • name
    slab 缓存的名字（例如 dentry, inode_cache, kmalloc-64 等）。
  • active_objs
    当前正在使用（已分配）的对象数量。
  • num_objs
    当前 cache 中的对象总数（包括已分配和未分配的）。
  • objsize
    每个对象的大小（字节数）。
  • objperslab
    每个 slab 中能容纳的对象数量。
    （slab = 若干页的内存块，里面被切分成 objperslab 个对象）。
  • pagesperslab
    每个 slab 占用的物理页数。

第二部分：tunables（可调参数）

这些字段和 array_cache（CPU 本地缓存）有关，早期 slab 分配器里比较重要。

  • limit
    每个 CPU 的 array_cache 能缓存的对象最大数量。
    超过这个值，多余对象会被批量释放回 node 层。
  • batchcount
    CPU 缓存和 node/slab 之间批量迁移对象的数量。
    • 当 CPU 本地缓存耗尽，就会从 slab 批量拿 batchcount 个对象。
    • 当缓存太满时，就会批量释放 batchcount 个对象回 slab。
  • sharedfactor
    用于计算 node 级共享缓存（shared）大小的因子。
    • 多个 CPU 共享一个 node 的 shared，避免频繁访问 slab 链表。
    • 值越大，shared 里的对象越多。

第三部分：slabdata（slab 统计信息）

  • active_slabs
    正在使用的 slab 数量（里面至少有一个对象被分配）。
  • num_slabs
    总 slab 数量（包括 full、partial、free 三种）。
  • sharedavail
    NUMA 节点共享缓存（shared）中可用的对象数量。

kmem_cache中cpu_cache和node成员的关系

// include/linux/slab_def.h
struct kmem_cache {
    struct array_cache __percpu *cpu_cache;
    ...
        struct kmem_cache_node *node[MAX_NUMNODES];
};

// mm/slab.h
struct kmem_cache_node {
    struct list_head slabs_partial;	/* partial list first, better asm code */
    struct list_head slabs_full;
    struct list_head slabs_free;
    ...
        struct array_cache *shared;	/* shared per node */
    struct alien_cache **alien;	/* on other nodes */
    ...
};

struct kmem_cache中的cpu_cache和node，struct kmem_cache_node中的slabs_partial，slabs_full，slabs_free，shared，alien，这些成员之间的关系：

1. struct kmem_cache（描述某种对象的缓存池）

cpu_cache

  • 类型：struct array_cache __percpu *，是 每 CPU 缓存。
  • 作用：加速对象的分配和释放，避免频繁访问全局的 slab 链表。
  • 原理：
    • 每个 CPU 有一个私有的 array_cache，里面保存若干“热对象”（free 对象的指针数组）。
    • 分配时，CPU 优先从自己的缓存里拿；释放时，也尽量先放到自己缓存里。
    • 如果 cpu_cache 空了，就从 node 的 slab 获取一批对象补充。
    • 如果 cpu_cache 太满，就把一批对象回收到 node。

换句话说：cpu_cache 是 CPU 本地的快速对象池。

node[MAX_NUMNODES]

  • 类型：struct kmem_cache_node *
  • 作用：在 NUMA 系统中，不同内存节点（node）都有自己的对象管理器。
  • 每个 node 负责本节点分配的 slab。
  • 这样避免跨 NUMA 节点分配/释放对象，提高内存局部性。

2. struct kmem_cache_node（管理一个 NUMA 节点上的 slab）

slabs_partial

  • 链表，保存 部分分配（partial） 的 slab：既有已分配对象，也有空闲对象。
  • 分配时，通常会优先从 partial slab 里拿空闲对象。

slabs_full

  • 链表，保存 已满（full） 的 slab：里面没有空闲对象。
  • 基本不参与分配，除非有对象被释放回来，slab 可能从 full 转到 partial。

slabs_free

  • 链表，保存 空 slab（全空，没有对象被使用）。
  • 释放时，如果某个 slab 所有对象都被释放了，它会被移到 free 列表。
  • 需要回收内存时，可以把 free 列表里的 slab 释放回伙伴系统。

所以：

  • 分配顺序：partial → free → 新建 slab。
  • 释放时：对象释放回 slab → slab 状态可能在 full/partial/free 之间切换。

shared

  • 类型：struct array_cache *
  • 含义：在 NUMA node 级别的 共享缓存（介于 cpu_cache 和 slab 链表之间的缓冲层）。
  • 作用：
    • 如果某个 CPU 的 cpu_cache 用完/太满，就可以和 shared 做批量交换。
    • 减少了频繁访问 slab 链表的开销。

可以理解为：node 级别的中转站。

alien

  • 类型：struct alien_cache **
  • 作用：当某个 CPU 释放了 不属于自己 NUMA 节点 的对象时，不能直接放到远端 node 的 shared，否则会有锁竞争和跨 NUMA 问题。
  • 解决方案：
    • 先放到本 CPU 上的 alien_cache，批量转移到目标节点。
    • 这样避免频繁跨节点操作。

可以理解为：跨 NUMA 的释放缓冲区。

3. 这些成员之间的关系（层级）

如果按层次画出来，大概是这样：

kmem_cache（对象类型缓存池）
│
├─ cpu_cache (每CPU缓存，加速本地分配/释放)
│     ↓ 批量获取/释放
│
├─ node[MAX_NUMNODES]（NUMA节点缓存）
│    │
│    ├─ slabs_partial（部分分配的slab）
│    ├─ slabs_full   （已满的slab）
│    ├─ slabs_free   （全空的slab）
│    │
│    ├─ shared  （NUMA节点共享缓存，用于CPU间交换）
│    └─ alien   （跨NUMA释放的缓冲区）

分配流程（简化版）：

  1. CPU 先从 cpu_cache 取对象；
  2. cpu_cache 不够时，从 node.shared 或 slabs_partial/free 批量取；
  3. 如果 node 也没有合适 slab，就向伙伴系统申请新页，建 slab。

释放流程（简化版）：

  1. 对象优先回到 cpu_cache；
  2. 如果 cpu_cache 太满，多余对象批量回到 node.shared；
  3. 如果 slab 对象全释放，slab 放到 slabs_free；
  4. 跨 NUMA 的释放，先放到 alien，再批量转移。

总结一下：

  • cpu_cache 是 CPU 层的快速对象池；
  • node 是 NUMA 节点的 slab 管理者；
  • slabs_partial/full/free 管理 slab 状态；
  • shared 是 node 内 CPU 之间的中转缓存；
  • alien 解决跨 NUMA 节点释放的性能问题。

测试代码

实现一个内核模块：

1）创建名称为slab_test_cache的kmem_cache大小为40字节，align为8字节。

2）设置构造函数，在构造函数中将对象初始化为0xAA。

代码如下：

#include <linux/module.h>
#include <linux/slab.h>
#include <linux/init.h>
#include <linux/delay.h>

static struct kmem_cache *mycache = NULL;
static void *obj = NULL;
static size_t obj_size = 40; // 对象大小

/* 构造函数：在对象分配时自动调用 */
static void my_ctor(void *ptr)
{
    pr_info("mycaches: ctor called for object %p\n", ptr);
    memset(ptr, 0xAA, obj_size);  /* 初始化为 0xAA */
}

static int __init mymodule_init(void)
{
    pr_info("mycaches: module init\n");
    size_t align = 8; // 对齐要求
    const char *name = "slab_test_cache";


    /* 创建 slab cache */
    mycache = kmem_cache_create(name, obj_size, align, SLAB_HWCACHE_ALIGN, &my_ctor);
    if (!mycache) {
        pr_err("mycaches: failed to create slab cache\n");
        return -ENOMEM;
    }

    pr_info("mycaches: slab cache[%s] created, obj_size = %zu, align = %zu\n", name, obj_size, align);

    /* 从 cache 中分配一个对象 */
    obj = kmem_cache_alloc(mycache, GFP_KERNEL);
    if (!obj) {
        pr_err("mycaches: failed to allocate object\n");
        kmem_cache_destroy(mycache);
        return -ENOMEM;
    }

    pr_info("mycaches: allocated object at %p, first 8 bytes = %*ph\n",
            obj, 8, (u8 *)obj);

    return 0;
}

static void __exit mymodule_exit(void)
{
    pr_info("mycaches: module exit\n");

    /* 释放对象 */
    if (obj) {
        kmem_cache_free(mycache, obj);
        pr_info("mycaches: object freed\n");
    }

    /* 销毁 slab cache */
    if (mycache) {
        kmem_cache_destroy(mycache);
        pr_info("mycaches: cache destroyed\n");
    }
}

module_init(mymodule_init);
module_exit(mymodule_exit);


MODULE_LICENSE("GPL");
MODULE_AUTHOR("congchp");
MODULE_DESCRIPTION("Example module for slab cache usage");

测试结果如下：

[25583.310309] mycaches: module init
[25583.310328] mycaches: slab cache[slab_test_cache] created, obj_size = 40, align = 8
[25583.310331] mycaches: ctor called for object 000000005332292f
[25583.310332] mycaches: ctor called for object 0000000009013862
[25583.310333] mycaches: ctor called for object 00000000a6e088c6
[25583.310334] mycaches: ctor called for object 000000003d904c26
[25583.310334] mycaches: ctor called for object 000000007c9fac9b
[25583.310335] mycaches: ctor called for object 000000000098edc2
[25583.310336] mycaches: ctor called for object 00000000ff3fa139
[25583.310336] mycaches: ctor called for object 000000001ce80991
[25583.310337] mycaches: ctor called for object 0000000090d5068a
[25583.310337] mycaches: ctor called for object 0000000057b47b33
[25583.310338] mycaches: ctor called for object 00000000e606fd32
[25583.310338] mycaches: ctor called for object 00000000d113c42c
[25583.310339] mycaches: ctor called for object 000000001f7f816c
[25583.310339] mycaches: ctor called for object 000000008e5b5f55
[25583.310340] mycaches: ctor called for object 0000000074e7df7a
[25583.310340] mycaches: ctor called for object 00000000d4dfa738
[25583.310341] mycaches: ctor called for object 000000001880f040
[25583.310341] mycaches: ctor called for object 0000000029e8e63a
[25583.310342] mycaches: ctor called for object 00000000f88c68dc
[25583.310342] mycaches: ctor called for object 000000001b9f86d1
[25583.310343] mycaches: ctor called for object 00000000dc179a8d
[25583.310343] mycaches: ctor called for object 00000000f93ccce4
[25583.310344] mycaches: ctor called for object 00000000d83ad1da
[25583.310344] mycaches: ctor called for object 000000002b819647
[25583.310345] mycaches: ctor called for object 00000000e4763ffc
[25583.310346] mycaches: ctor called for object 000000001078b356
[25583.310346] mycaches: ctor called for object 00000000dfc333a7
[25583.310347] mycaches: ctor called for object 0000000005ef5f3e
[25583.310347] mycaches: ctor called for object 0000000051a1d56f
[25583.310348] mycaches: ctor called for object 0000000045d96db7
[25583.310348] mycaches: ctor called for object 00000000ba6c2cb0
[25583.310349] mycaches: ctor called for object 00000000b70bef14
[25583.310349] mycaches: ctor called for object 00000000b82e2428
[25583.310350] mycaches: ctor called for object 000000008f41f66b
[25583.310350] mycaches: ctor called for object 00000000b11a4b53
[25583.310351] mycaches: ctor called for object 000000002de03941
[25583.310351] mycaches: ctor called for object 00000000d521c8ce
[25583.310352] mycaches: ctor called for object 000000006842339c
[25583.310353] mycaches: ctor called for object 0000000003bf6fde
[25583.310353] mycaches: ctor called for object 00000000c00f1ad0
[25583.310354] mycaches: ctor called for object 0000000079441e29
[25583.310354] mycaches: ctor called for object 00000000396645ae
[25583.310355] mycaches: ctor called for object 000000007aee9b35
[25583.310355] mycaches: ctor called for object 000000009049f398
[25583.310356] mycaches: ctor called for object 0000000008a5af82
[25583.310356] mycaches: ctor called for object 00000000a2788b07
[25583.310357] mycaches: ctor called for object 00000000318a2f52
[25583.310357] mycaches: ctor called for object 00000000af6b3bcd
[25583.310358] mycaches: ctor called for object 00000000f724e4d2
[25583.310359] mycaches: ctor called for object 0000000097fc2cdf
[25583.310359] mycaches: ctor called for object 000000004440532d
[25583.310360] mycaches: ctor called for object 0000000037932300
[25583.310360] mycaches: ctor called for object 00000000c9c40901
[25583.310361] mycaches: ctor called for object 000000005c3fe42f
[25583.310361] mycaches: ctor called for object 0000000097b2b54f
[25583.310362] mycaches: ctor called for object 000000009d575be3
[25583.310362] mycaches: ctor called for object 000000007763afbb
[25583.310363] mycaches: ctor called for object 0000000002105838
[25583.310363] mycaches: ctor called for object 0000000091a0da01
[25583.310364] mycaches: ctor called for object 000000003c43bcfb
[25583.310364] mycaches: ctor called for object 00000000b3c694a4
[25583.310365] mycaches: ctor called for object 0000000017ede172
[25583.310365] mycaches: ctor called for object 0000000048c6629c
[25583.310366] mycaches: ctor called for object 00000000bb0e4141
[25583.310367] mycaches: allocated object at 000000005332292f, first 8 bytes = aa aa aa aa aa aa aa aa

只调用了一次kmem_cache_alloc，但为什么会执行64次my_ctor？

应该是在第一次调用就将整个slab（一页，4K bytes）中的所有object给初始化了。

可以通过/sys/kernel/slab/或者/proc/slabinfo查询到该kmem_cache的具体信息

伙伴分配器、slab分配器与用户空间malloc的不同

1. 用户空间的 malloc()

  • 用户空间调用 malloc() 时，glibc 只是向内核申请 虚拟地址空间，很多时候并不会立刻分配物理页。
  • 真正的物理内存在 缺页异常 (page fault) 时才按需分配（称为 demand paging）。

2. 内核空间的 alloc_pages()（伙伴分配器）

  • alloc_pages(order, gfp_mask) 直接向伙伴系统要物理页框。
  • 调用返回时，就已经拿到 真实的物理页，并且映射到内核的线性映射区。
  • 不会拖延到缺页异常时才分配。

3. 内核空间的 kmalloc()（slab/slub 分配器）

  • kmalloc(size, gfp_mask) 本质上最终也是基于伙伴系统分配物理页，然后在 slab 中 carve 成小对象。
  • 调用返回时，拿到的是 内核虚拟地址，它已经对应着 实际分配好的物理内存。
  • 也就是说，kmalloc 之后马上就能安全访问，不存在 “先占坑、等 page fault 再分配” 的机制。

4. 为什么内核不能用 demand paging？

  • 内核自己必须保证分配时拿到的是可立即使用的物理内存，否则驱动、DMA、页表等都会出问题。
  • 如果像用户空间一样延迟到缺页时才分配，那在处理缺页异常时又需要新的内存，就可能 递归陷入 或 死锁。

结论：

  • 用户空间 **malloc()** → 延迟分配物理内存（缺页异常时才分配）。
  • 内核空间 **alloc_pages()** / **kmalloc()** → 调用时立即分配物理内存，返回的虚拟地址已经有对应物理页。

参考资料

  1. Professional Linux Kernel Architecture，Wolfgang Mauerer
  2. Linux内核深度解析，余华兵
  3. Linux设备驱动开发详解，宋宝华
  4. linux kernel 4.12
Linux 内存管理 | 物理内存、内存碎片、伙伴系统、SLAB分配器
Jormungand_V的博客
08-04 1158
文章目录物理内存物理内存分配外部碎片内部碎片伙伴系统(buddy system)slab分配器 物理内存 在Linux中，内核将物理内存划分为三个区域。 在解释DMA内存区域之前解释一下什么是DMA： DMA（直接存储器访问） 使用物理地址访问内存，将数据从一个地址空间复制到另外一个地址空间，从而加快磁盘和内存之间数据的交换，不经过MMU（内存管理单元），这时CPU可以去干别的事，大大增加了效率。 DMA内存区域(ZONE_DMA)： 包含 0M~16M 之内的内存页框，该区域的物理页面专门供I/O设备
Slab分配器
qq_55655082的博客
02-07 831
slab 分配器是一种高效的小对象内存管理机制，而 slab 层则是基于 slab 分配器构建的抽象层，为内核提供了统一的小对象内存管理接口。它们共同协作，提高了内核内存分配和释放的效率，减少了内存碎片。Slab分配器通过预分配和缓存机制，显著提升了内核内存管理的效率。Slab中分配的最小内存单元，大小固定，由缓存类型决定。查看所有Slab缓存的详细信息（对象数量、内存占用等）。创建，包含对象的元数据（大小、对齐、构造函数等）。，划分为多个相同大小的对象（Object）。的对象（如进程描述符。
伙伴分配器补充
congchp的博客
09-01 903
可移动页 (MIGRATE_MOVABLE)用户进程的匿名页 (匿名内存)、文件缓存页（page cache）等。它们被 swap-out 或从文件重新读入后，可以放到别的物理页。所以这些页是“可移动的”。不可移动页 (MIGRATE_UNMOVABLE)内核数据结构、页表、一些 slab 分配的对象。这些数据与内核内部指针直接绑定，没法整体迁移到其他物理页。可回收页 (MIGRATE_RECLAIMABLE)比如 slab 中的 dentry cache、inode cache。
slab分配器
qq_52911516的博客
09-12 1141
介绍slab分配器的一些概念与关联
内存管理之slab分配器
hhhanpan的博客
06-20 937
STL中的空间配置器采用一、二级配置器进行内存管理，当配置区块    在一级配置器中，allocate()直接使用malloc()，deallocate()直接使用free()，对于内存不足的情况，模拟C++的set_new_handler()机制；      在二级配置器中，首先会维护16个自由链表（free lists），负责16种小型区块的次配置能力；如果内存不足，转调一级配置器中的set_...
【Linux内核学习笔记五】内存管理-slab分配器
wyy4045的专栏
10-07 668
    slab分配器的基本思想是：将内核中经常使用的对象放到高速缓存中，并且由系统保持为初始的可利用状态。如果没有基于对象的分配器，内核将花费更多的时间分配，初始化以及释放一个对象。slab分配器的目的是缓存这些空闲的对象，保留基本结构，从而能够重复使用它们。      slab分配器由多个高速缓存组成，它们通过双向循环链表链接在一起，称为高速缓存链表。每个高速缓存包含若干slab，slab由...
Linux内存细节 kmem_cache_init初始化slab分配器
生活需要深度
04-09 890
看了下kmem_cache_init，涉及到不同MIGRATE间的buddy system的迁移，kmem_cache的构建，slab分配器头的构建、buddy system的伙伴拆分。 对于SMP系统，每个kmem_cache还有各个CPU的arraycache_init，这样每个CPU可以从各自的arraycache_init中获取缓存，如果不足，则从slab分配器中获得；当让slab分配器的三条链表也有一定的缓存作用，如果三条链表都已空了，则需要从buddy system中申请页。在申请页的时候，由
【Linux】【内存管理】伙伴系统和slab分配器
张壮壮的博客
05-26 1060
Linux内核采用伙伴系统与slab分配器两级机制管理物理内存。伙伴系统以页为单位管理大块连续内存，通过分割合并策略减少外部碎片，适合分配大块内存。slab分配器在此基础上细分小对象，通过预分配、对象复用和缓存优化提升小内存分配效率。两者协同工作，伙伴系统提供底层页框支持，slab构建对象缓存层，共同实现高效内存管理。伙伴系统优势在于大块连续内存管理，而slab擅长高频小对象分配，但都存在一定内存开销和复杂度问题。这种层级设计平衡了内存利用率与分配性能的需求。
SLAB分配器小结
protoss_penguin的博客
05-28 767
在遇到类似于越界溢出、迷途指针这些漏洞时，一般会对内存进行覆盖（比如喷堆），无论哪种重写方式，无疑都需要了解内存分配器的工作方式。在进行了阅读，源码的分析，包括很多博文的帮助下大概摸清了SLAB分配器的脉络。 SLAB分配器主要的作用是针对常用的对象，以链表的方式缓存它们，缓存的链表会连续的存放，这样频繁地分配和回收就不会导致内存碎片，此外对于很多初始化的对象（如互斥锁）内存回收后仍保持初始化的
不连续页分配器补充
congchp的博客
09-08 1108
用户态用malloc()（底层 brk/mmap），本质是修改虚拟内存布局，缺页时通过 **伙伴系统 **分配物理页；内核态直接用kmalloc()（小块）、vmalloc()（大块，物理不连续）。内核线程没有独立的页表，它们不会切换到某个“内核专用页表”。调度到内核线程时，Linux 内核会让它们 借用上一个进程的页表（通过active_mm），只使用其中的内核地址映射部分。由于所有进程的内核区页表一致，内核线程就能安全运行。
Slab分配器原理与源码深度解析
为此，slab分配器应运而生，作为对伙伴系统的补充，专门用于优化小对象的内存分配效率。slab的基本思想是：预先从伙伴系统中申请若干连续物理页面，并在其基础上构建多个固定大小的对象缓存区（称为kmem_cache），每...
Uslab:实现无锁短期分配与持久存储的slab分配器
Uslab是一个独立的无锁slab分配器库，主要用于短期分配和持久性存储。Slab分配是一种内存分配机制，适用于固定大小对象的快速分配和回收，常见于Linux内核内存管理。Uslab旨在作为一个有界缓冲区，高效管理固定大小...
嵌入式面试问题：STM32中指针和数组的本质区别是什么，常用数组存储什么数据？
d111111111d的博客
12-15 501
摘要： STM32中指针与数组的核心区别在于：数组静态分配固定内存（如uint8_t array[100]），直接存储数据；指针动态分配（如malloc）或指向现有内存，仅存储地址。关键差异包括sizeof行为（数组返回总大小，指针返回地址大小）、地址操作及内存布局（数组连续存储，指针间接引用）。STM32常用数组存储外设缓冲区（UART/ADC）、信号处理数据（FFT）、系统配置（PWM表）等，优先静态分配以提升实时性。特殊场景需考虑内存分段（如CCMRAM）、对齐要求（DMA）及缓存优化。最佳实践推荐静
深入理解 C/C++ 内存管理：从内存布局到动态分配
qq_67169366的博客
12-10 912
我们可以重载这两个函数来实现自定义内存管理策略，例如内存池。new调用分配内存；调用构造函数初始化对象。delete调用析构函数清理资源；调用释放内存。特性new/delete语言C 函数C++ 操作符初始化不初始化可初始化大小计算手动计算自动计算（类型）返回值void*（需强转）类型指针（无需强转）失败处理返回 NULL抛出异常对象生命周期管理不调用构造/析构函数调用构造/析构函数理解 C/C++ 内存管理是写出高效、稳定程序的基础。从内存布局到动态分配，从到。
【Linux】浅析Linux内存管理机制
xuhuang11的博客
12-11 1031
本文主要讲解Linux内存管理机制中的一个核心子模块：内核内存分配与回收机制。通过了解这个机制，对内核内存分配失败时，应该怎么看日志、分析原因有一定帮助。
操作系统 李治军 3 内存管理
qq_44845100的博客
12-10 189
C++代码优化与内存管理实战
2301_81451531的博客
12-14 399
本文展示了一个C++程序示例，包含类实现和链表操作。类A封装了两个整型成员变量，提供带默认参数的构造函数和打印功能。定义了一个链表节点结构体ListNode，包含数据域和指针域，实现构造/析构函数。程序演示了动态内存分配（数组和单个变量）及正确释放方法。创建并连接了5个链表节点，遍历输出后释放内存。完整展现了面向对象编程和链表操作的基本实现方式。
【C语言学习】动态内存管理
embrace99的博客
12-09 811
动态内存管理摘要 C语言中动态内存管理允许程序在运行时灵活分配和释放内存，通过malloc、calloc、realloc和free函数实现。与静态内存分配相比，动态内存管理具有更高灵活性，内存位于堆区，需手动释放；而静态内存由编译器自动分配，位于栈区或静态区，大小固定。 malloc分配连续内存空间，返回void*指针；calloc会初始化内存为0；realloc可调整已分配内存大小；free用于释放内存。使用时必须检查返回值，释放后应将指针置NULL避免野指针问题。动态内存管理能更好适应不确定的内存需求，
C语言入门（二十七）：动态内存管理（1）
最新发布
世界万物，永恒不变，人心炽热，璀璨光芒
12-15 751
当是情况2的时候，原有空间之后没有⾜够多的空间时，扩展的⽅法是：在堆空间上另找⼀个合适⼤⼩ 的连续空间来使⽤。有时候我们需要的空间⼤⼩在程序运⾏的时候才能知 道，那数组的编译时开辟空间的⽅式就不能满⾜了。所以如果我们对申请的内存空间的内容要求初始化，那么可以很⽅便的使⽤calloc函数来完成任务。当是情况1的时候，要扩展内存就直接原有内存之后直接追加空间，原来空间的数据不发⽣变化。：赋值的内容，第一次循环是 1，第二次是 2，……以上是部分的讲解内容，剩下的就放在下一章里面去!
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值