Почему List ‹T› не является потокобезопасным?

Вам действительно нужно классифицировать Java Vector по типу потоковой безопасности. Javas Vector безопасно использовать из нескольких потоков, потому что он использует синхронизацию методов. Состояние не будет испорчено.

Однако полезность вектора Java ограничена несколькими потоками без дополнительной синхронизации. Например, рассмотрим простой акт чтения элемента из вектора.

Vector vector = getVector();
if ( vector.size() > 0 ) { 
  object first = vector.get(0);
}

Этот метод не повредит состояние вектора, но он также неверен. Ничто не мешает другому потоку изменить вектор между оператором if и вызовом get (). Этот код может и будет в конечном итоге завершиться ошибкой из-за состояния гонки.

Этот тип синхронизации полезен только в небольшом количестве сценариев и, конечно, стоит недешево. Вы платите заметную цену за синхронизацию, даже если вы не используете несколько потоков.

.Net предпочла не платить эту цену по умолчанию из-за сценария, имеющего лишь ограниченную полезность. Вместо этого он решил реализовать список без блокировок. Авторы несут ответственность за добавление любой синхронизации. Это ближе к модели C ++: «платите только за то, что используете».

Недавно я написал пару статей об опасностях использования коллекций только с внутренней синхронизацией, таких как вектор Java.

• Почему потоки безопасные коллекции так сложно?
• Более удобный API для изменяемая потокобезопасная коллекция

Справочник по безопасности потоков вектора: http://www.ibm.com/developerworks/java/library/j-jtp09263.html

Почему это будет потокобезопасным? Не каждый класс. Фактически, по умолчанию классы не потокобезопасны.

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

Это просто дизайнерское решение реализовать типы, не ориентированные на многопотоковое исполнение. Коллекции предоставляют свойство SyncRoot интерфейса ICollection и метод Synchronized() для некоторых коллекций для явной синхронизации типов данных.

Используйте SyncRoot, чтобы заблокировать объект в многопоточных средах.

lock (collection.SyncRoot)
{
   DoSomething(collection);
}

Используйте collection.Synchronized(), чтобы получить потокобезопасную оболочку для коллекции.

Возможность состояния гонки, о которой упоминает JaredPar, является пугающим следствием предполагаемой потоковой безопасности Vector. Такие вещи приводят к тому, что «каждый девятый вторник приложение делает что-то странное» - отчет о дефектах, который сводит вас с ума.

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

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

Для истинной безопасности потоков List<> и другие типы коллекций должны быть неизменными. С появлением параллельных расширений .NET в .NET 4.0 мы увидим поточно-ориентированные версии наиболее часто используемых коллекций. Джон Скит затрагивает некоторые из этих вопросов.

используйте SynchronizedCollection, он также предоставляет параметр-конструктор для использования общей синхронизации :)