リソース管理（コンピューティング）

コンピュータプログラミングにおいて、リソース管理とは、リソース(利用可能性が制限されているコンポーネント) を 管理する手法を指します。

コンピュータ プログラムは、プログラミング言語によって公開さ^れる機能を使用して^独自のリソースを管理する場合もあれば⁽ Elder、Jackson、Liblit (2008) は、さまざまなアプローチを比較した調査記事です)、ホスト (オペレーティング システムまたは仮想マシン) または別のプログラムによってリソースを管理する場合もあります。

ホストベースの管理はリソース トラッキングと呼ばれ、リソース リークのクリーンアップ、つまり、取得されたが使用後に解放されていないリソースへのアクセスの終了で構成されます。これはリソースの再利用と呼ばれ、メモリのガベージ コレクションに似ています。多くのシステムでは、プロセスがexit システム コールを実行した後、オペレーティング システムがリソースを再利用します。

プログラムがリソースの使用を終了したときにそのリソースを解放しないことは、リソース リークと呼ばれ、シーケンシャル コンピューティングで問題になります。複数のプロセスが限られたリソースにアクセスしようとすると、並行コンピューティングで問題になる可能性があり、リソース競合と呼ばれます。

リソース管理は、これら両方の状況を防ぐためにアクセスを制御しようとします。

正式には、リソース管理（リソースリークの防止）は、リソースが正常に取得された場合にのみリソースが解放されるようにすることです。この一般的な問題は、「前、 本体、後」のコードとして抽象化できます。これらのコードは通常、この順序で実行されますが、本体コードが正常に実行されるかどうかに関係なく、前コードが正常に完了した場合にのみ後コードが呼び出されるという条件があります。これは、実行アラウンド^[1]またはコードサンドイッチとも呼ばれ、プログラム状態の一時的な変更や、サブルーチンへのエントリと終了のトレースなど、さまざまなコンテキスト^[2]で発生します。ただし、リソース管理は最も一般的に引用されるアプリケーションです。アスペクト指向プログラミングでは、このような実行アラウンドロジックはアドバイスの一種です。

制御フロー分析の用語では、リソースの解放は、リソースの取得の成功に先行する必要があります。 ^[3]これを保証できない場合はバグであり、この条件に違反するコードパスはリソースリークを引き起こします。 リソースリークは多くの場合軽微な問題であり、一般的にプログラムをクラッシュさせることはありませんが、プログラムまたはシステム全体の速度低下を引き起こします。^{[2]ただし、}リソースの枯渇により、プログラム自体または他のプログラムのクラッシュを引き起こす可能性があります。システムのリソースが不足すると、取得要求は失敗します。攻撃によってリソースが枯渇する可能性があると、セキュリティバグが発生する可能性があります。 リソースリークは、通常のプログラムフロー（単にリソースを解放し忘れるなど）で発生する場合もあれば、プログラムの別の部分で例外が発生した場合にリソースが解放されないなど、例外的な状況でのみ発生する場合もあります。 リソースリークは、ステートメントによるサブルーチンの早期終了return、またはサブルーチン自体またはサブルーチンが呼び出すより深いサブルーチンによって発生した例外によって発生することがよくあります。 return ステートメントによるリソースの解放は、戻る前にサブルーチン内で慎重に解放することで処理できますが、解放コードが実行されることを保証する追加の言語機能がなければ、例外を処理することはできません。

もっと微妙なことに、リソースの獲得が成功すれば、リソースの解放が優先される必要があります。そうしないと、コードは獲得していないリソースを解放しようとするからです。このような誤った解放の結果は、黙って無視されることから、プログラムのクラッシュや予測できない動作までさまざまです。これらのバグは、リソース割り当てがまず失敗する必要があるため、通常はまれにしか発生しません。これは通常、例外的なケースです。さらに、重要なリソースの獲得に失敗したためにプログラムがすでにクラッシュしている可能性があるため、結果は深刻ではない可能性があります。ただし、これらのバグによって障害からの回復が妨げられたり、正常なシャットダウンが無秩序なシャットダウンになったりする可能性があります。この状態は通常、リソースの獲得が成功したかどうかを確認してから解放することで保証されます。そのためには、「獲得に成功した」ことを記録するブール変数を用意します。リソースは獲得されているがフラグ変数が更新されなかった場合はアトミック性が失われます。その逆の場合、またはリソースへのハンドルがnull 許容型(「null」は「獲得に成功していない」ことを示し、アトミック性が保証されます) にします。

コンピュータ サイエンスでは、リソース競合とは、複数のエンティティがランダム アクセス メモリ、ディスク ストレージ、キャッシュ メモリ、内部バス、外部ネットワーク デバイスなどの共有リソースにアクセスしようとしたときに発生する競合を指します。

{{expand section|リソース競合

メモリはリソースとして扱うことができますが、メモリ管理は通常は別個に考えられます。主な理由は、メモリの割り当てと割り当て解除は、ファイル ハンドルなどの他のリソースの取得と解放よりもはるかに頻繁であるからです。外部システムによって管理されるメモリは、(内部) メモリ管理 (メモリであるため) とリソース管理 (外部システムによって管理されるため) の両方と類似しています。例としては、ネイティブ コードで管理され、Java から使用されるメモリ ( Java Native Interface経由) や、JavaScriptから使用されるドキュメント オブジェクト モデル(DOM)のオブジェクトが挙げられます。どちらの場合も、ランタイム環境(仮想マシン)のメモリ マネージャー(ガベージ コレクター) は外部メモリを管理できない (共有メモリ管理がない) ため、外部メモリはリソースとして扱われ、類似して管理されます。ただし、システム間の循環 (JavaScript が DOM を参照し、JavaScript を参照し返す) によって、管理が困難または不可能になることがあります。

プログラム内のリソース管理における重要な違いは、語彙管理と明示的管理です。つまり、スタック変数などの語彙スコープを持つリソースとして処理できるかどうか (有効期間は単一の語彙スコープに制限され、特定のスコープに入るときまたはスコープ内で取得され、実行がそのスコープを終了するときに解放されます)、または関数内で取得され、その後関数から返されたリソースなど、リソースを明示的に割り当てて解放する必要があるかどうか (そのリソースは取得関数の外部で解放する必要があります) です。語彙管理が適用可能な場合、関心の分離が適切に行われ、エラーが発生しにくくなります。

リソース管理の基本的なアプローチは、リソースを取得し、それを使用して何らかの処理を行い、それを解放して、次の形式のコードを生成することです (Python でファイルを開く場合を例に説明します)。

f  =  open (ファイル名) 
... 
f .close ( )

これは、介入...コードに早期終了 ( ) が含まれずreturn、言語に例外がなく、open成功することが保証されている場合は正しいです。ただし、戻り値または例外がある場合はリソース リークが発生し、失敗する可能性がある場合は取得されていないリソースが不正に解放されますopen。

さらに 2 つの根本的な問題があります。取得と解放のペアが隣接していない (解放コードは取得コードから離れた場所に記述する必要がある)、およびリソース管理がカプセル化されていない (プログラマーはこれらが常にペアになっていることを手動で確認する必要がある) ことです。これらを組み合わせると、取得と解放は明示的にペアにする必要があるものの、一緒に配置できないため、これらが正しくペアにならない可能性が高くなります。

リソース リークは、finally構文をサポートする言語 (Python など) では、本体をtry節に配置し、リリースをfinally節に配置することで解決できます。

f  =  open (ファイル名) 
try : 
    ... 
finally : 
    f .close ( )

これにより、本体内に return がある場合や例外がスローされた場合でも、正しい解放が保証されます。さらに、取得は 節の前に行われるため、コードtryが成功したfinally場合open(例外をスローせずに) のみ 節が実行され、"例外なし" は "成功" を意味すると想定されます (Python の場合と同様open)。 の形式を返すなどして、リソースの取得が例外をスローせずに失敗する可能性がある場合はnull、次のように解放前にチェックする必要があります。

f  =  open (ファイル名) 
try : 
    ... 
finally : 
    if  f : 
        f .close ( )

これにより、正しいリソース管理が保証されますが、隣接性やカプセル化は提供されません。多くの言語には、Python のステートメントのように、カプセル化を提供するメカニズムがありますwith。

 open (ファイル名) をfとして : ...
    

上記の技術（アンワインド保護（finally）と何らかの形のカプセル化）は、リソース管理に対する最も一般的なアプローチであり、C#、Common Lisp、Java、Python、Ruby、Scheme、Smalltalk ^[1]など、さまざまな形で見られます。これらは、1970年代後半にLispのNIL方言で登場しました（例外処理§ 歴史を参照）。実装には多くのバリエーションがあり、大幅に異なるアプローチもあります。

言語間でのリソース管理の最も一般的なアプローチは、アンワインド保護を使用することです。これは、実行がブロックの終わりを超えて実行されるか、ブロック内から戻るか、例外がスローされることによって、実行がスコープから出るときに呼び出されます。これはスタック管理リソースに対して機能し、C#、Common Lisp、Java、Python、Ruby、Scheme など、多くの言語で実装されています。このアプローチの主な問題は、解放コード (最も一般的にはfinally節内) が取得コードから非常に離れている可能性があること (隣接性がない)、および取得コードと解放コードを呼び出し元が常にペアにする必要があること (カプセル化がない) です。これらは、クロージャ/コールバック/コルーチンを使用する (Common Lisp、Ruby、Scheme) か、取得と解放の両方を処理するオブジェクトを使用して、制御がスコープに出入りするときにこれらのメソッドを呼び出す言語構成要素を追加することで (C# using、tryリソースのある Java、Python with)、機能的に解決できます。以下を参照してください。

代わりとなる、より命令的なアプローチは、直接的なスタイルで非同期コードを書くことです。つまり、リソースを取得し、次の行で遅延解放を行います。これは、スコープの終了時に呼び出されます。つまり、同期取得の後に非同期解放が続きます。これは、2000年に Andrei AlexandrescuとPetru MargineanによってC++でScopeGuardクラスとして最初に考案され、 ^[4] Joshua Lehrerによって改良され、^[5] Dではキーワード(ScopeGuardStatement)を介して直接言語サポートされており、 RAIIに加えて例外安全性scopeへの1つのアプローチです(下記参照)。 ^[6] Goにもステートメントとして含まれています。^[7]このアプローチにはカプセル化がありません。つまり、取得と解放を明示的に一致させる必要がありますが、リソースごとにオブジェクトを作成する必要はありません(コード的には、リソースの種類ごとにクラスを記述する必要はありません)。 defer

オブジェクト指向プログラミングでは、リソースは、ファイル記述子(またはより一般的なファイル ハンドル)を値とするフィールドfileを持つオブジェクトなど、それらを使用するオブジェクト内にカプセル化されます。これにより、オブジェクトのユーザーが行う必要なく、オブジェクトがリソースを使用および管理できるようになります。ただし、オブジェクトとリソースを関連付ける方法は多種多様です。

まず、所有権の問題があります。オブジェクトにはリソース がありますか?

• オブジェクトはリソースを所有できます(オブジェクトの構成、強力な「has a」関係を介して)。
• オブジェクトはリソースを表示できます(オブジェクト集約、弱い「has a」関係経由)。
• オブジェクトは、リソースを持つ他のオブジェクトと通信できます ( Association経由)。

リソースを持つオブジェクトは、オブジェクトの存続期間中のさまざまな時点で、さまざまな方法でリソースを取得および解放できます。これらはペアで発生しますが、実際には対称的に使用されないことがよくあります (以下を参照)。

• openまたはなどの (インスタンス) メソッドを介して、オブジェクトが有効な間に取得/解放しますdispose。
• オブジェクトの作成/破棄中に取得/解放します (初期化子と終了子内)。
• リソースを取得も解放もせず、代わりに依存性注入の場合のように、オブジェクトの外部で管理されるリソースへのビューまたは参照を持つだけです。具体的には、リソースを持つオブジェクト (またはリソースを持つオブジェクトと通信できるオブジェクト) が、メソッドまたはコンストラクターに引数として渡されます。

最も一般的なのは、オブジェクトの作成中にリソースを取得し、次に一般に と呼ばれるインスタンス メソッドを介して明示的に解放することです。 これは、従来のファイル管理 ( 中に取得し、明示的に によって解放)disposeに類似しており、 dispose パターンとして知られています。 これは、 Java、C#、Pythonなど、いくつかの主要な最新のオブジェクト指向言語で使用される基本的なアプローチであり、これらの言語には、リソース管理を自動化するための追加の構造があります。 ただし、これらの言語でも、以下で説明するように、オブジェクトの関係が複雑になると、リソース管理も複雑になります。 openclose

自然なアプローチは、リソースの保持をクラス不変にすることです。つまり、リソースは、オブジェクトの作成時 (具体的には初期化) に取得され、オブジェクトの破棄時 (具体的には終了処理) に解放されます。これは、リソース取得は初期化である(RAII) と呼ばれ、リソース管理をオブジェクトの有効期間に結び付けて、ライブ オブジェクトに必要なリソースがすべてあることを保証します。他のアプローチでは、リソースの保持をクラス不変にしないため、オブジェクトに必要なリソースがない可能性があります (まだ取得されていない、すでに解放されている、または外部で管理されているため)。その結果、閉じたファイルから読み取ろうとするなどのエラーが発生します。このアプローチでは、リソース管理がメモリ管理 (具体的にはオブジェクト管理) に結び付けられるため、メモリ リーク (オブジェクト リーク) がなければ、リソース リークはありません。RAII は、スタック管理リソースだけでなく、ヒープ管理リソースに対して自然に機能し、構成可能です。つまり、任意の複雑な関係 (複雑なオブジェクト グラフ)にあるオブジェクトによって保持されているリソースは、オブジェクトを破棄するだけで透過的に解放されます (これが適切に行われる限り)。

RAII は C++ の標準的なリソース管理アプローチですが、その魅力にもかかわらず、C++ 以外ではほとんど使用されていません。これは、最新の自動メモリ管理、特にガベージ コレクションのトレースとの相性が悪いためです。RAII はリソース管理とメモリ管理を結び付けますが、これらには大きな違いがあります。まず、リソースは高価なため、速やかに解放することが望ましいため、リソースを保持しているオブジェクトはガベージになった (使用されなくなった) らすぐに破棄する必要があります。オブジェクトの破棄は、C++ (スタックに割り当てられたオブジェクトはスタックの解放時に破棄され、ヒープに割り当てられたオブジェクトは を呼び出すdeleteか を自動的に使用して手動で破棄されるunique_ptr) などの決定論的なメモリ管理や、決定論的な参照カウント (参照カウントが 0 になるとオブジェクトが直ちに破棄される) では迅速に行われるため、RAII はこれらの状況でうまく機能します。ただし、最新の自動メモリ管理のほとんどは非決定論的であり、オブジェクトが速やかに破棄されること、または破棄されることがまったく保証されません。これは、各オブジェクトがガベージになったときに直ちに正確にコレクションするよりも、一部のガベージを割り当てたままにしておく方がコストがかからないためです。第二に、オブジェクトの破棄中にリソースを解放するということは、オブジェクトにファイナライザ(決定論的メモリ管理ではデストラクタと呼ばれる) が必要であることを意味します。つまり、オブジェクトを単純に割り当て解除することはできないため、ガベージ コレクションが大幅に複雑化し、速度が低下します。

複数のオブジェクトが単一のリソースに依存している場合、リソース管理は複雑になる可能性があります。

基本的な質問は、「持つ」関係が、別のオブジェクトを所有する関係（オブジェクトの構成）なのか、別のオブジェクトを表示する関係（オブジェクトの集約）なのかということです。一般的なケースは、パイプとフィルターパターン、委任パターン、デコレータ パターン、アダプタ パターンのように、2 つのオブジェクトが連鎖されている場合です。2 番目のオブジェクト（直接使用されない）がリソースを保持している場合、最初のオブジェクト（直接使用される）がそのリソースの管理を担当するのでしょうか。これは通常、最初のオブジェクトが2 番目のオブジェクトを所有しているかどうかと同じように答えられます。所有している場合、所有オブジェクトはリソース管理も担当します（「リソースを所有する」ことは推移的）。そうでない場合は推移的ではありません。さらに、1 つのオブジェクトが他の複数のオブジェクトを「所有」し、いくつかを所有して他のオブジェクトを表示する場合があります。

どちらのケースもよく見られますが、規則は異なります。間接的にリソースを使用するオブジェクトにリソースの責任を持たせる (構成) と、カプセル化が実現します (クライアントが使用するオブジェクトのみが必要で、リソース用の個別のオブジェクトは必要ありません)。ただし、特にリソースが複数のオブジェクトで共有されている場合や、オブジェクト間の関係が複雑な場合は、かなり複雑になります。リソースを直接使用するオブジェクトのみがリソースの責任を持つ場合 (集約)、リソースを使用する他のオブジェクト間の関係は無視できますが、カプセル化は行われません (直接使用するオブジェクト以外)。つまり、リソースは直接管理する必要があり、間接的に使用するオブジェクトでは利用できない可能性があります (個別にリリースされている場合)。

実装的には、オブジェクトの構成で、破棄パターンを使用する場合、所有オブジェクトにもdisposeメソッドがあり、そのメソッドは、dispose破棄する必要がある所有オブジェクトのメソッドを呼び出します。RAII では、これは自動的に処理されます (所有オブジェクト自体が自動的に破棄される限り: C++ では、それらが値または でありunique_ptr、生のポインターでない場合は: ポインター所有権を参照)。オブジェクト集約では、表示オブジェクトはリソースの責任を負わないため、表示オブジェクトによって何もする必要はありません。

どちらもよく見られます。たとえば、Java クラス ライブラリでは、Reader#close()は基になるストリームを閉じ、これらは連鎖することができます。たとえば、にはBufferedReaderが含まれ、その には が含まれており、 を呼び出すとが閉じ、その が を閉じ、システム ファイル リソースが解放されます。実際、カプセル化により、リソースを直接使用するオブジェクトは匿名にすることもできます。 InputStreamReaderFileInputStreamcloseBufferedReaderInputStreamReaderFileInputStream

try ( BufferedReader reader = new BufferedReader ( new InputStreamReader ( new FileInputStream ( fileName )))) { // reader を使用します。} // try-with-resources ブロックが終了すると reader が閉じられ、含まれている各オブジェクトが順番に閉じられます。        
    

ただし、リソースを直接使用するオブジェクトのみを管理し、ラッパー オブジェクトではリソース管理を使用しないこともできます。

try ( FileInputStream stream = new FileInputStream ( fileName )))) { BufferedReader reader = new BufferedReader ( new InputStreamReader ( stream )); // リーダーを使用します。} // try-with-resources ブロックが終了すると、ストリームは閉じられます。// ストリームが閉じられた後はリーダーは使用できなくなりますが、ブロックを脱出しない限り、これは問題ではありません。      
         
    

対照的に、Pythonでは、csv.readerは読み込んでいる を所有していないfileため、リーダーを閉じる必要はなく（閉じることはできません）、代わりにfile自体を閉じる必要があります。^[8]

with  open ( filename )  as  f : 
    r  =  csv . reader ( f ) 
    # r を使用します。
# with 文が終了すると f は閉じられ、使用できなくなります。
# r に対しては何も行われませんが、基になる f は閉じられているため、r も使用できません。

.NETでは、リソースの直接のユーザーのみが責任を負うという慣例があります。「型がアンマネージリソースを直接使用する場合にのみ、IDisposableを実装する必要があります。」^[9]

複数のオブジェクトがリソースを共有したり、リソースを保持するオブジェクト間で循環が発生したりするなど、より複雑なオブジェクト グラフの場合、適切なリソース管理は非常に複雑になる可能性があり、オブジェクトのファイナライズ (デストラクタまたはファイナライザ経由) とまったく同じ問題が発生します。たとえば、オブザーバー パターン(およびオブザーバーがリソースを保持) を使用している場合、リスナーの失効問題が発生してリソース リークが発生する可能性が あります。リソース管理をより細かく制御できるようにするためのさまざまなメカニズムが存在します。たとえば、Google Closure Libraryでは、クラスは、このオブジェクトと一緒に破棄される他のオブジェクトを登録するメソッドと、破棄を管理するためのさまざまな低レベルのインスタンス メソッドおよびクラス メソッドを 提供します。goog.DisposableregisterDisposable

構造化プログラミングでは、スタックリソース管理は、すべてのケースを処理できるほど十分にコードをネストするだけで行われます。これには、コードの最後に1つの戻り値のみが必要であり、多くのリソースを取得する必要がある場合は、コードが重くネストされる可能性があります。これは、連続したネストによる三角形の形状のため、 一部の人によってアンチパターン（矢印アンチパターン）と見なされています^{[10] 。}

早期復帰を許可しながらクリーンアップを 1 か所に統合​​するもう 1 つの方法は、クリーンアップ コードを先行させた関数の単一の終了戻り値を用意し、終了前にgoto を使用してクリーンアップにジャンプすることです。これは最近のコードではあまり見られませんが、C の一部の用途では発生します。

• メモリ管理
• プール（コンピュータサイエンス）

• DG アップデート: 廃棄、ファイナライズ、リソース管理、ジョー・ダフィー

• 決定論的リソース管理、WikiWikiWeb