Можно ли использовать статические объекты кодирования из нескольких потоков? [Дубликат]

Примером этого исключаемого исключения является: Когда вы пытаетесь проверить что-то, это null.

Например:

string testString = null; //Because it doesn't have a value (i.e. it's null; "Length" cannot do what it needs to do)

if (testString.Length == 0) // Throws a nullreferenceexception
{
    //Do something
} 

Время выполнения .NET исключение NullReferenceException при попытке выполнить действие над чем-то, что не было инстанцировано, т.е. код выше.

По сравнению с ArgumentNullException, которое обычно выбрано как защитная мера, если метод ожидает, что то, что происходит

Дополнительная информация находится в C # NullReferenceException и Null Parameter .

18
задан thaller 11 June 2010 в 17:12
поделиться

1 ответ

Да, должно быть безопасно использовать один и тот же объект Encoding, поскольку он предназначен для бездействия, тогда как Encoder и Decoder являются состояниями, сохранение неполных символов и т. д., если это необходимо. Я полагаю, вы могли бы написать класс с состоянием Encoding, но это была бы очень плохая идея. Насколько мне известно, все встроенные реализации кодирования являются безстоящими и потокобезопасными.

Например, свойства Encoding.UTF8, Encoding.ASCII и т. Д. Являются одиночными.

23
ответ дан Jon Skeet 28 August 2018 в 11:58
поделиться
  • 1
    Спасибо!! Я просто хотел быть уверенным, потому что не смог найти подтверждения в другом месте. – thaller 11 June 2010 в 17:36
  • 2
    @JonSkeet Документация явно исключает любые гарантии безопасности потока экземпляров Encoding: Any instance members are not guaranteed to be thread safe. И для Encoding, и для UTF8Encoding. Этот шаблон может быть вызван ленивым копированием и вставкой. Но я столкнулся с той же ситуацией, что и casperOne, и документация не заставляет меня чувствовать, что я создаю синглтон UTF8Encoding и использую его по потокам, хотя я согласен, что Encoding чувствуют себя без гражданства, хотя документы не являются явным образом об этом. – Eugene Beresovsky 31 July 2013 в 09:54
  • 3
    @EugeneBeresovksy: Не стесняйтесь создавать новый экземпляр для каждого потока, если вы действительно этого хотите, но я все еще уверен, что объекты Encoding фактически потокобезопасны (вернее, реализации .NET являются и если вы напишете свой собственный производный класс, я бы попросил вас сделать его потокобезопасным тоже.) – Jon Skeet 31 July 2013 в 09:58
  • 4
    @JonSkeet Согласен. В результате я разделил одноточечный код не-BOM-UTF8Encoding, хотя он означает использование текущей реализации, а не спецификации documentation =. В общем, это не самая безопасная вещь, но, как и в случае с моделью памяти, добавляется (в 3.0?), Чтобы не разорвать часто используемую двунаправленную блокировку идиомы - я думаю, что MS будет рисковать слишком много жалоб, если они сделают ее нитью - небезопасно в будущем. – Eugene Beresovsky 31 July 2013 в 10:35
  • 5
    @EugeneBeresovksy: Действительно. Есть все виды вещей, которые на самом деле не документированы. IIRC, порядок, в котором значения, полученные из List<T> через GetEnumerator, не документированы (или не были), но, очевидно, каждый полагается на это. , – Jon Skeet 31 July 2013 в 10:44
Другие вопросы по тегам:

Похожие вопросы: