已有虚拟内存为何仍需内存保护？兼论访问违例检测的硬件成本

一、本文所指的内存保护示例 #

如下C++程序在多数设备上会触发运行时异常，这就是本文讨论的内存保护行为：

#include <iostream>

int main() {
    int* my_int = new int[12];
    std::cout << my_int[20000];
    delete[] my_int;
    return 0;
}

程序运行时会抛出类似如下的访问违例错误：

Exception thrown at 0x00007FF7A467101A in myprogram.exe: 0xC0000005: Access violation reading location 0x000002794CA635C0.

二、核心问题 #

既然每个进程拥有独立虚拟内存，其他程序已能免受本程序访问违例的影响，但正确程序似乎仍要为错误程序的未分配内存访问付出运行时成本。为何计算机要在非Debug模式下仍进行访问违例保护？

三、问题解答 #

1. 初始问题解答 #

这类访问违例检测通常由硬件完成，而非操作系统在运行时额外开销检测，因此所谓的“运行时成本”几乎可以忽略。

2. 后续追问解答 #

（1）若硬件无需触发访问违例异常，能否实现更高速硬件？

理论上可行，但实际收益极低，完全不值得为此修改硬件设计。

（2）访问违例检测的硬件成本究竟有多少？

访问违例检测依赖CPU的内存管理单元（MMU）和页表机制，而这两部分是现代CPU实现虚拟内存、进程隔离的基础组件——即便去掉访问违例检测，MMU和页表依然需要存在来完成地址转换、内存分页等核心功能。

具体来说，访问违例检测只是在MMU完成虚拟地址到物理地址转换的过程中，额外检查该页的权限标记（如是否可读、可写、已分配），这个检查是流水线式的、与地址转换并行完成的，几乎不会带来额外延迟。硬件上的成本仅仅是在页表项中增加几个权限位（通常2-4个比特），以及MMU中对应的简单逻辑判断电路，这部分开销在整个CPU的硬件规模里可以忽略不计。

相反，如果去掉访问违例检测，不仅无法快速定位程序的内存错误（比如越界访问、使用已释放内存），还可能导致错误的内存写入破坏进程自身的合法数据，引发更隐蔽的程序崩溃或逻辑错误，反而会大幅增加软件开发和调试的成本。

内容的提问来源于stack exchange，提问作者Mark Wallace