Поле ThreadStatic VS параметр метода VS один экземпляр на поток

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

private void MySubmethod(MyConfiguration configuration)

Теперь я думал о редизайне типа и создании одного экземпляра для каждого работающего потока, но потом я наткнулся на атрибут ThreadStatic.

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

[ThreadStatic]
private static MyConfiguration _configuration;

1 ответ

Решение

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

Нет; это означает, что любой код, касающийся потоков, теперь крайне ненадежен; и с такими вещами, как ThreadPoolТЛП и async/awaitпотоки неизбежны в современных приложениях (даже если они неявные, а не явные в вашем коде). Переменные, которые зависят от потока, также чрезвычайно проблематичны для отладки. Если нет очень веских причин, мой совет - сохранить общий контекст или подключиться к существующей надежной реализации. Например, в веб-приложении вы могли бы разумно получить доступ к текущему запросу через статические методы - но даже при этом вы должны быть осторожны, чтобы знать, находитесь ли вы в потоке запросов, а не в рабочем потоке, который должен был иметь все необходимое для знать передал ему на тарелку.

Другие вопросы по тегам