监视python脚本正在使用的系统资源并在资源使用超过某些预定值时终止它的“正确”或“最佳”方法是什么。在我的情况下，内存使用是值得关注的。尽管我愿意接受建议，但我并不是在问如何衡量系统资源的使用。
作为一个简单的例子，假设我有一个函数可以找到小于某个大数的素数，并根据某些条件将它们添加到列表中。我事先不知道有多少质数会满足条件，所以如果我使用最多的系统内存（比如说 8gb），我要确保终止函数。我知道有一些方法可以监控 python 对象的大小。我不知道监控列表大小和退出的正确方法是在主函数循环中包含一个大小测试，如果它超过 8gb 或者如果有“外部”（我的意思是外部的）则退出在循环外部但仍然在 python 脚本内或部分）监视和退出的方式。
在我的情况下，我在 Mac 上运行，但一般都在问这个问题。
在类 Unix 系统上，监视任何进程的有用“外部”方法是ulimit命令（您没有说明是否要在 Windows 中运行，Windowsulimit不存在，其他方法可能，但我不认识他们;-）。
如果您正在考虑在自己的 Python 程序中执行此类控制，只需更改相关函数以检查它附加到列表中的每个对象的大小（并保持运行总数）并在运行总数达到或超过时返回阈值（您可以将其作为额外参数传递给相关函数）。
编辑：OP在评论中澄清说，他们希望将监控放在可能放置的最糟糕的地方——在前面的段落中，我提到了在流程之外很容易，在函数内部很容易，但是OP想要它“在中间”；-)。
最不坏的方法可能是使用“看门狗线程”——无限循环中的一个单独的守护线程，它每秒钟X检查一次进程的资源消耗（例如，使用resource.getrusage，如果在类 Unix 机器上——再次，如果在 Windows 上，则需要其他东西），如果该消耗超过所需的限制，则尝试使用thread.interrupt_main杀死主线程。当然，这是万无一失的失败：周期性X（就像在“轮询”的所有情况下一样）必须足够低以同时停止失控的进程，但又足够高以不会使进程减速到爬行。另外，主线程（唯一可以像这样被中断的线程）可能正在阻塞异常（在这种情况下，看门狗线程可能会尝试使用越来越严重的“这个进程的信号”，一直到SIGKILL杀手-永远不会被阻塞或拦截的信号）。
因此，这种中间方法比ulimit命令要多得多，也更脆弱，没有实质性的附加值。但是，如果你想把监控放在“进程内部，资源消耗功能之外”，没有优点，工作量大，还有我提到的其他缺点，这就是这样做的方法。
resource.getrusage()（特别是ru_idrss）可以为您提供当前python解释器的资源使用情况，您可以将其用作停止处理的哨兵。