Co to jest AppDomain?


118

Co to jest AppDomain? Jakie są zalety AppDomains lub dlaczego firma Microsoft wprowadziła pojęcie AppDomains, jaki był problem bez AppDomains?

Proszę opracować.

+4

http://stackoverflow.com/questions/665668/usage-of-appdomain-in-c- Co ciekawe, odpowiedzi udzielili ci sami faceci! 17 mar. 102010-03-17 22:04:18

  0

Dodatkowa uwaga, klasa ApplicationManager znajduje się na szczycie WSZYSTKICH działających aplikacji AppDomains. 08 sty. 112011-01-08 18:14:35

  0

http://stackoverflow.com/a/41410172/993672 odpowiedział tutaj 01 sty. 172017-01-01 15:28:43

104

An AppDomain zapewnia warstwę izolacji w procesie. Wszystko, co zwykle postrzegasz jako "za program" (zmienne statyczne itp.) Jest w rzeczywistości przyporządkowane do poszczególnych domen. Jest to przydatne dla:

  • plugins (można wyładować się AppDomain, ale nie zespół wAppDomain)
  • bezpieczeństwa (można uruchomić zestaw kodu z poszczególnych poziomów zaufania)
  • izolacji (można uruchomić różne wersje zespołów itp)

ból to trzeba użyć usług zdalnych itp

See MSDN dla partii więcej informacji. Szczerze mówiąc, nie jest to coś, z czym często trzeba się bić.

+11

Jedna mała (ale ważna) rzecz, o której należy wspomnieć: AppDomains nie obejmują wątków. 22 lut. 092009-02-22 13:04:38

  0

@ RüdigerStevens co masz na myśli? 30 wrz. 152015-09-30 11:53:03

+5

@AgentFire: Jeśli jakiś kod działa w jakimś wątku i jakiś kod wywołań AppDomain z innego AppDomain, wątek "przecina" granicę AppDomain i uruchamia kod z tego innego AppDomain. Wątki nie należą do konkretnych AppDomains ... chociaż można powiedzieć, że wątek "należy" do domeny, z której pochodzi kod, z którego został utworzony. Ale wątek może uruchamiać kod z dowolnego elementu AppDomain. 02 paź. 152015-10-02 16:04:46

  0

@ RüdigerStevens to naprawdę przewaga. 02 paź. 152015-10-02 18:37:20

+2

Jak zauważył @Marc, myślenie o AppDomain jako dodatkowej Warstwie izolacji jest dobrym pomysłem. Chciałbym umieścić to w kontekście: [Process> CLR> AppDomain> Assembly with statics> Thread with stack]. Oznacza to, że proces obsługuje środowisko wykonawcze Common Language Runtime (CLR). Środowisko CLR ma jedną lub więcej domen aplikacji. Każda AppDomain ładuje jeden lub więcej złożeń. Każdy zespół ma własne statyczne wartości zmiennych i jeden lub więcej wątków. Każdy wątek ma własny stos. 05 lip. 162016-07-05 23:31:06

  0

Myślę, że byłby to wyciek abstrakcji, gdyby wątki nie były tak agnostyczne w kontekście. także, jeśli spojrzysz na wątek jako na jakąś maszynę podróżującą przez kontrolny przepływ, seryjnie wykonując polecenia wzdłuż linii, zobaczysz, że nie obchodzi go, gdzie ten łańcuch poleceń poprowadzi go, czy to ta sama domena, w której się rozpoczął, czy też inne. wszystkie polecenia wyglądają podobnie i są traktowane podobnie, gdziekolwiek się znajdują "fizycznie". pojęcie pochodzenia polecenia jest ortogonalne do tego, co nić robi i robi w swoim jednowymiarowym świecie. heh. 01 sie. 172017-08-01 06:46:59


31

AppDomains można postrzegać jako procesy lekkie. Mają wiele takich samych cech procesu, np. mają własne kopie statyki, złożeń itd., ale są zawarte w jednym procesie. Z punktu widzenia systemu operacyjnego proces jest po prostu procesem, bez względu na to, ile AppDomains może zawierać.

Jednak w przeciwieństwie do procesu, AppDomain nie ma żadnych wątków, chyba że je jawnie utworzysz. Wątek może uruchamiać kod w dowolnym AppDomain.

AppDomains są częścią tego samego procesu i tym samym faktycznie udostępniają tę samą zarządzaną stertę. Zwykle nie stanowi to problemu, ponieważ model programowania aplikacji AppDomain uniemożliwia niejawny dostęp między domenami aplikacji. Jednak niektóre odwołania są faktycznie udostępniane między domenami aplikacji, takimi jak obiekty typu i internowane ciągi.

  0

Tylko jedna uwaga. Internowane ciągi nie wydają się być udostępniane w różnych AppDomains 16 gru. 142014-12-16 08:40:57


41

Domena aplikacji implementuje koncepcję ciągłej przestrzeni pamięci wirtualnej, która przechowuje kod i zasoby w pamięci, do których można bezpośrednio uzyskiwać dostęp lub się do nich odwoływać.

Oddzielne domeny AppDomains nie współużytkują pamięci i dlatego jedna AppDomena nie może bezpośrednio odnosić się do zawartości w innej. W szczególności dane muszą być przesyłane między domenami aplikacji za pomocą procesu kopiowania według wartości. W szczególności obiekty referencyjne, które bazują na wskaźnikach, a tym samym adresach pamięci, muszą najpierw zostać przekształcone do postaci szeregowej ze źródła, a następnie przekształcone do postaci docelowej AppDomain.

Poprzednio w systemach Windows granice pamięci były implementowane przez procesy; jednak konstruowanie procesów wymaga dużej ilości zasobów. Służą również podwójnemu celowi jako granice wątków. Z drugiej strony domeny aplikacji dotyczą tylko granicy pamięci lub przestrzeni adresowej. Wątki mogą przepływać między domenami aplikacji (to znaczy, procedura może wywoływać punkt wejścia w innym AppDomain i czekać na jego powrót. Wątek ma wykonywać dalej wykonywanie w ramach innej domeny aplikacji).

Jedną z istotnych zalet tej architektury jest to, że wzorce komunikacyjne między domenami aplikacji pozostają zasadniczo niezmienione, niezależnie od tego, czy AppDomains są w tym samym procesie, w różnych procesach, czy też na różnych komputerach łącznie: proces serializacji i deserializacji (marsze) parametrów danych.

Uwaga 1: znaczenie wątku przekraczającego AppDomain to połączenie blokujące lub synchroniczne wywołanie do innej AppDomain (w przeciwieństwie do połączenia nie blokującego lub asynchronicznego, które spowodowałoby odrodzenie się innego wątku, aby kontynuować wykonywanie w docelowej domenie AppDomain i kontynuować w aktualnym AppDomain bez oczekiwania na odpowiedź).

Uwaga 2: istnieje coś takiego jak Lokalna pamięć wątków. Jednak lepszą nazwą byłoby lokalne przechowywanie wątków aplikacji, ponieważ wątki zostawiają swoje dane za sobą, gdy przekraczają App-Domeny, ale odbierają je z powrotem po powrocie: http://msdn.microsoft.com/en-us/library/6sby1byh.aspx

Uwaga 3: Środowisko wykonawcze .Net to proces systemu Windows aplikacja z powiązaną stertą. Może hostować jedną lub więcej domen aplikacji w tej stercie. Jednak AppDomains są zaprojektowane tak, aby wzajemnie się niepomnywać i komunikować się ze sobą poprzez nawiązywanie połączeń. Można sobie wyobrazić, że można przeprowadzić optymalizację, która omija kwantowanie między komunikowaniem się aplikacji AppDomains współużytkujących to samo środowisko wykonawcze .Net i tym samym stertę procesu systemu Windows.

  0

Cóż, byłem trochę zdezorientowany między twoimi wypowiedziami ** Oddzielne AppDomains nie współużytkują pamięci ** i @Brian Rasmussen ** AppDomains są częścią tego samego procesu, a więc w rzeczywistości udostępniają ta sama sterowana kupa **. Czy możesz trochę wyjaśnić? 18 sie. 162016-08-18 02:39:12

  0

Gdy AppDomains są częścią tego samego samego procesu systemu Windows (a zatem znajdują się w tej samej instancji środowiska wykonawczego .NET), muszą znajdować się w tym samym sterowanym stadzie wspomnianego procesu systemu Windows; jednak ta okoliczność będzie zwykle niewidoczna dla aplikacji .Net. Pamiętaj, że aplikacja .Net nie jest aplikacją Windows Process i faktycznie działa na jakiejś maszynie wirtualnej. 18 sie. 162016-08-18 07:19:05