如何在Linux上分配内存而不过度使用
那是一个加载的问题，或者至少是一个不正确的问题。该问题基于错误的假设，这使得回答所陈述的问题充其量是不相关的，最糟糕的是会引起误解。
内存过量使用是一项系统范围的策略-
因为它确定为进程提供了多少虚拟内存-而不是由进程自己决定的事情。
由系统管理员确定内存是否过量使用。在Linux中，该策略是相当可调整的（例如
/proc/sys/vm/overcommit_memory，参见man
5 proc中的内容。
在分配期间，没有任何进程会影响内存过量使用策略 。
OP也似乎对使自己的进程不受Linux中的内存不足杀手（OOM杀手）的影响很感兴趣。（Linux中的OOM杀手是一种通过杀死进程，从而将其资源释放回系统来减轻内存压力的技术。）
这也是不正确的方法，因为OOM杀手是一个启发式过程，其目的不是“惩罚或杀死行为不良的过程”，而是使系统保持运行状态。此功能在Linux中也很可调，而且系统管理员甚至可以调整在内存压力大的情况下每个进程被杀死的可能性。除了进程使用的内存量以外，
还不完全取决于该进程来影响OOM杀手在内存不足的情况下是否将其杀死 。这也是系统管理员管理的策略问题，而不是流程本身。
我认为OP试图解决的实际问题是如何编写可以动态响应内存压力而不只是死掉的Linux应用程序或服务（由于SIGSEGV或OOM杀手的原因）。答案是 您不会
-让系统管理员担心对他们来说重要的事情，而不是他们的工作量-
除非您的应用程序或服务是使用大量内存的应用程序或服务因此在高内存压力下可能会被不公平地杀死。（特别是如果数据集足够大以至于需要进行比原先启用的交换量大得多的交换，则会导致较高的交换风暴风险，并且后期OOM杀手会太强。）
解决方案，或者至少是可行的方法，是对关键部分（甚至是整个应用程序/服务，如果它适用于不应交换到磁盘的敏感数据）进行内存锁定，或者将内存映射用于专用的备份文件。（对于后者，这是我在2011年编写的示例，该示例操作了TB级的数据集。）
OOM杀手仍然可以终止进程，并且仍然会发生SIGSEGV（由于内核无法向其提供RAM支持的库函数内部分配），除非所有应用程序都被锁定到RAM，但至少服务/流程不再是不
公平的 目标，只是因为它使用了大量内存。
可能会捕获到SIGSEGV信号（在没有可用内存来备份虚拟内存时发生），但是到目前为止，我还没有看到可以保证代码复杂性和所需维护工作的用例。
总之，对所述问题的正确答案是“ 否”，不要这样做 。
