我正在学习 C，并且担心内存泄漏。我知道重启一般会刷内存，假设我不再运行程序，我会没事的。我正在考虑使用第二台大功率机器。如果出现以下情况，我会把系统搞砸到什么程度:
- 我做了一些可笑的蠢事
- 我使用 GCC(不确定编译器是否可以做任何事情？)
- 我有内存泄漏并重新启动
- 出于好奇，如果我使用虚拟机。我可能不会，因为我更喜欢使用真正的硬件。
以下任何事情会对我的系统产生长期影响吗？谢谢。
最佳答案
如果您的产品是纯软件，您最需要担心的就是内存泄漏，最终导致机器内存耗尽，无法再分配，应用程序将崩溃。很多内存不会重复发生，甚至不会走到这一步。当应用程序退出时，它们将消失。如果在崩溃时修改了某些内容，您的应用程序也可能会损坏数据，但这可能适用于任何类型的崩溃。
如果您的产品以某种方式控制硬件，您需要非常小心。如果软件出现故障，那么您将不知道硬件可能会做什么。就像其中一个评论说的那样，一艘飞船出现内存泄漏导致坠毁，可以让飞船坠毁。机器人可能会意外移动并造成属性(property)损失或人身伤害。其他设备可能会导致放电。
就处理内存泄漏而言，您只需要小心。在 C 语言中，对 malloc 和类似函数的任何调用都需要在所有 执行路径上与对 free 的调用配对。如果发生某种类型的错误，如果应用程序要继续运行，仍然需要调用 free。同样，fopen 应与 fclose 配对。在这里，您还可能遇到文件句柄用完的问题，这在很多方面都是不同但相似的问题。在 C++ 中，使用 new 的手动内存分配应该与 delete 配对，尽管使用像 std::unique_ptr、 这样的“智能”指针std::shared_ptr 和 std::weak_ptr 可以简化内存管理并防止内存泄漏。其他库也提供了使用引用计数来处理自己的生命周期的指针类型。我建议您在任何时候都可以使用这些而不是原始指针。如果您可以选择使用 C++ 而不是 C，我也建议您这样做。在大多数情况下(性能或其他)，您实际上不需要 C 而不是 C++。如果您不确定是否需要 C，您可以使用 C++。
如果您有兴趣查找内存泄漏，请查看 valgrind .它有很多功能可以帮助您发现内存泄漏并确定其严重性。
关于c - C 内存泄漏的现实危险？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/43530699/