linux内存学习记录

一、内存、磁盘空间和虚拟内存之间关系

二、查看指令

命令	全称	作用	显示对象
free -h	free memory	显示系统物理内存和交换分区（swap）的使用量	内存 (RAM + Swap)
df -h	disk free	显示文件系统的磁盘空间占用情况	磁盘分区 / 挂载点

• -h 选项表示 human-readable（以 K、M、G 等易读单位显示）

三、输出示例与字段解释

3.1 free -h 示例

bash

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           15G        2.1G        9.8G        245M        3.4G         12G
Swap:         2.0G          0B        2.0G

• Mem 行：物理内存（RAM）的使用情况。

  • total：物理内存总量。

  • used：已使用的内存（不含 buff/cache 中可回收的部分）。

  • free：完全未被使用的内存。

  • shared：主要用于 tmpfs 等共享内存。

  • buff/cache：内核缓存和缓冲区占用的内存（需要时可释放）。

  • available：估算的可用于启动新程序的内存（free + 可回收的 buff/cache）。

• Swap 行：交换分区（磁盘上模拟的内存）使用情况。

3.2df -h 示例

bash

$ df -h
文件系统        容量  已用  可用 已用% 挂载点
/dev/sda1        98G   30G   63G   33% /
/dev/sdb1        92G   60G   28G   69% /data

• 文件系统：磁盘分区或设备。

• 容量：分区总大小。

• 已用：已占用的磁盘空间。

• 可用：剩余可用的磁盘空间。

• 已用%：使用百分比。

• 挂载点：该分区挂载的目录路径。

四、核心区别

对比项	free -h	df -h
关注资源	内存（RAM）和交换分区（swap）	磁盘存储空间
数据来源	/proc/meminfo 等内存统计	文件系统元数据（如超级块）
单位	默认字节，-h 转换为 K/M/G	默认字节，-h 转换为 K/M/G
典型用途	检查内存是否充足、是否存在内存泄漏、swap 使用情况	查看磁盘是否快满、分区挂载情况、清理空间
影响因素	进程内存分配、缓存策略、swap 配置	文件创建/删除、日志增长、大文件占用

五、常见混淆点

• 内存与磁盘 ：free 涉及的是易失性存储（RAM），断电数据丢失；df 涉及的是持久化存储（硬盘、SSD）。

• swap 的误解 ：free 中的 swap 是磁盘空间，但属于虚拟内存的一部分；而 df 显示的磁盘分区中可能包含 swap 分区，但 df 默认不显示 swap 分区（需用 swapon --show 查看）。

• buff/cache 的回收 ：free 中的 available 体现了可回收的缓存，而 df 中的 可用 是直接可用的磁盘空间，无需回收。

---

六、 使用场景举例

• 系统运行变慢，怀疑内存不足 → 执行 free -h 查看内存和 swap 使用。

• 无法写入文件，提示"磁盘空间不足" → 执行 df -h 查看哪个分区已满。

• 想清理系统垃圾 → 先用 df -h 定位分区使用率，再用 du -sh /* 查找大目录。

七、虚拟地址空间"（4GB上限）与"虚拟内存"（物理内存+Swap的扩展机制）

32位系统的"虚拟地址空间"（4GB上限） ​ 和 广义的"虚拟内存"（物理内存+Swap的扩展机制）

32位系统的"虚拟地址空间"≠"虚拟内存（Swap）"

**7.1 32位虚拟地址空间（4GB）：进程的"私人地图"**​

32位CPU的地址总线宽度为32位，因此理论上能表示的虚拟地址范围是 0~2³²-1 （共4GB）。这就是32位系统常说的"虚拟地址空间上限"------每个进程认为自己独占一个4GB的连续地址空间（实际由内核和用户空间分割，如x86_32通常是用户空间3GB+内核空间1GB）。

这个"4GB虚拟地址空间"是进程的"私人地图"，用于映射它需要访问的内存（物理RAM或Swap）。但它只是一个"地址范围"，不代表实际有多少内存可用------就像一张地图标了4GB的区域，但实际住多少人（内存数据）取决于物理RAM和Swap的总和。

7.2. **广义"虚拟内存"：物理内存（RAM）+ Swap（磁盘扩展）**​

我们常说的"虚拟内存"（Virtual Memory），本质是操作系统通过磁盘（Swap）扩展物理内存的机制。它的公式是：

**可用内存总量 ≈ 物理内存（RAM） + 交换空间（Swap）**​

这里的"虚拟内存"是内存管理的扩展手段 ，目的是让进程以为自己有更多内存可用（即使物理RAM不够，也能把不活跃数据暂存到Swap）。它与32位系统的4GB虚拟地址空间是完全不同的概念：

💡 为什么会这样？32位系统的内存限制

这背后的根本原因在于 32 位架构的设计限制：

为了突破这个限制，一些技术如 PAE（物理地址扩展，Physical Address Extension） 被开发出来。它允许 32 位系统在硬件层面支持超过 4GB 的物理内存

八、问题：每个进程把地址用满会发生什么

• 4GB虚拟地址空间：进程的"地址地图"大小（每个进程独立）；

• 虚拟内存（RAM+Swap）：实际可使用的"内存总量"（系统级，所有进程共享物理RAM和Swap）。

• 在 32 位 Linux 系统上执行 free -h 命令，显示的格式和你之前在 64 位系统上看到的完全一样，仍然是那两行（Mem 和 Swap）以及六个列（total, used, free, shared, buff/cache, available）。

  最大的不同在于 total 值的大小 。因为 32 位系统的内存寻址空间有限，free -h 输出的总内存（total）通常会小于或等于 4GB。即使你安装了 8GB 的物理内存，系统通常也只能识别和使用其中的一部分。

  📊 32位系统 free -h 输出示例及解释

  假设你的 32 位系统安装了 3GB 内存，输出可能如下：

  bash

  $ free -h
                total        used        free      shared  buff/cache   available
  Mem:           2.9G        1.5G        345M         98M        1.1G        1.1G
  Swap:          1.0G        120K        1.0G

• Mem 行：显示物理内存的使用情况 。

  • total: 2.9G：这是系统实际识别出的总内存。在 32 位系统上，这个值最大通常在 3GB 到 4GB 之间。

  • used: 1.5G：已使用的内存。

  • free: 345M：完全空闲的内存。

  • shared: 98M ：主要用于 tmpfs 等共享内存 。

  • buff/cache: 1.1G：内核缓存和缓冲区占用的内存（需要时可释放）。

  • available: 1.1G ：估算的、可用于启动新程序的内存（free + 可回收的 buff/cache）。

• Swap 行：显示交换分区的使用情况 。

• 总寻址空间限制 ：32 位 CPU 的地址总线宽度为 32 位，因此它最大能访问的虚拟地址空间是 2 的 32 次方，即 4GB 。这 4GB 的空间需要同时容纳内存 、**硬件设备（如显卡的显存）**的 I/O 映射空间等 。

• 内核与用户空间划分 ：Linux 内核通常会把这 4GB 的虚拟地址空间分成两部分。例如，最常见的比例是 1GB 留给内核 使用，剩下的 3GB 给用户进程使用。这就导致即使物理内存有 4GB，用户程序最多也只能直接用到 3GB 左右。

• 物理内存访问限制 ：由于上述地址空间的划分，内核无法为所有超过 3GB 的物理内存建立直接、永久的映射 。这部分"看不见"的多余内存被称为 高端内存 (High Memory)。内核需要通过复杂的临时映射机制才能访问它，效率较低，且不能用于一些必须处于低端内存的内核任务。所以，很多 32 位系统默认配置下，能直接管理和使用的总内存（total）可能就止步于 3GB 多一点。

，"每个进程把地址用满"这个操作本身，并不意味着会立即用完物理内存。最终会发生什么，完全取决于你是"只用不碰"还是"又用又碰"。

我们可以用一个表格来清晰地展示在不同架构和不同行为下，会发生什么：

场景	32位系统 (用户空间约3GB)	64位系统 (用户空间超大, >128TB)
10个进程仅申请虚拟内存，但不读写	没问题，申请成功。每个进程都获得了自己的3GB虚拟地址空间，但这只是"画饼"，并没有实际消耗物理内存。10个进程的虚拟内存总和（30GB）远大于物理内存，但系统依然可以正常运行 。	没问题，申请成功。64位系统的虚拟空间近乎无限大，每个进程都能轻松拿到自己的3GB。系统运行如常 。
10个进程申请后，同时疯狂读写这3GB内存	系统崩溃（OOM） 。当所有进程都想把"画的饼"变成"真饼"时，物理内存（例如4GB）和Swap分区会瞬间被耗尽。此时，内核的OOM Killer会被触发，它会根据一套复杂的算法，选择一个它认为"最该死"的进程（通常是占用内存最大、优先级最低的）杀掉，以释放内存，保住系统 。	系统崩溃（OOM）。和32位系统一样，物理内存和Swap就是系统的总"真金白银"。当10个进程同时要求把30GB的虚拟内存全部映射到物理内存时，远超实际容量的需求会瞬间压垮系统，同样会触发OOM Killer来杀死进程 。
10个进程疯狂读写，但有足够大的Swap分区 (如100GB)	系统濒临"假死"，性能极低，但可能不会立刻崩溃 。系统会将暂时不用的内存页换出到磁盘上的Swap空间。但由于内存读写速度和磁盘读写速度有数量级的差距，系统绝大部分时间将花在"换入换出"数据上，这种现象叫"抖动"。你会感觉系统慢得完全无法响应，像死机了一样 。	系统濒临"假死"，性能极低。原理与32位系统完全一样。虽然地址空间大了，但物理内存的瓶颈依然存在。当所有进程都在疯狂读写，数据在内存和磁盘间频繁交换，系统同样会陷入严重的"抖动"而近乎假死 。

💡 深入理解：为什么结果会不同？

这个问题的核心，在于理解了虚拟内存的两个关键特性：

地址空间隔离：每个进程都活在自己独立的虚拟地址空间里，仿佛拥有整栋楼的"虚拟地契"。在32位系统上，这块"地"最多3GB；在64位系统上，这块"地"则大得几乎无穷无尽（128TB）。所以，仅申请虚拟内存时，大家是"井水不犯河水"的。

物理内存共享与竞争：物理内存（RAM）是整栋楼里真正能住人的"实体房间"。无论有多少进程，无论它们的"虚拟地契"有多大，最终都要争夺这些有限的"实体房间"。当所有进程都想把自己的"虚拟地"变成"实体房"时，争夺就爆发了。

所以，你问题的答案可以总结为：如果只是申请，大家各占各的虚拟地，相安无事。但如果都要用，就会引发对物理内存的激烈竞争，最终的结果取决于物理内存和Swap的总和是否够用。不够用，系统就会通过OOM Killer"强制清退"一些进程。