2010-03-25 25 views
2

Le problème est le suivant. Il y a une application qui est en train de créer des assemblages AppDomain supplémentaires et charge là (scripts utilisateur personnalisés). Dans l'application principale, il existe certains objets, références auxquels transférer la propriété à ceux créés AppDomain. Les objets eux-mêmes sont MarshalByRefObject et ils sont désactivés lifetimeservices (InitializeLifetimeService renvoie null).Interaction entre plusieurs AppDomain. Problèmes avec la destruction des objets singleton

Tout cela fonctionne. Cependant, ces AppDomains sont créés et détruits ... avec la destruction causée par Décharger le domaine, et les références aux objets créés - sont oubliées.

En général, à la suite de la mémoire se termine progressivement, parce que ces objets « oubliés » ne semblent pas libérés, mais ils ont aucun lien nulle part, et AppDomain, qui étaient des liens - a été déchargé longtemps ...

D'où la question - où le bug? Qu'est-ce qui ne va pas? Pourquoi ne pas exempter les installations après le déchargement du domaine? Personne ne pensait - pour prendre en compte leurs propres liens à ces objets pour chaque domaine chargé, et après son déchargé - cause pour chaque objet RemotingServices.Disconnect (...). Il se peut que vous ayez à faire lorsque le service à vie n'est pas disponible?

Répondre

1

je ferais les modifications suivantes:

Mettre en oeuvre IDisposable et iSponsor pour ces types. Remplacez la méthode InitializeLifetimeService de ces types et, au lieu de renvoyer null, faites de chaque instance son propre sponsor.

Ces types doivent retourner un TimeSpan positif de Renouvellement jusqu'à ce qu'ils soient éliminés. Assurez-vous juste d'en disposer avant de détruire le domaine.