Python 列表内存存储本质：存储差异原因与优化建议

Ne0inhk

— 12 min read
Python 列表内存存储本质：存储差异原因与优化建议

文章目录

在 Python 中处理大量字符串时，你可能会遇到意想不到的内存占用问题。比如需要存储一百万个短字符串或数字，按每个字符串平均 10 字节、每个 64 位整数 8 个字节计算，理论上只需约 8 到 10MB 内存，但实际用 Python 列表存储时，内存使用可能会到几十MB。这背后的原因是什么？又该如何优化？

1. 问题引入：列表存储的内存 “膨胀”

先看一段简单的代码，用普通列表存储一百万个短字符串、相同的短字符串、整数、相同的整数：

str_list =[f"item_{i}"for i inrange(1000000)] same_item_str_list =[f"item"for i inrange(1000000)] num_list =[i for i inrange(1000000)] same_item_num_list =[0for i inrange(1000000)]

直觉上，每个字符串 “item_xxx” 大约 8-10 字节，每个整数 8 个字节，一百万条数据应该在 8 到 10MB 左右。但实际内存使用如何呢，我们用pympler来精确测量。

先安装 pympler：

uv add pympler

修改代码，增加测量内存占用情况的打印：

from pympler import asizeof str_list =[f"item_{i}"for i inrange(1000000)] same_item_str_list =[f"item"for i inrange(1000000)] num_list =[i for i inrange(1000000)] same_item_num_list =[0for i inrange(1000000)]print(f"str_list列表内存: {asizeof.asizeof(str_list)/1024/1024:.2f} MB")print(f"same_item_str_list列表内存: {asizeof.asizeof(same_item_str_list)/1024/1024:.2f} MB")print(f"num_list列表内存: {asizeof.asizeof(num_list)/1024/1024:.2f} MB")print(f"same_item_num_list列表内存: {asizeof.asizeof(same_item_num_list)/1024/1024:.2f} MB")

再次运行，得到的内存报告大致如下（具体数值因环境略有差异）：

str_list列表内存: 61.46 MB same_item_str_list列表内存: 8.06 MB num_list列表内存: 38.57 MB same_item_num_list列表内存: 8.06 MB

可以看到，四个列表的内存占用差异巨大：存储不同字符串的str_list占用 61.46MB，存储不同整数的num_list占用 38.57MB，而存储相同字符串和相同数字的列表都只占用约 8MB 内存。为什么同样是存储一百万条数据，内存占用会相差这么大呢？为什么和我们的根据理论猜测的占用大小不一样呢？这需要先从数据的理论存储与实际存储差异说起。

2. 理论存储与实际存储的差异

我们常说 “每个 64 位整数占用 8 字节”“每个字符占用 1 字节”，这是硬件层面的理论存储需求，但在 Python 中，由于对象模型的设计，实际存储开销会远高于理论值。

2.1 64位整数的存储差异

  • 理论值（8 字节）：指在硬件和底层编程语言（如 C 语言）中，存储一个 64 位二进制数字所需的最小空间，仅包含数值本身，没有额外信息。
  • Python 实际值（28 字节以上）：Python 中的整数是对象，其结构PyIntObject（在 CPython 源码中实际名为PyLongObject，整数对象统一使用长整型结构）包含：
    • 引用计数（8 字节）：跟踪对象被引用的次数，用于垃圾回收
    • 类型指针（8 字节）：标识该对象是整数类型（指向PyLong_Type）
    • 长度字段（8 字节）：记录整数占用的位数组长度（对于小整数固定为 1）
    • 数值数据（4 字节起）：存储实际的整数数值（以位数组形式存储，小整数至少占用 4 字节对齐空间）
      这些结构字段总和为 8+8+8+4=28 字节，因此即使是最小的整数，在 Python 中也需要 28 字节内存，是理论值的 3.5 倍。

2.2 短字符串的存储差异

  • 理论值（字符数 ×1 字节）：在 ASCII 编码中，每个字符占用 1 字节，一个 8 字符的字符串理论上只需 8 字节。
  • Python 实际值（50 字节左右）：Python 的字符串对象PyUnicodeObject包含：
    • 引用计数（8 字节）和类型指针（8 字节）：基础对象元数据
    • 字符串长度（8 字节）：记录字符数量
    • 哈希值（8 字节）：用于快速比较和字典查找
    • 编码标志位（4 字节）：记录字符串使用的编码格式（如 ASCII、UTF-8 等）
    • 字符数据及内存对齐（8 字符 ×1 字节 + 4 字节对齐填充）：实际字符存储需要按 8 字节对齐，8 个字符本需 8 字节，但为满足内存对齐要求会填充 4 字节
    • 额外内存开销：Python 内存分配器会为小对象添加 4-8 字节的管理信息
      以 8 字符的 “item” 字符串为例，元数据（36 字节）+ 字符数据（8 字节）+ 对齐填充（4 字节）+ 分配器开销（2 字节）≈50 字节，因此实际内存是理论值的 6 倍多。
      这种理论与实际的差异，是导致列表内存 “膨胀” 的基础原因。当存储大量元素时，每个元素的额外开销会累积成巨大的内存差异。

3. 列表的内存存储本质

了解了整数和字符串的理论存储和实际存储差异，我们就可以开始学习列表的内存存储了。Python 列表本质上是指针数组，它存储的不是元素本身，而是元素对象在内存中的地址（指针）。在 64 位系统中，每个指针固定占用 8 字节，因此：

  • 无论列表中的元素是什么类型，一个包含 100 万个元素的列表，其指针数组本身的内存固定为 8MB（1000000×8 字节）。
  • 列表的总内存 = 指针数组内存 + 所有元素对象的内存总和。
    这就解释了为什么same_item_str_list和same_item_num_list的内存都在 8MB 左右 —— 它们的指针数组占用 8MB，所有指针指向相同的内存地址，因为元素对象只有一个，所以元素对象的内存几乎可以忽略不计。而str_list和num_list内存飙升的原因，正是元素对象的内存开销很大。

3.1 相同元素列表内存少的核心原因：对象复用

当列表中的元素完全相同时（如same_item_str_list全是 “item”，same_item_num_list全是 0），Python 会复用同一个对象，避免重复创建，从而大幅减少内存开销。

3.1.1 小整数的缓存复用机制

Python 对小整数（通常是 -5 到 256 之间） 采用预创建和缓存机制：这些整数在 Python 启动时就被提前创建，并存入全局缓存池，后续使用时直接复用，不会重复分配内存。

  • 在same_item_num_list = [0 for i in range(1000000)]中，所有元素都是 0，而 0 属于小整数，会被全局缓存复用。
  • 整个列表中，所有指针都指向同一个 0 对象，因此元素对象的内存只需存储1 个 0 的内存（约 28 字节）。
  • 总内存 = 指针数组（8MB）+1 个 0 对象内存（可忽略）≈8MB（与实测的 8.06MB 一致）。
    这种机制极大提高了小整数的使用效率，尤其在循环计数、状态标记等场景中，避免了频繁创建和销毁整数对象的开销。

3.1.2 字符串的驻留（Intern）机制

Python 会对短字符串、标识符类字符串进行 “驻留”（Intern）处理：相同的字符串会被存储在全局字符串池中，后续使用时直接复用，不会重复创建新对象。

  • 在same_item_str_list = [f"item" for i in range(1000000)]中，所有元素都是 “item”，这是一个短字符串且符合标识符规则（字母组成），会被自动驻留。
  • 整个列表中，所有指针都指向同一个 “item” 对象，元素对象的内存只需存储1 个 “item” 的内存（约 50 字节）。
  • 总内存 = 指针数组（8MB）+1 个 “item” 对象内存（可忽略）≈8MB（与实测的 8.06MB 一致）。
    字符串驻留机制主要用于优化程序中频繁出现的相同字符串，如变量名、关键字、常量字符串等，减少内存浪费和字符串比较的时间开销。

3.2 不同元素列表内存高的原因：对象重复创建

当列表中的元素不同时（如str_list和num_list），每个元素都是独立的新对象，需要为每个元素分配单独的内存，导致总内存剧增。

3.2.1 不同整数的内存开销

num_list = [i for i in range(1000000)]中，元素是 0 到 999999：

  • 其中 0 到 256 是小整数，会被缓存复用，但 257 到 999999 是大整数，每个大整数都是独立的新对象。
  • 每个 Python 整数对象（尤其是大整数）的内存开销约 28 字节（包含引用计数、类型指针等元数据）。
  • 总内存 = 指针数组（8MB）+ 约 999744 个大整数对象内存（999744×28 字节≈27MB）≈35MB（与实测的 38.57MB 接近，差异来自小整数缓存和内存对齐）。
    大整数没有缓存机制，每个大整数都需要单独分配内存，这就是num_list内存比相同元素数字列表高的原因。

3.2.2 不同字符串的内存开销

str_list = [f"item_{i}" for i in range(1000000)]中，每个元素是不同的字符串（“item_0” 到 “item_999999”）：

  • 这些字符串都是动态生成的不同内容，不会被驻留复用，每个都是独立的新字符串对象。
  • 每个短字符串对象的内存开销约 50-60 字节（包含元数据和字符数据）。
  • 总内存 = 指针数组（8MB）+100 万个独立字符串对象内存（1000000×50 字节≈48MB）≈56MB（与实测的 61.46MB 接近，差异来自字符串长度不同和元数据开销）。
    动态生成的不同字符串无法被驻留机制复用，每个字符串都需要单独存储元数据和字符数据，导致内存开销远高于相同元素的字符串列表。

4. 内存占用对比分析

列表类型指针数组内存（固定）元素对象内存（变量）总内存内存差异原因
same_item_num_list8MB28 字节（1 个 0 对象）8.06MB小整数缓存复用，元素内存可忽略
num_list8MB≈27MB（约 99 万个大整数）38.57MB大整数无缓存，每个都是新对象
same_item_str_list8MB50 字节（1 个 “item” 对象）8.06MB字符串驻留复用，元素内存可忽略
str_list8MB≈48MB（100 万个不同字符串）61.46MB动态字符串无驻留，每个都是新对象

5. 优化建议：利用对象复用减少内存开销

了解了 Python 的对象复用机制后，我们可以采取以下策略优化列表内存占用：

  1. 复用小整数和短字符串：在需要存储大量重复元素的场景中，尽量使用小整数（-5 到 256）和可驻留的短字符串，避免动态生成不同的元素。
  2. 使用数据结构优化重复元素存储：对于包含大量重复元素的列表，可使用array模块或 Pandas 的category类型，这些结构会自动复用重复元素，减少内存开销。
  3. 避免无意义的对象创建：在循环中避免重复创建相同的对象，例如将[f"abcdefghijklmnopqrstuvwxyz" for i in range(1000000)]改为item = "abcdefghijklmnopqrstuvwxyz"; [item for i in range(1000000)]，确保元素对象只创建一次。
  4. 针对大整数和长字符串的优化：对于大量大整数，可考虑使用 NumPy 数组存储；对于大量字符串，可使用 Pandas 的StringDtype或category类型，利用其内置的重复元素压缩机制。

6. 总结

Python 列表的内存占用差异主要来自元素对象的复用情况：相同元素的列表通过小整数缓存和字符串驻留机制复用对象，内存开销主要来自指针数组；而不同元素的列表需要为每个元素创建独立对象，每个对象的元数据开销累积导致内存飙升。

在实际开发中，当需要存储大量数据时，应充分利用 Python 的对象复用机制，选择合适的数据结构，避免无意义的对象重复创建。通过合理设计数据存储方式，既能减少内存占用，也能提高程序运行效率。

Read more

【C++ Qt】网络编程（QUdpSocket、QTcpSocket、Http）

【C++ Qt】网络编程（QUdpSocket、QTcpSocket、Http）

每日激励：“不设限和自我肯定的心态：I can do all things。 — Stephen Curry” 绪论 ： 本章将提到Qt中的网络部分，在看这篇文章之前需要有一定的网络基础也就是TCP/HTTP、本篇文章主要讲到的是Qt中基础的Udp、Tcp、Http的使用方法，并附有了多个小demo方便实操练习，并且其中还在每章最后进行了小总结回顾重要接口和函数方便回顾。 ———————— 早关注不迷路，话不多说安全带系好，发车啦（建议电脑观看）。 网络编程主要依赖于操作系统提供的Socket API。需要注意的是，C++标准库本身并未封装网络编程相关的API。 关于Qt网络编程的几个要点： 1. 网络应用开发本质上是编写应用层代码，需要传输层协议（如TCP/UDP）的支持 2. 为此，Qt提供了两套专门的网络编程API（QUDPSocket和QTcpSocket） 3. 使用Qt网络编程API时，需先在.pro文件中添加network模块 4. 之前学习的Qt控件和核心功能都属于QtCore模块（默认已包含） 为什么Qt要划分出这些模块呢？ Qt 本身是一个非常庞

By Ne0inhk
深入解剖STL RB-tree(红黑树)：用图解带入相关复杂操作实现

深入解剖STL RB-tree(红黑树)：用图解带入相关复杂操作实现

👇点击进入作者专栏： 《算法画解》 ✅ 《linux系统编程》✅ 《C++》 ✅ 文章目录 * 一、红黑树介绍 * 1. 什么是红黑树？ * 2. 红黑树的规则 * 3. 为什么最长路径不超过最短路径的两倍？ * 4. 红黑树的效率 * 二、红黑树的实现 * 2.1 红黑树的节点结构 * 2.2 红黑树整体结构 * 三、红黑树的插入操作 * 3.1 插入的大致流程 * 3.2 插入后的三种情况 * 情况1：叔叔节点存在且为红色（变色处理） * 情况2：叔叔节点不存在或为黑色 + cur和p在同一侧（单旋+变色） * 情况3：叔叔节点不存在或为黑色 + cur和p在不同侧（双旋+变色） * 3.3 插入完整代码 * 3.4 旋转操作的实现

By Ne0inhk

深入解析C/C++标量初始化警告：braces around scalar initializer的根源与修复

1. 什么是"braces around scalar initializer"警告？ 当你用C或C++写代码时，可能会遇到这样的警告："warning: braces around scalar initializer"。这个警告的意思是你在初始化一个标量（scalar）变量时，不必要地使用了花括号{}。 标量变量指的是那些简单的、不可再分的变量类型，比如： * 基本数据类型：int, float, double等 * 指针类型：int*, char*等 * 枚举类型 举个例子，下面这行代码就会触发这个警告： int x = {5}; // 警告：标量初始化使用了不必要的花括号 而正确的写法应该是： int x = 5; // 正确：直接使用值初始化标量 这个警告通常出现在GCC和Clang编译器中，特别是当你开启了-Wall或-Wextra警告选项时。

By Ne0inhk

C++中std::string的弱点：你可能未曾注意到的缺点

性能方面的局限 由于std::string是动态大小的字符串，它需要在运行时动态分配内存来存储字符串的内容。在字符串长度变化时，要频繁地进行内存分配和释放操作，导致一定的性能开销。 1. 频繁的内存分配和释放操作可能导致内存碎片的产生，内存空间的利用率降低。 2. 内存分配的成本比较高，特别是在频繁进行小块内存分配时，会增加系统开销。 3. 频繁地进行内存分配和释放操作会导致性能下降，尤其是在大规模数据处理时。 当字符串长度超过当前分配的内存空间时，std::string需要进行动态内存重分配，这会带来一定的性能开销。当字符串长度超过当前分配的内存空间时，std::string需要进行内存重分配，涉及到申请新的内存空间、拷贝数据、释放旧内存等操作，导致性能开销。 std::string 的性能局限之一是字符串拼接的效率问题。当对多个字符串进行拼接操作时，使用加法操作符或者append()方法在每次拼接时都需要进行内存重新分配和复制，这会导致较高的性能开销。特别是在频繁拼接大量字符串时，这种操作会导致大量的内存重分配和数据复制，从而影响程序的性能表现。 三、可变性带来的

By Ne0inhk