|
|
Рекомендации по организации поточной обработки
Цикл статей
Рекомендации по организации поточной обработки
Далее приведены основные рекомендации по организации поточной обработки:
- Избегайте использования статических методов, которые изменяют статическое состояние. В обычных серверных сценариях статическое состояние используется совместно через запросы, это означает, что этот код одновременно могут выполнять множество потоков. Это делает возможными сбои в организации поточной обработки. Рассмотрите использование схемы разработки, при которой данные инкапсулируются в экземпляры, которые не используются совместно через запросы.
- Статическое состояние должно быть потокобезопасным.
- Состояние экземпляра не нуждается в потокобезопасности. По умолчанию библиотека не является потокобезопасной. Добавление блокировок для создания потокобезопасного кода снижает производительность, увеличивает конфликты между блокировками и создает условия для возникновения зависаний. В обычных моделях приложений только один поток выполняет пользовательский код в единицу времени. Это минимизирует потребность в потокобезопасности. Поэтому .NET Framework непотокобезопасна по умолчанию. Если вы хотите обеспечить потокобезопасную версию, используйте метод GetSynchronized, чтобы вернуть потокобезопасный экземпляр типа. В качестве примера рассмотрите пространство имен System.Collections.
- Разрабатывайте библиотеку классов с учетом пиковых нагрузок в серверном сценарии. По возможности избегайте применения блокировок.
- Осмыслите, как осуществляются вызовы методов в блокированных секциях. Когда статический метод в классе А вызывает статический метод класса В и наоборот, могут возникать зависания. Если классы А и В синхронизируют свои статические методы, это приведет к зависанию. Вы сможете обнаружить это зависание только во время пиковых нагрузок.
Проблемы с производительностью могут возникнуть, когда статический метод в классе А вызывает статический метод класса А. Если эти методы неправильно спроектированы, страдает производительность, потому что будет большое количество избыточной синхронизации. Чрезмерное использование синхронизации может иметь негативное воздействие на производительность. Кроме того, это может иметь существенное отрицательное влияние на масштабируемость.
Имейте ввиду проблемы с оператором lock (SyncLock в Visual Basic). Довольно заманчиво использовать оператор lock для решения всех проблем с организацией поточной обработки. При проверке кода вы должны остерегаться таких экземпляров, как тот, который показан в следующем примере. [C#] lock(this) { myField++; }
Для увеличения производительности, необходимо заменить этот код System.Threading.Interlocked.Increment(myField);
То же косается и следующего примера. Вместо этого кода: [C#] if (x == null) { lock (this) { if (x == null) { x = y; } } } Следует использовать такую запись: System.Threading.Interlocked.CompareExchange(ref x, y, null);
- Избегайте по возможности необходимости синхронизации.
|