Блог

Предположим, у меня есть статический вспомогательный класс, который я часто использую в веб-приложении. Предположим, что приложение получает около 20 запросов в секунду в течение длительного периода времени и что, как по волшебству, два запроса просят статический класс выполнить некоторую работу в одну и ту же наносекунду.

Что происходит, когда это происходит?

Чтобы обеспечить некоторый контекст, класс используется для выполнения запроса linq-to-sql: он получает несколько параметров, включая идентификатор пользователя, и возвращает список пользовательских объектов.

Спасибо.

Это полностью зависит от того, что означает ваша «некоторая работа». Если это не связано с каким-либо общим состоянием, все в порядке. Если для этого требуется доступ к общему состоянию, вам нужно решить, как справиться с этим потокобезопасным способом.

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

Что происходит, когда это происходит?

Если ваши методы являются реентерабельными, то они потокобезопасны, и что произойдет, так это то, что, скорее всего, они будут работать. Если эти статические методы полагаются на какое-то общее состояние, и вы не синхронизировали доступ к этому состоянию, скорее всего, это общее состояние будет повреждено. Но вам не нужно запускать метод в одну и ту же наносекунду на 20 запросов, чтобы повредить ваше общее состояние. 2 в значительной степени достаточно, если вы не синхронизируете его.

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

Обновить:

Поскольку в разделе комментариев вы упомянули LINQ-TO-SQL, пока все переменные, используемые в статическом методе, являются локальными, этот метод потокобезопасен. Например:

 public static SomeEntity GetEntity(int id)
{
    using (var db = new SomeDbContext())
    {
        return db.SomeEntities.FirstOrDefault(x => x.Id == id);
    }
}
  

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

Это зависит от того, имеет ли статический класс какое-либо состояние или нет (т. Е. Статические переменные, общие для всех вызовов). Если это не так, то все в порядке. Если это так, это нехорошо. Примеры:

 // Fine
static class Whatever
{
    public string DoSomething() {
        return "something";
    }
}

// Death from above
static class WhateverUnsafe
{
    static int count = 0;
    public int Count() {
        return   count;
    }
}
  

Вы можете заставить второй работать нормально, используя блокировки, но тогда вы вводите взаимоблокировки и проблемы с параллелизмом.

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

Он выходит из строя неприятным образом (если вы делаете это для совместного использования состояния), избегайте делать это в веб-приложении… Или альтернативно защитить чтение / запись блокировкой:

http://msdn.microsoft.com/en-us/library/system.threading.readerwriterlockslim.aspx

Но, честно говоря, вам действительно следует избегать использования статики, если только вам ДЕЙСТВИТЕЛЬНО не нужно, и если вам действительно нужно, вы должны быть очень осторожны со своей стратегией блокировки и проверить ее на уничтожение, чтобы убедиться, что вам удалось изолировать операции чтения и записи друг от друга