•  01-07-2019
  •  | 
  •  

質問

インタビューで AppDomain についてよく質問されますが、 基本的なことは知っています:

  • これらはアプリケーション内の分離レベルです (アプリケーションとは異なります)。
  • スレッドを持つことができます (スレッドとは異なります)
  • あるアプリドメインの例外は別のアプリドメインに影響を与えません
  • appdomain は相互のメモリにアクセスできません
  • 各アプリドメインには異なるセキュリティを設定できます

何が必要なのかまだ分かりません。あなたがそれを使用する合理的な具体的な状況を探しています。

答え:

  • 信頼できないコード
    • コアアプリケーションの保護
      信頼できない/サードパーティのプラグインは、セキュリティ制限のある別のアプリドメインに隔離することで、共有メモリの破損やレジストリやハードドライブへの不正アクセスを禁止され、アプリケーションやサーバーを保護します。例えばASP.NET および SQL Server ホスティング コンポーネント コード
  • 信頼できるコード
    • 安定性
      安全で独立した機能に分割されたアプリケーション
    • アーキテクチャの柔軟性
      単一の CLR インスタンス内で複数のアプリケーションを実行したり、独自の各プログラムを自由に実行したりできます。

他に何か？

役に立ちましたか？

解決

おそらく最も一般的なのは、信頼できないパーティからのプラグイン コードを含むアセンブリを読み込むことです。コードは独自の AppDomain で実行され、アプリケーションを分離します。

また、特定のアセンブリをアンロードすることはできませんが、AppDomain をアンロードすることはできます。

完全な概要については、Chris Brumme がこれに関する大規模なブログ エントリを作成しました。

http://blogs.msdn.com/cbrumme/archive/2003/06/01/51466.aspx

https://devblogs.microsoft.com/cbrumme/appdomains-application-domains/

他のヒント

AppDomains のもう 1 つの利点は (質問で述べたように)、AppDomains にロードしたコードをさまざまなセキュリティ権限で実行できることです。たとえば、DLL を動的にロードするアプリを作成しました。私はインストラクターで、これらは私がロードしていた学生用の DLL でした。不満を抱いた学生にハード ドライブを消去されたり、レジストリが破損されたりしたくなかったので、ファイル IO 権限やレジストリ編集権限、さらには新しいウィンドウを表示する権限さえも持たない別の AppDomain にコードを DLL からロードしました。 (実際には実行権限しかありませんでした)。

AppDomain を導入する主な動機は、CLR 設計者が複数の Windows プロセスのパフォーマンスのオーバーヘッドを発生させずにマネージド コードを分離する方法を望んでいたことだと思います。CLR が元々 UNIX 上に実装されていた場合 (複数のプロセスの作成コストが大幅に低くなる場合)、AppDomain は決して発明されなかったかもしれません。

また、サードパーティ アプリのマネージド プラグイン アーキテクチャは間違いなく AppDomain の有効な利用法ですが、AppDomain が存在する大きな理由は、SQL Server 2005 や ASP.NET などのよく知られたホストのためです。たとえば、ASP.NET ホスティング プロバイダーは、単一の Windows プロセスで実行される同じボックス上で複数の顧客の複数のサイトをサポートする共有ホスティング ソリューションを提供できます。

アプリ ドメインは、アプリケーションの安定性に優れています。

アプリケーションを中央プロセスで構成し、個別のアプリドメインに「機能」を生成することで、そのうちの 1 つが不正に動作した場合の全体的なクラッシュを防ぐことができます。

サードパーティのプラグインを許可するアプリケーションを作成する場合は、それらのプラグインを別の AppDomain にロードして、メイン アプリケーションが未知のコードから安全になるようにすることができます。

また、ASP.NET は、単一のワーカー プロセス内の Web アプリケーションごとに個別の AppDomain を使用します。

私の理解では、AppDomain は、ホスティング エンティティ (OS、DB、サーバーなど) が単一の CLR インスタンス内で複数のアプリケーション、または独自の各プログラムを自由に実行できるように設計されています。したがって、これはアプリケーション開発者ではなくホストの問題です。

これは、アプリケーションごとに常に 1 つの JVM が存在する Java と比べて有利であり、多くの場合、JVM の多数のインスタンスが重複したリソースで並行して実行されることになります。

個別のアプリケーション ドメインを作成する主な使用例は 2 つまたは 3 つあります。

1) リソース使用量とオーバーヘッドが低いプロセスのような分離。たとえば、これが ASP.NET の機能です。ASP.NET は、各 Web サイトを個別のアプリケーション ドメインでホストします。単一のアプリケーション ドメインで異なるスレッドを使用すると、異なる Web サイトのコードが相互に干渉する可能性があります。異なるプロセスで異なる Web サイトをホストすると、多くのリソースが使用され、プロセス間通信はインプロセス通信に比べて比較的困難になります。

2) 特定のセキュリティ権限を持つ別のアプリケーション ドメインで信頼できないコードを実行する (これは実際には 1 番目の理由に関連します)。すでに述べたように、サードパーティのプラグインや信頼できない DLL を別のアプリケーション ドメインに読み込むことができます。

3) アセンブリをアンロードして、不必要なメモリ使用量を削減する機能。残念ながら、アプリケーション ドメインからアセンブリをアンロードする方法はありません。したがって、大きなアセンブリをメイン アプリケーション ドメインに読み込んだ場合、そのアセンブリが不要になった後に対応するメモリを解放する唯一の方法は、アプリケーションを閉じることです。アセンブリを別のアプリケーション ドメインに読み込み、それらのアセンブリが不要になったときにそのアプリケーション ドメインをアンロードすることが、この問題の解決策です。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top