物理泄漏
GC所解决的错误（至少对于外部观察者而言）似乎是一种很好地了解他的语言，库，概念，习惯用法等的程序员所不会做的事情。但是我可能是错的：手动内存处理本质上是复杂的吗？
来自C端，它使内存管理尽可能地手动和清晰，以便我们比较极端情况（C ++大多在没有GC的情况下自动执行内存管理），我会说“不是真的”，而与之相比发生泄漏。初学者，有时甚至是专业人士，都可能忘记free为给定的内容写作malloc。肯定会发生。
但是，有诸如valgrind泄漏检测之类的工具可以在执行代码时，何时/何地发生此类错误直至确切的代码行立即发现。将其集成到CI中后，几乎不可能合并这些错误，并且很容易纠正它们。因此，在具有合理标准的任何团队/流程中，这都不是什么大问题。
当然，在某些情况下，执行free失败可能会在测试的注意范围内进行，而调用失败，也许是在遇到晦涩的外部输入错误（例如损坏的文件）时，这种情况下系统可能会泄漏32个字节或其他内容。我认为，即使在相当好的测试标准和泄漏检测工具下，也肯定会发生这种情况，但是对于几乎从未发生过的事情泄漏一点内存也不是那么重要。我们将看到更大的问题，即即使在下面的常见执行路径中，我们也可能以GC无法阻止的方式泄漏大量资源。
当对象的生存期需要某种形式的延迟/异步处理（可能由另一个线程）扩展时，如果没有类似GC伪形式（例如引用计数）的东西，这也很困难。
悬空指针
使用更多手动形式的内存管理的真正问题并没有泄漏给我。我们知道有多少用C或C ++编写的本机应用程序确实泄漏了？Linux内核泄漏吗？MySQL的？CryEngine 3？数字音频工作站和合成器？Java VM是否泄漏（以本机代码实现）？Photoshop？
如果有的话，我认为当我们环顾四周时，最泄漏的应用程序往往是使用GC方案编写的应用程序。但是在此之前，本机代码有一个重大问题，它与内存泄漏无关。
对我来说，问题始终是安全。即使当我们free通过指针进行存储时，如果还有其他指向资源的指针，它们也将变为悬空（无效）的指针。
当我们尝试访问那些悬空指针的指针时，最终会遇到不确定的行为，尽管几乎总是出现段错误/访问冲突，从而导致立即崩溃。
我上面列出的所有那些本机应用程序可能都有一个或两个模糊的边缘情况，这可能主要是由于此问题而导致崩溃，并且肯定有相当一部分用本机代码编写的伪劣应用程序是非常崩溃的，而且经常很大程度上是由于这个问题。
...这是因为无论您是否使用GC，资源管理都很困难。面对导致资源管理不善的错误，实际的差异通常是泄漏（GC）或崩溃（没有GC）。
资源管理：垃圾回收
无论如何，复杂的资源管理都是一个困难的手动过程。GC无法在此处自动执行任何操作。
让我们举一个例子，我们有一个对象“ Joe”。乔被其加入的许多组织所引用。他们每个月左右都会从他的信用卡中提取会员费。
我们还可以参考乔来控制他的一生。可以说，作为程序员，我们不再需要Joe。他开始缠扰我们，我们不再需要他所属的这些组织浪费时间与他打交道。因此，我们试图通过删除他的生命线参考将他从大地上抹掉。
...但是等等，我们正在使用垃圾回收。对乔的任何强烈提及都会使他留在身边。因此，我们也从他所属的组织中删除了对他的引用（取消订阅）。
...除了哎呀，我们忘了取消他的杂志订阅！现在，乔仍然在记忆中，困扰着我们并耗尽了资源，而杂志公司也最终继续继续每月处理乔的会员资格。
这是主要的错误，它可能导致使用垃圾回收方案编写的许多复杂程序泄漏得越久，它们运行的时间越长，并开始使用越来越多的内存，并且处理的次数可能越来越多（循环杂志订阅）。他们忘记删除这些引用中的一个或多个，从而使垃圾收集器无法魔术，直到关闭整个程序。
该程序不会崩溃，但是。非常安全。这只是为了增加记忆，而Joe仍然会流连忘返。对于许多应用程序而言，这种泄漏行为（我们只是在这个问题上投入越来越多的内存/处理）可能比硬崩溃要好得多，尤其是考虑到当今我们的计算机具有多少内存和处理能力。
资源管理：手册
现在，让我们考虑一下使用指向Joe的指针和手动内存管理的替代方法，如下所示：
这些蓝色链接无法管理乔的一生。如果我们想将他从地球上移开，我们会手动要求销毁他，如下所示：
现在，通常情况下，我们到处都是悬空的指针，所以让我们删除指向Joe的指针。
...糟糕，我们又犯了同样的错误，却忘记了退订Joe的杂志！
除了现在，我们还有一个悬空的指针。当杂志订阅试图处理Joe的月租费时，整个世界都会爆炸式增长-通常，我们会立即遭受重创。
开发人员忘记手动删除对资源的所有指针/引用的这种基本的资源管理不当错误也可能导致本机应用程序崩溃。它们通常不会运行更长的时间，因为在这种情况下，它们经常会彻底崩溃。
真实世界
现在，上面的示例使用的是一个荒谬的简单图表。现实世界中的应用程序可能需要将数千张图像缝合在一起才能覆盖整个图，场景图中存储了数百种不同类型的资源，GPU资源与其中的某些资源相关联，加速器与其他资源相关联，观察者分布在数百个插件中观看场景中的多种实体类型以进行更改，观察者观察观察者，将音频同步到动画等。因此，似乎很容易避免我上面描述的错误，但是在现实世界中通常没有这么简单的方法了跨数百万行代码的复杂应用程序的生产代码库。
某天某人会错误地管理该代码库中某处的资源的机会往往很高，无论是否使用GC，这种可能性都是相同的。主要区别是由于此错误而将发生的情况，这也可能影响潜在地发现和修复此错误的速度。
崩溃与泄漏
现在哪一个更糟？立即崩溃，还是无声的内存泄漏，让Joe神秘地徘徊？
大多数人可能会回答后者，但可以说该软件被设计为连续运行数小时，甚至可能数天，而我们添加的这些Joe's和Jane's中的每一个都会使该软件的内存使用量增加1 GB。它不是关键任务软件（崩溃实际上并不会杀死用户），而是性能关键软件。
在这种情况下，硬调试在调试时立即显示出来，指出您所犯的错误，实际上可能比泄漏的软件更可取，而泄漏的软件甚至可能在您的测试程序的监视下飞翔。
另一方面，如果它不是以性能为目标的任务关键型软件，而不会以任何可能的方式崩溃，则泄漏实际上可能更可取。
参考文献薄弱
GC方案中存在这些想法的混合形式，称为弱引用。使用弱引用，我们可以让所有这些组织都使用弱引用Joe，但是当强引用（Joe的所有者/生命线）消失时，我们不能阻止他被删除。但是，我们获得的好处是能够通过这些弱引用来检测Joe何时不再存在，从而使我们能够轻松获得各种错误。
不幸的是，弱引用没有得到应有的使用，因此，许多复杂的GC应用程序可能容易泄漏，即使它们比复杂的C应用程序崩溃的可能性小得多，例如
无论如何，GC是否使您的生活更轻松或更艰难，取决于软件对避免泄漏的重要性，以及它是否涉及这种复杂的资源管理。
以我为例，我在性能至关重要的领域工作，资源确实跨越了数百兆字节到千兆字节，并且由于类似上述错误而在用户请求卸载时不释放该内存，实际上比崩溃更不受欢迎。崩溃很容易发现和重现，即使它们不是用户最不喜欢的地方，也经常成为程序员最喜欢的错误，并且很多此类崩溃会在他们到达用户之前通过健全的测试过程显示出来。
无论如何，这些就是GC和手动内存管理之间的区别。要回答您的紧迫问题，我想说手动内存管理很困难，但是与泄漏几乎没有关系，当资源管理不那么重要时，GC和手动形式的内存管理仍然非常困难。在这里，GC可以说具有更棘手的行为，其中程序似乎运行良好，但消耗了越来越多的资源。手动表单的技巧不那么复杂，但是会崩溃并浪费大量时间，并出现上述错误。