Unity Container Memory Leaks

Привет, Я работаю над проектом, который использует контейнер Unity Консоли для разрешения зависимостей для обработки исключений, кеша, ведения журнала и доступа к db, но мы продолжаем получать много просочившихся объектов в память.Unity Container Memory Leaks

Мы используем инъекции свойство как это:

[Dependency] 
public Database DB 
{ 
    get { return db; } 
    set { db = value; } 
} 
[Dependency] 
public ExceptionManager ExceptionMgr 
{ 
    get { return exceptionManager; } 
    set { exceptionManager = value; } 
}

Некоторые из объекта просочилась:

Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Configuration.ExceptionHandlingSetti Microsoft.Practices.EnterpriseLibrary.Logging.Configuration .LoggingSettings
Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Configuration.ExceptionPolicyData
Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Co nfiguration.ReplaceHandlerData
Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Configuration.WrapHandlerData Microsoft.Practices.EnterpriseLibrary.Common.Configuration.GenericEnumeratorWrapper Microsoft.Practices.EnterpriseLibrary.Caching.Configuration.CacheManagerData Microsoft.Practices.EnterpriseLibrary.Caching.Configuration.CacheManagerSettings
Microsoft.Practices.EnterpriseLibrary.Caching.Configuration.CacheStorageData

Любые общие рекомендации по обработке зависимостей с Unity во избежание утечки объектов?

источник

2010-10-06 zad

Как вы подтверждаете утечку памяти? Можете ли вы опубликовать несколько статистических данных, которые показывают ваш профиль памяти до и после «утечки»? Одно дело отметить Unity в том, что по умолчанию объекты не удаляются из контейнера, пока сам контейнер не будет удален. Это поведение SingeltonLifetimeManager. Если вы хотите контролировать срок службы ваших объектов, вам придется предъявить иск другому менеджеру по жизни. –

Все объекты, которые вы перечисляете, являются частью системы конфигурации. Как вы инициализируете свой контейнер? Просто называя «AddNewExtension()?» Если это так, это не утечка, так как эти объекты представляют собой загруженную конфигурацию. Источник конфигурации (который является тем, что держится на этих объектах) остается на всю жизнь приложения, чтобы он мог следить за изменениями в вашем приложении и уведомлять вас об этом.

Какие инструменты вы используете, которые говорят вам, что они протекают? И растут ли утечки или постоянны? Некоторые детали помогут сузить поведение от «ожидаемого» до «критической ошибки».

Кроме того, это вопрос с корпоративной библиотекой, а не единство Единство - само единство не течет, о котором я знаю.

источник

2010-10-07 05:15:09

Итак, если я инициализирую контейнер несколько раз, объекты конфигурации для каждой инициализации останутся на всю жизнь приложения? – zad

Вы много помогли. – zad

В принципе да. Есть несколько трюков, которые вы можете использовать для смягчения этого. Например, создайте контейнер и инициализируйте Entlib в нем, а затем используйте дочерний контейнер для всего остального. Затем снимите и повторно инициализируйте дочерний контейнер. Это предотвратит перезагрузку содержимого конфигурации Entlib.Вы также можете попробовать явно создать объект ConfigurationSource, сконфигурировать контейнер с ним и затем утилизировать его после настройки контейнера. Не уверен, что это сработает или поможет. –

-3

Вы правильно распоряжаетесь экземпляром базы данных? Как, например, (используя db = new Database()) {....}?

источник

2010-10-06 23:32:47

База данных не является доступной. –

Это не подходит к корпоративной библиотеке. EL управляет зависимостями, такими как db для вас. Вы говорите, что хотите получить экземпляр своего класса, и он дает вам один с выполненной зависимостью. Когда вы распоряжаетесь своим классом, он имеет дело с расположением зависимостей. –

Unity Container Memory Leaks

ответ

Смежные вопросы