Статические методы .Net и его влияние на параллелизм?

Question

Я сейчас создаю API, который будет использоваться веб-сервисом.

Мне было интересно, с какими проблемами производительности я мог бы столкнуться, если бы я построил свой API, используя большое количество статических методов .

Первоначальной идеей было создание экспертных объектов, которые действуют как сервисы.

В однопользовательской среде этот подход был великолепен! Но скоро мне нужно будет перенести это в многопользовательскую среду.

С какими проблемами производительности я могу столкнуться с такой архитектурой?

С уважением,

Edit:

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

Answer 1

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

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

Answer 2

Вам не нужно беспокоиться о локальных переменных в статическом методе. Каждый поток имеет свой собственный стек, и каждый вызов метода создаст отдельную копию локальной переменной в стеке. Например, методы SqlHelper, которые MS предоставляет в своих прикладных блоках, используют именно эту технику.

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

Answer 3

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

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

Вы должны уменьшить количество точек, в которых общие данные хранятся среди потоков, до абсолютного минимума. Это уменьшает вероятность проблем с многопоточностью. Вероятно, вы потеряете немного эффективности в этом, но вы значительно выиграете в простоте кодирования и обслуживания. Представьте, как трудно было бы написать и протестировать приложение ASP.NET, если бы все страницы были статичными. Это был бы кошмар. Возможно, вы поймете, что идете по этому пути, поскольку ваш API со временем приобретает новые функции.

Кроме того, используйте достойную структуру DI (я думаю, Unity, может быть, лучшая вещь из P & P).