从这篇文章中 ，我知道交换空间与物理内存相关。 所以假设物理内存和交换空间都是4 GB。 虽然在理论上，64位应用程序的内存空间接近2 ^ 64（当然，内核会占用一定的空间），但根据我的理解，应用程序可以使用的实际内存仅为8 GB。
所以我的问题是：对于在Unix / Linux上运行的应用程序，它可以使用的最大内存空间是否等于（物理内存+交换空间）？
这是一个复杂的问题。
首先，64位系统的理论虚拟内存空间为2 ^ 64。 但事实上，操作系统和CPU都不支持如此大的虚拟内存空间或物理内存。
目前的x86-64 CPU（也就是AMD64和英特尔当前的64位芯片）实际上使用48位地址线（AMD64）和42位地址线（Intel），理论上允许256太字节的物理RAM。
而且Linux在x86-64上每个进程允许128TB的虚拟内存空间，理论上可以支持64TB的物理内存。
对于你的问题，在理想情况下，Linux进程可以使用的最大虚拟内存空间只是上面的虚拟内存空间的Linux限制。 即使你的系统已经用完了所有的交换空间，只剩下100MB的空闲RAM，你的进程也可以利用整个内存空间。
但是你的系统对于虚拟内存空间请求（malloc，叫做brk / sbrk syscall）可能有一些限制。 例如，Linux有一个vm.overcommit_memory和vm.overcommit_ratio选项来决定malloc是否会拒绝进程。 见http://www.win.tue.nl/~aeb/linux/lk/lk-9.html 。
但是，虚拟内存空间不是真正的RAM +交换。 考虑到真正的内存+交换，你的观点是正确的：一个进程将永远不会使用比你的系统更真实的RAM +交换。 但是在大多数情况下，系统中会存在很多进程，所以你的进程可以使用的RAM + swap会被缩小。 如果所有物理RAM +交换都将耗尽，OOM杀手会选择一些进程来杀死。