谢谢邀请。
首先,题目中 Linux 遇到的情况应该是在没有内存限制的情况下发生的。只要是生产环境中的 Linux 系统,负责的系统管理员都会设置 ulimit 用户继承的最大内存使用量。如果超出界限,程序就会无法继续获得内存,或者 new 语句返回 NULL,或者抛出 oom 异常(取决于编译器的编译选项中是否存在 -fexceptions 或 -fno-exceptions)。但是,很多系统默认的安装设置中,ulimit 都被设置为 unlimited,包括一些经常用于做服务器操作系统的 Linux 发行版,比如 Debian。在 ulimit 没有受限的情况下,Linux 会尽量满足应用程序的要求,直到虚拟内存(物理内存和磁盘交换区)都超过系统内建的硬限制为止。
(注:所谓硬限制,是说 Linux 内核在留给用户进程的内存外会保留一段专属于内核的内存,用来保证内存耗尽的情况下内核还能工作。专属区之外的部分,就可以被认为是用户进程能动用的内存的硬限制。)
但是,提问者发现程序执行后系统性能快速下降,则未必和内存有关。一般来说有两种因素可能导致这个问题:一、物理内存被用尽导致内核对其他用户进程实施频繁的换页操作;二、你的程序中用的 while(1) 没有适当进行 sleep(),耗尽了 CPU 时间。事实上,我倾向于认为第二个原因更有可能是真实原因。因为无论 Linux 还是 Windows 都对物理内存分配有优化操作,不会任何内容都尚未写入前就直接占用物理内存。从代码上看,虽然虚拟内存可能不停地增加,但物理内存不太可能迅速吃紧。反过来,CPU 时间被用完的可能性更大,因为默认情况下 Linux 多数发行版的 ulimit -t 仍然是 unlimited。相反地,Windows 通过进程的优先级可以在一定程度上限制进程占用 CPU 的时间,使别的程序不会失去响应。注:虽然 Linux 也有 nice 命令,但它默认是降低优先级,换言之,默认情况下所有进程都在一个相对较高和平等的优先级下起步。
最后,其实还有另一个可能,你的两台测试机配置不一样。如果测试时使用的 Windows 机器是双核的,那么这种情况就更正常:你还有一个核心是空闲的,别的进程跑在那个空闲的核心上呢。
至于 Linux 和 Windows 的内存管理。我只能说我对 Linux 相对熟悉一些,Windows 的内存管理部分代码我没有读过,确实不清楚,抱歉。
参考: