Удаленное время жизни для статических объектов в домене приложения с активированными объектами клиента

Question

Мне интересно узнать время жизни общих / статических объектов в AppDomain, где RemotingCalls являются причиной создания общих объектов.

Мы используем настройку Remoting, которая использует объекты, активированные клиентом, для которых мы используем только функции для доступа к серверу. Удаленные объекты настроены как синглтоны.

Сервер устанавливает канал и использует RemotingConfiguration.Configure для загрузки файла конфигурации.

Некоторые из этих серверных функций касаются и используют некоторые статические (совместно используемые в vb.net) переменные на сервере. Я не могу узнать, каково время жизни этих статических переменных, они создаются (запускается статический конструктор), когда к ним обращаются в первый раз. При ведении журнала я не вижу, чтобы объекты удалялись / завершались.

Ожидание в течение пары минут после подключения к серверу удаленного взаимодействия обнаруживает, что общие объекты живы и здоровы.

Вопрос:

Итак, каково ожидаемое время жизни статических объектов в этой настройке удаленного взаимодействия. Они живут так долго, как AppDomain, или они отключаются, когда объекты Remoting меняются местами. И как правильно продлить срок их службы при необходимости?

Ответ:

Статические типы живут в AppDomain, так как они обращались в первый раз, пока AppDomain не был выгружен. Поэтому вам не нужно продлевать срок их службы до тех пор, пока запущен AppDomain.

Answer 1

Удаленные объекты не собираются для мусора до истечения срока аренды - аренда защищает их от GC, так как на них нет явной видимой ссылки.Период аренды по умолчанию составляет 5 минут, сборщик мусора может работать через пару минут (в зависимости от загрузки, использования памяти и т. Д.), А затем последняя ссылка на ваш объект должна быть удалена.Только после того, как все это произошло, экземпляр объекта должен быть собран при следующем запуске GC.Однако статические объекты вообще не будут собираться мусором .

Что касается второй части вопроса, то правильный способ продления срока службы называется "спонсорством" - в основном, когдаСрок аренды истекает, сервер спрашивает клиентов, желает ли кто-либо продолжать использовать этот объект.Есть довольно подробная статья на эту тему здесь .Не просто установите время жизни в бесконечность.

Answer 2

Статические поля никогда не собираются мусором.Взгляните на статью Джеффри Рихтера .
Статические поля рассматриваются сборщиком мусора как корень, поэтому сборщик мусора всегда будет предполагать, что используются статические поля.

Статические поля инициализируютсякогда тип владельца загружен.JIT-компилятор загружает тип, когда ему нужно построить метод, и видит ссылку на этот тип.После загрузки тип остается там в течение всего срока службы AppDomain, поэтому все, на что ссылаются поля, принадлежащие типу (статические поля), будет считаться используемыми ссылками и не будет собирать мусор.

Кроме того, в отношении этогоутверждение:

Я не могу выяснить, каково время жизни этих статических переменных, они создаются (запускается статический конструктор), когда к ним обращаются в первый раз.

Технически статические переменные не обязательно "трогаются" в первый раз в статическом конструкторе.Рассмотрим класс следующим образом:

public static class Test
{
    private static MyType myType;

    static Test()
    {
        myType = new MyType();
    }
}

Статический конструктор (конструктор типов) никогда не будет вызываться, если у вас нет кода, который выполняет и ссылается на этот тип, например var x = Test.myType;.Что ж, это, вероятно, зависит от того, что именно означает «затронут».

Ответ:

Статические типы живут в AppDomain, так как они обращались в первый раз, пока AppDomain не был выгружен.Поэтому вам не нужно продлевать срок их службы до тех пор, пока запущен AppDomain.