物理的な漏れ
GCが対処する種類のバグは、（少なくとも外部の観察者にとっては）自分の言語、ライブラリ、概念、イディオムなどをよく知っているプログラマーがしないようなことのように見えます。しかし、私は間違っている可能性があります：手動メモリ処理は本質的に複雑ですか？
メモリ管理を可能な限り手動で発音し、極端なものを比較する（C ++はほとんどGCなしでメモリ管理を自動化する）Cエンドから来ると、GCと比較するという意味で「実際にはない」と言います来るリーク。初心者や時にはプロでさえfree、与えられたものを書くのを忘れるかもしれませんmalloc。それは間違いなく起こります。
しかし、valgrindリーク検出などのツールがあり、コードの実行時に、そのようなミスがコードの正確な行までいつ/どこで発生したかを即座に見つけます。それがCIに統合されると、そのような間違いをマージすることはほぼ不可能になり、修正するのは簡単になります。したがって、合理的な基準を備えたチーム/プロセスでは決して大したことではありません。
確かに、free呼び出されなかったテストのレーダーの下で飛ぶエキゾチックな実行ケースがいくつかあるかもしれません。おそらく破損したファイルのようなあいまいな外部入力エラーが発生すると、システムが32バイトか何かをリークする可能性があります。かなり良いテスト標準とリーク検出ツールの下でもそれは間違いなく起こると思いますが、ほとんど起こらないことで少しのメモリをリークすることもそれほど重要ではありません。以下の一般的な実行パスであっても、GCで防止できない方法で大量のリソースをリークする可能性のある、はるかに大きな問題が発生します。
また、おそらく別のスレッドによって何らかの形の遅延/非同期処理のためにオブジェクトのライフタイムを延長する必要がある場合、GCの疑似形式（参照カウントなど）に似たものがなければ困難です。
宙ぶらりんのポインター
メモリ管理のより多くの手動形式の本当の問題は、私にはリークではありません。CまたはC ++で記述されたネイティブアプリケーションのうち、本当に漏れやすいものはどれくらいあるでしょうか。Linuxカーネルは漏れやすいですか？MySQL？CryEngine 3？デジタルオーディオワークステーションとシンセサイザー？Java VMはリークしますか（ネイティブコードで実装されていますか）？Photoshop？
どちらかといえば、私たちが見回すと、最もリークの多いアプリケーションはGCスキームを使用して記述されたものになる傾向があると思います。しかし、それがガベージコレクションのバタンとされる前に、ネイティブコードにはメモリリークとはまったく関係のない重要な問題があります。
私にとっての問題は常に安全でした。私たちもfreeポインターを介し記憶する、リソースへの他のポインターがある場合、それらはぶら下がり（無効化された）ポインターになります。
これらのぶら下がりポインタのポインティにアクセスしようとすると、未定義の動作に陥りますが、ほとんどの場合、セグメンテーション違反/アクセス違反が発生してすぐにクラッシュします。
上記のすべてのネイティブアプリケーションには、主にこの問題が原因でクラッシュを引き起こす可能性のある不明瞭なエッジケースが1つまたは2つあります。これは主にこの問題によるものです。
...それはリソース管理のためですは、GCを使用するかどうかに関係なく、が難しい。実際の違いは、多くの場合、リソースの誤った管理につながるミスに直面した場合のリーク（GC）またはクラッシュ（GCなし）です。
リソース管理：ガベージコレクション
複雑なリソース管理は、どんなに難しい手動のプロセスです。GCはここでは何も自動化できません。
このオブジェクト「Joe」がある例を見てみましょう。ジョーは、彼がメンバーである多くの組織から参照されています。彼らは毎月かそこらで彼のクレジットカードから会費を引き出します。
また、ジョーの生涯をコントロールするためのジョーへの言及もあります。プログラマーとして、ジョーはもう必要ないとしましょう。彼は私たちを悩ませ始めており、彼が所属しているこれらの組織は、彼に対処する時間を無駄にする必要がなくなりました。そこで、私たちは彼のライフライン参照を削除することにより、彼を地球の表面から拭き取ろうとします。
...しかし、待ってください。ガベージコレクションを使用しています。ジョーへの強い言及はすべて彼を引き留めます。そのため、彼の所属する組織から彼への参照も削除します（彼の登録を解除します）。
...フープを除いて、彼の雑誌の購読をキャンセルするのを忘れていました！現在、Joeは記憶に残り、私たちを悩ませ、リソースを使い果たしています。また、雑誌会社は、Joeのメンバーシップを毎月処理し続けています。
これは、ガベージコレクションスキームを使用して記述された多くの複雑なプログラムがリークし、実行時間が長くなるにつれてメモリを使い果たし、処理が増える可能性がある主な間違いです（定期的な雑誌購読）。それらは、これらの参照の1つ以上を削除するのを忘れていたため、プログラム全体がシャットダウンされるまで、ガベージコレクターが魔法をかけることができませんでした。
ただし、プログラムはクラッシュしません。それは完全に安全です。それはちょうどメモリを独占し続け、ジョーはまだ残っています。多くのアプリケーションでは、問題にメモリ/処理を追加するだけのこの種の漏れやすい動作は、特に今日のマシンのメモリと処理能力を考えると、ハードクラッシュよりもはるかに望ましい場合があります。
リソース管理：手動
次に、Joeへのポインタと手動メモリ管理を使用する代替案を考えてみましょう。
これらの青いリンクは、ジョーの生涯を管理しません。地球の表面から彼を削除したい場合、次のように手動で彼を破壊するように要求します。
今では通常、あちこちにぶら下がっているポインターが残っているので、Joeへのポインターを削除しましょう。
...まったく同じ間違いを犯し、ジョーの雑誌購読を解除するのを忘れていました！
今を除いて、宙ぶらりんのポインターがあります。雑誌の購読がJoeの月額料金を処理しようとすると、全世界が爆発します。通常、即座にハードクラッシュが発生します。
開発者がリソースへのすべてのポインター/参照を手動で削除するのを忘れた、これと同じ基本的なリソースの誤った管理ミスにより、ネイティブアプリケーションで多くのクラッシュが発生する可能性があります。この場合、しばしば完全にクラッシュするため、通常、実行時間が長くなってもメモリを占有しません。
現実の世界
さて、上記の例はとてつもなくシンプルな図を使用しています。実際のアプリケーションでは、シーングラフに格納された数百の異なるタイプのリソース、それらのいくつかに関連付けられたGPUリソース、他のユーザーに結び付けられたアクセラレーター、数百のプラグインに分散されたオブザーバーを含む、グラフ全体をカバーする数千の画像が必要になる場合がありますシーン内のいくつかのエンティティタイプの変化を監視し、観測者が観測者を観察し、音声がアニメーションに同期しているなど。上記の間違いを回避するのは簡単に思えるかもしれませんが、実世界では一般的にこれほど単純ではありません数百万行のコードにまたがる複雑なアプリケーションの本番コードベース。
いつか誰かがそのコードベースのどこかでリソースを誤って管理する可能性は非常に高くなる傾向があり、その可能性はGCの有無にかかわらず同じです。主な違いは、この間違いの結果として何が起こるかであり、これは、この間違いを発見して修正する速さにも影響する可能性があります。
クラッシュ対リーク
今、どれが悪いですか？すぐにクラッシュするのか、Joeが不思議なままに残るサイレントメモリリークですか？
ほとんどが後者に答えるかもしれませんが、このソフトウェアは数時間、場合によっては数日間実行されるように設計されているとしましょう。追加したこれらのJoeとJaneのそれぞれは、ソフトウェアのメモリ使用量を1ギガバイト増やします。それはミッションクリティカルなソフトウェアではなく（クラッシュは実際にユーザーを殺すことはありません）、パフォーマンスにクリティカルなソフトウェアです。
この場合、デバッグ時にすぐに表示されるハードクラッシュは、あなたが犯した間違いを指摘し、テスト手順のレーダーの下を飛ぶ可能性のある漏れやすいソフトウェアよりも実際に望ましい場合があります。
一方、パフォーマンスが目標ではないミッションクリティカルなソフトウェアであり、可能な限りクラッシュしない場合、実際にはリークが望ましい場合があります。
弱い参照
弱参照として知られるGCスキームには、これらのアイデアのハイブリッドがあります。弱参照を使用すると、これらすべての組織にJoeを弱参照させることができますが、強参照（Joeの所有者/ライフライン）がなくなったときに彼が削除されるのを防ぐことはできません。それにもかかわらず、Joeがこれらの弱い参照を介してもはや存在しないことを検出できるという利点が得られ、簡単に再現可能な種類のエラーを取得することができます。
残念なことに、弱参照はおそらく使用されるほどには使用されないため、多くの複雑なGCアプリケーションは、複雑なCアプリケーションよりもはるかにクラッシュしにくい場合でも、リークの影響を受けやすい場合があります。
いずれにせよ、GCがあなたの人生を楽にするか難しくするかは、あなたのソフトウェアがリークを避けることがいかに重要か、そしてこの種の複雑なリソース管理を扱うかどうかに依存します。
私の場合、リソースが数百メガバイトからギガバイトに及ぶパフォーマンスが重要な分野で働いていますが、上記のような間違いのためにユーザーがアンロードを要求したときにそのメモリを解放しないことは、実際にはクラッシュよりも好ましくありません。クラッシュは簡単に発見して再現できるため、ユーザーにとって最も嫌いなものでなくても、多くの場合プログラマーのお気に入りのバグになります。これらのクラッシュの多くは、ユーザーに届く前に健全なテスト手順で表示されます。
とにかく、これらはGCと手動メモリ管理の違いです。あなたの直接の質問に答えるために、手動のメモリ管理は難しいと思いますが、リークとはほとんど関係がなく、リソース管理が重要でない場合、GCと手動のメモリ管理の両方は依然として非常に困難です。GCはおそらく、プログラムが正常に動作しているように見えますが、ますます多くのリソースを消費している、よりトリッキーな動作をしています。手動のフォームはそれほどトリッキーではありませんが、上記のようなミスでクラッシュして大きな時間を費やすことになります。