Блокировка статического объекта внутри статического свойства в HTTPModule - PullRequest
1 голос
/ 25 декабря 2010

У нас есть пользовательская DLL, реализованная IHttpModule для обработки httpApplication_EndRequest, что я хочу знать, это

В DLL есть класс (не статический класс), который имеет статическое свойство и используется для создания экземпляра статической переменной / ссылки на объект, определенной внутри класса.

Теперь мне нужно заблокировать статическое свойство перед созданием экземпляра для статического объекта / переменной?

Например: -

public class SPEnvironment : IEnvironment
{
    private static SPEnvironment _instance;
    private static object _syncRoot = new object();

    private SPEnvironment()
    {
        try {
        .....
        }
        finally {
        ......
        }
    }

    public static SPEnvironment Instance
    {
        get
        {
            if (_instance == null)
            {
                lock (_syncRoot)
                {
                    if (_instance == null)
                    {
                        _instance = new SPEnvironment();
                    }
                }
            }
            return _instance;
        }
    }
}

Я буду вызывать это из другого класса, как показано ниже

SPEnvironment.Instance;

Это правильный путь? или замок надо снять?

1 Ответ

3 голосов
/ 26 декабря 2010

Двойная нулевая проверка с блокировкой посередине - хороший, потокобезопасный способ создания экземпляра синглтона. Однако вы можете сэкономить много кода, просто сказав

public class SPEnvironment : IEnvironment
{
    public static SPEnvironment Instance = new SPEnvironment();

    private SPEnvironment()
    {
        try {
        .....
        }
        finally {
        ......
        }
    }
}

Разница между ними состоит в том, что этот код создает экземпляр singleton при первом создании объекта этого типа, когда ваш код создает экземпляр singleton при первом обращении к SPEnvironment.Instance. Почти во всех случаях это одно и то же; в большинстве оставшихся случаев это не имеет значения; но это тонкое различие, которое стоит понять в этом очень редком случае.

...