問題タブ [resource-management]

シンプルな ResourceManager を実装しました - (緊急) クリーンアップ (致命的な例外の場合など) のためにそのデストラクタを実装しようとするまでは、すべて問題ありませんでした。私はそれを行う単一の方法を見つけることができませんでした:

明らかに、すべてのアクティブなリソースを反復処理する必要があります...しかし、ResourceManager が技術的にリソースの (唯一の) 所有者ではない場合、どうすればそれらを解放できますか? これは設計上の欠陥である可能性があります。その場合は、代替案を提案してください。

編集：回答に応じて、「リソースマネージャー」を定義するために、権限のあるキャッシュを想像します-リソースを検索できるリソースへの参照用のストレージ（=重複なし）およびメモリ内の状態を管理します（メモリ内、説明のみ（=パス） +type) および freed) であり、上記のすべてが可能な限り自動化されています。(個別の ResourceLoaders が必要ですが、この質問ではあまり変わりません)

DataContexta のWindowを を実装するものに設定すると、が閉じられたときに d になりIDisposableますか?Dispose()Window

次のようなカスタムクラスがあります。

私のカスタムクラスのリストを持つ別のクラス：

メモリ内のすべての使用済みベクトル空間を解放するために、リスト デストラクタはどのようになりますか。

そのコードは正しいですか、冗長ですか、それとも間違っていますか?

助けてくれてありがとう...

マップの個々の領域が動的に生成されるか、既に生成されて保存されている場合はファイルからロードされるプロジェクトに取り組んでいます。リージョンは必要に応じてロード/生成され、不要になったときに保存および破棄されます。このマップの 1 つ以上の領域をさまざまな目的で使用するいくつかの異なるタスクがあります。たとえば、これらのタスクの 1 つは、現在表示されているすべての領域 (常に約 9 つ) を描画することです。もう 1 つは、リージョンに関する情報を取得したり、リージョンを変更したりすることです。問題は、これらのタスクが他のタスクと同じリージョンで機能する場合と機能しない場合があることです。

これらの領域はかなり大きく、生成にコストがかかるため、タスクごとに異なるコピーを使用するのは (これらの理由やその他の理由で) 問題があります。むしろ、現在ロードされているリージョンのプールを作成して管理するのが良い考えだと思います。新しいタスクは、最初に必要なリージョンのプールをチェックします。存在する場合はそれを使用するか、新しいものを作成してプールに追加します。

それが機能する場合、このプールをどのように管理しますか? 領域がどのタスクにも不要になり、安全に破棄できるかどうかを判断するにはどうすればよいですか? 私はばかげていて、これを過度に複雑にしていますか?

それが誰にとっても重要な場合、私はc＃を使用しています。

編集：私はもっと目覚めたので、使用されている場所ごとに各地域のカウンターをインクリメントするのと同じくらい簡単でしょうか? カウンターが0になったら捨てる？

cpuset を 1 コアに指定して、1 つの Docker コンテナーを開始しました。

cpuset を 4 コアに指定して 2 つ目:

各コンテナー内でロード プロセスを開始し、両方のコンテナーの CPU 消費量を監視しました。

ロード プロセスは次のようになります。

私は、両方のコンテナ間の実行時間に関して改善がないことを観察しました (スピードアップなし)。

改善されない理由がわかりませんか？4 コアのコンテナーは、1 コア コンテナーよりも高速に実行する必要があります。

注意: 1core コンテナーに top を使用する

4core コンテナーに top を使用すると、docker は 4 つのコアのいずれかをランダムに選択してプロセスを起動します。場合によってはコアごとに 30% 影響します

コードでエグゼキュータ サービスを使用していますが、使用されているスレッドの数は 100 を超えています。実行が完了すると、executor サービスで shutdown() メソッドが呼び出され、次に awaitTermination() が呼び出されます。

Java クラスは、Linux 端末からシェル スクリプトを使用して呼び出されます。Executor サービスが開始されているが完全にシャットダウンされていない状態で ctrl+C を押して実行を停止するとどうなるか知りたいです。

スレッドが強制終了され、メモリがクリーンアップされ、リソースが割り当て解除されるか、メモリ リークが発生しますか。

次のようなコード（簡略化）があります。

mustBeClosed が解放されることを保証する方法は?

これは、オブジェクト階層が複雑な場合に発生する可能性があります。B のファイナライズをオーバーライドすることは、完全な解決策ではない可能性があります。

この問題に対するベストプラクティスまたは原則はありますか?

改訂版は次のようになります。

ただし、これにはコードが多すぎて、洗練されたものとは言えません。さらに、所有権階層内のすべてのクラスが同じスタイルに従う必要があるように思われるため、大量のコードが生成されます。

何かアドバイス？

GCC 4.8.4 を使用して Ubuntu 14.04 を使用しており、次のようなコードがあります。

の署名MyFunctionは次のようになります。

完全なコードはここにあります

ただし、 my_object のコンテキスト内で実際には範囲外になることがわかっていますMyFunction。私の考えでは、は範囲外になった後、つまりが戻ったmy_shared_object後にのみコンテンツをリリースするというものでした。MyFunction私が誤解しているstd::shared_ptrのか、それとも GCC のバグなのかはわかりません。

質問は次のように要約できると思います: std::shared_ptr を逆参照すると、逆参照が使用されている限り、それが持続することが保証されますか?std::shared_ptr