Блог

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

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

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

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

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

Вопрос:

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

Ответ:

Статические типы сохраняются в AppDomain с момента первого доступа к ним до выгрузки AppDomain. Таким образом, вам не нужно продлевать их время жизни, пока работает AppDomain.

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

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

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

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

Кроме того, что касается этого заявления:

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

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

 public static class Test
{
    private static MyType myType;

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

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

Ответ:

Статические типы сохраняются в AppDomain с момента первого доступа к ним до выгрузки AppDomain. Таким образом, вам не нужно продлевать их время жизни, пока работает AppDomain.