blocks|key|137858|text|C标准没有指定在程序终止时释放由malloc分配的内存。这是由操作系统完成的，并不是所有的OSes+(通常在嵌入式环境中)都会在程序终止时释放内存。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|137859|entityMap^0|G|6|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

The C Standard does not specify that memory allocated by <code>malloc</code> is released when the program terminates. This done by the operating system and not all OSes (usually these are in the embedded world) release the memory when the program terminates.

blocks|key|355708|text|这更可能取决于操作系统而不是语言。最终，任何语言的任何程序都将从操作系统获取内存。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|355709|我从来没有听说过一个操作系统在程序退出/崩溃时不回收内存。因此，如果你的程序对它需要分配的内存有一个上限，那么只分配而不释放是完全合理的。|355710|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

This is more likely to depend on operating system than language. Ultimately any program in any language will get it's memory from the operating system.

I've never heard of an operating system that doesn't recycle memory when a program exits/crashes. So if your program has an upper bound on the memory it needs to allocate, then just allocating and never freeing is perfectly reasonable.

blocks|key|137900|text|所有当之无愧的操作系统都会清理你的进程在终止后造成的混乱。但总有一些不可预见的事件，如果它被以某种方式拒绝访问，并且一些糟糕的程序员没有预见到这种可能性，所以它不会在稍后重试，那该怎么办？如果内存泄漏是任务关键型的，那么只清理自己总是更安全的-否则如果这种努力是昂贵的，那么就不值得付出这样的努力。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|137901|编辑:您确实需要清理内存泄漏，如果它们在它们将积累的地方，如在循环中。我所说的内存泄漏是那些在整个程序过程中不断积累的内存泄漏，如果你有任何其他类型的泄漏，它迟早会成为一个严重的问题。|137902|在技术术语中，如果您的泄漏是内存“复杂性”O(1)，它们在大多数情况下都是好的，O(logn)已经令人不快(在某些情况下是致命的)和O(N)%2B无法忍受。|137903|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

All operating systems deserving the title will clean up the mess your process made after termination. But there are always unforeseen events, what if it was denied access somehow and some poor programmer did not foresee the possibility and so it doesn't try again a bit later?
Always safer to just clean up yourself IF memory leaks are mission critical - otherwise not really worth the effort IMO if that effort is costly.

Edit:
You do need to clean up memory leaks if they are in place where they will accumulate, like in loops. The memory leaks I speak of are ones that build up in constant time throughout the course of the program, if you have a leak of any other sort it will most likely be a serious problem sooner or later.

In technical terms if your leaks are of memory 'complexity' O(1) they are fine in most cases, O(logn) already unpleasant (and in some cases fatal) and O(N)+ intolerable.

blocks|key|137922|text|正如其他人所说，大多数操作系统将在进程终止时回收分配的内存(可能还有其他资源，如网络套接字、文件句柄等)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|137923|话虽如此，在处理new/delete+(而不是原始的malloc/free)时，内存可能不是唯一需要担心的问题。在new中分配的内存可能会被回收，但在对象的析构函数中可能完成的事情将不会发生。也许某些类的析构函数在销毁时会将一个标记值写入文件中。如果进程刚刚终止，文件句柄可能会被刷新，内存可能会被回收，但该标记值不会被写入。|137924|这个故事的寓意是，总是自己清理干净。不要让事情摇摆不定。不要依赖操作系统在你之后进行清理。自己清理一下吧。|137925|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Like the others have said, most operating systems will reclaim allocated memory upon process termination (and probably other resources like network sockets, file handles, etc).

Having said that, the memory may not be the only thing you need to worry about when dealing with new/delete (instead of raw malloc/free). The memory that's allocated in new may get reclaimed, but things that may be done in the destructors of the objects will not happen. Perhaps the destructor of some class writes a sentinel value into a file upon destruction. If the process just terminates, the file handle may get flushed and the memory reclaimed, but that sentinel value wouldn't get written.

Moral of the story, always clean up after yourself. Don't let things dangle. Don't rely on the OS cleaning up after you. Clean up after yourself.

blocks|key|137948|text|如果您有进程间通信，这可能会导致其他进程永远无法完成，并根据协议消耗资源。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|137949|举个例子，我曾经在Java中尝试打印到PDF打印机，当我在打印作业中途终止JVM时，PDF假脱机进程仍然处于活动状态，我必须在任务管理器中终止它，然后才能重试打印。|137950|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If you have interprocess communication, this can lead to other processes never completing and consuming resources depending on the protocol.

To give an example, I was once experimenting with printing to a PDF printer in Java when I terminated the JVM in the middle of a printer job, the PDF spooling process remained active, and I had to kill it in the task manager before I could retry printing.

blocks|key|355828|text|兼容POSIX的系统上的共享内存将一直存在，直到调用shm_unlink或重新启动系统。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|355829|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Shared memory on POSIX compliant systems persists until shm_unlink is called or the system is rebooted.

I've run into memory leaks many times. Usually when I'm <code>malloc</code>-ing like there's no tomorrow, or dangling <code>FILE *</code>s like dirty laundry. I generally assume (read: hope desperately) that all memory is cleaned up at least when the program terminates. Are there any situations where leaked memory won't be collected when the program terminates, or crashes?

If the answer varies widely from language-to-language, then let's focus on C(++).

Please note hyperbolic usage of the phrase, 'like there's no tomorrow', and 'dangling ... like dirty laundry'. Unsafe* <code>malloc</code>*ing can hurt the ones you love. Also, please use caution with dirty laundry.

How far can memory leaks go?

Java

我曾多次遇到内存泄漏问题。通常当我是malloc-ing的时候，就像没有明天，或者像脏衣服一样挂着FILE *s。我通常认为(阅读:绝望的希望)，所有内存都被清理，至少当程序终止时。是否存在在程序终止或崩溃时无法收集泄漏的内存的情况？如果答案因语言而异，那么让我们关注一下C(++)。请注意短语的夸张用法，“就像没有明天...

问内存泄漏能走多远？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问内存泄漏能走多远？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问内存泄漏能走多远？
EN