Утилизирует ли дочерняя область .NET Core IServiceScopeFactory временные службы?
Всякий раз, когда мне нужны временные или ограниченные службы внутри одиночной или фоновой службы, я создаю их в дочерней области:
using var serviceScope = _serviceScopeFactory.CreateScope();
var foo = serviceScope.ServiceProvider.GetRequiredService<Foo>();
Однако я только что заметил, что в документации API для CreateScope указано:
Возврат: IServiceScope, управляющий временем существования области. После этого все службы с заданной областью, которые были разрешены из IServiceScope.ServiceProvider, также будут удалены.
Обратите внимание на формулировку «любые службы».
Означает ли это, что контейнер с заданной областью не располагает временными службами (только службами с заданной областью)? Я всегда думал, что дочерний контейнер уничтожает все, что он создает, и только корневой контейнер удерживает временные ссылки.
(Я привык к Autofac, и некоторые нюансы между ним и .NET DI немного сбивают с толку.)
@Damien_The_Unbeliever Спасибо. Получается, что временный процесс, разрешенный из дочернего контейнера, никогда не будет удален и со временем приведет к утечке памяти?
Так и будет, но это означает, что ваш сервис никогда не сможет использоваться в качестве зависимости от корневого сервиса. Поведение описано в документации, где говорится by default the DI container will hold onto these references, and not Dispose() of them until ... or until the scope is disposed if they were resolved from a scope.. Вместо того, чтобы предполагать, как все настроено, почему бы не сделать сервис ограниченным?
Если ваша служба Y разрешена из корня, временный Z останется активным на время работы приложения. Документы предупреждают об этом несколько раз. Если ваша служба сама по себе является зависимостью корневой службы X, вы получите утечки Z. Если это зависимость только от служб с ограниченной областью действия, вы этого не сделаете.
В чем на самом деле проблема? Судя по фразе child container вместо scope, я подозреваю, что вы пытаетесь имитировать поведение другой DI-библиотеки. Возможно, вы уже зарегистрировали эту другую библиотеку в качестве фактического поставщика DI и задаетесь вопросом, как будет вести себя остальная часть инфраструктуры DI?
@PanagiotisKanavos Спасибо. Я видел эти документы, но все еще не уверен. Позвольте мне сделать это более конкретным: служба является (одноэлементной) фоновой службой, которая имеет (переходную) зависимость, которую она разрешает косвенно через дочернюю область IServiceScopeFactory (как в приведенном выше коде). Это приведет к утечке памяти?
Это ничем не отличается от исходного вопроса, и документы уже отвечают на него. По умолчанию нет. Но значение по умолчанию может измениться, например, если вы используете другую библиотеку контейнеров с другой семантикой. В любом случае, если вы когда-нибудь попытаетесь использовать Foo в другом сервисе, вы должны быть абсолютно уверены, что это сервис с ограниченной областью действия, иначе произойдет утечка. Если приложение большое, вы можете легко забыть, что есть что, например, в пятницу в 16:50. Лучше сделать вещи явными
Я только что провел быстрый тест, и временная служба, реализующая IDisposable, разрешенную в пределах области, удаляется, когда эта область удаляется.
Спасибо @SirRufo. Я так думал, но не был уверен. Я думаю, что документация по API, показанная выше, плохо сформулирована.
@Ionix Я тоже не был, поэтому я сделал этот небольшой тест
Я добавил запрос на обновление документации в репозиторий.
Ответы 1
Формулировка в этой части документации не совсем правильна, по крайней мере, для контейнера DI по умолчанию: когда область действия удаляется, она удаляет все зависимости, которые принадлежат/контролируются/создаются самой областью действия. Проверить это довольно легко:
var services = new ServiceCollection();
services.AddTransient<MyDisposable>();
MyDisposable disposable;
using(var scope = services.BuildServiceProvider().CreateScope())
{
disposable = scope.ServiceProvider.GetRequiredService<MyDisposable>();
}
Console.WriteLine(disposable.Disposed); // true
class MyDisposable : IDisposable
{
public bool Disposed { get; private set; }
public void Dispose()
{
Disposed = true;
}
}
Когда вы регистрируете службы Transient, реализующие IDisposable, по умолчанию контейнер DI будет хранить эти ссылки, а не Dispose() до тех пор, пока контейнер не будет удален при остановке приложения, если они были разрешены из контейнера, или до тех пор, пока область не будет удалена, если они были решены из области действия
Спасибо! Я так и думал, но формулировка мне не была ясна. Насколько я понимаю, все, созданное дочерней областью, удаляется из этой дочерней области.
Документы *.Abstractions ничего не могут сказать о крайних случаях. Можно использовать разные библиотеки DI (например, Autofac), и поведение пространства имен *.Abstractions применимо ко всем из них. В библиотеке DI может даже не быть концепции scope, а дочерние контейнеры не являются областями действия — например, вы не можете регистрировать сервисы в областях видимости.
@PanagiotisKanavos справедливая точка зрения. Хотя, возможно, он ничего не может сказать и об области действия, но говорит (или, может быть, это требование для разработчиков) =)
Я добавил запрос на обновление документации в репозиторий.
В документации CreateScope говорится об области действия. Рекомендации по самому промежуточному программному обеспечению DI. Я подозреваю, что отчасти странности связаны с контейнерами Enterprise Library/Unity, которые были немного... переработаны, но их нужно было поддерживать, потому что они были собственными библиотеками Microsoft (в то время). Существуют жизненные циклы Transient и Container Transient, и фактически удаляется только Container Transient. Unity не будет удалять сервисы Transient, когда область действия закончится.
Одно продолжение, если можно... В тех же документах говорится: «Не регистрируйте экземпляры IDisposable с временным сроком службы. Вместо этого используйте фабричный шаблон». Я предполагаю, что это относится к случаю, когда временные службы будут разрешены из корневой области и, таким образом, останутся на протяжении всего срока службы приложения (посредством внедрения конструктора?). Но этот совет неприменим, если вы собираетесь решать проблему только из дочерней области (как вы это делали выше)?
@lonix - короче - да. Но на самом деле вы не можете помешать кому-либо разрешить временную службу из корневой области прямо или косвенно.
Руководство предполагает, что вам не следует с самого начала регистрировать
IDisposableкак временные.