Программирование к интерфейсам и синхронизировало наборы
Думайте о 2 типах тестирования и рассматривайте их по-другому - функциональное тестирование и тестирование производительности.
Использование различные исходные данные и метрики для каждого. Вы, возможно, должны использовать различное программное обеспечение для каждого типа теста.
4 ответа
1) Yes, it will be overkill
2) Correct, that should not be done
3) Зависит от ситуации.
Дело в том, как вы уже знаете, программирование интерфейса описывает то, что делает приложение (не то, как оно это делает, а реализация)
Синхронизация была удалена из последующих реализаций (помните, Vector и Hastable были до java 1.2, позже появились ArrayList и HasMap, которые не были синхронизированы, но все они реализовали интерфейс List и Map соответственно), потому что они приводят к снижению производительности из-за чрезмерной синхронизации. Например, если вы используете вектор в одном потоке, вы все равно получаете синхронизацию в этом одном потоке.
Совместное использование структуры данных между несколькими потоками - это то, что необходимо учитывать при разработке приложения. Там вы выберете методы, которые будете использовать, и вы Я выберу, кто отвечает за чистоту состояния данных.
Здесь вы выбираете между упомянутым вами вариантом 1 или 3. Была бы ручная синхронизация? Стоит ли использовать синхронизированный интерфейс? Какую версию мы будем поддерживать и т. Д. И т. Д.
Например, если вы выберете 1, вы также можете в своем проекте отклонить определенные реализации (например, вектор).
Синхронизация данных - это не то, что происходит по «удаче», вам действительно нужно проектируйте, чтобы это происходило правильно и не создавало больше проблем, чем решаемые им.
Во время этого проектирования вы должны обращать внимание на параметры (реализации) и / или базовую инфраструктуру, которую вы будете использовать.
Самый простой способ избежать чрезмерной синхронизации - использовать неизменяемые данные и не передавать свои данные другим потокам.
Нечто очень похожее на первый закон распределения вычислений Мартина Фаулера:
«Таким образом, мы переходим к моему Первому закону распределенного дизайна объектов: не распространяйте свои объекты».
Будет ли первый закон распределения многопоточными приложениями являются:
Первый закон многопоточных приложений: не делитесь своими данными?
:)
Последнее замечание: класс Collections предоставляет «синхронизированную» версию некоторых интерфейсов:
Синхронизированный список
Синхронизированная карта
Синхронизированный набор
Вы боретесь с тем фактом, что в многопоточной среде клиент не может наивно использовать объект с изменяемым общим состоянием. Интерфейс коллекции сам по себе ничего не говорит о том, как можно безопасно использовать объект. Возврат ConcurrentMap помогает предоставить некоторую дополнительную информацию, но только для этого конкретного случая.
Обычно вам необходимо сообщить о проблемах безопасности потоков отдельно в документации (например, javadoc) или с помощью пользовательских аннотаций, как описано в Java Concurrency на практике. Клиент возвращенного объекта должен будет использовать свой собственный механизм блокировки или тот, который вы предоставите. Интерфейс обычно ортогонален потокобезопасности.
Это не проблема, если клиент знает, что все реализации взяты из параллельных реализаций,
Java Vector и Hashtable предшествовали текущему пакету параллелизма, который был добавлен в JDK 5. Во время написания Vector , люди думали, что синхронизировать это - хорошая идея, а затем, вероятно, столкнулись с проблемой производительности в корпоративном использовании. Параллелизм, безусловно, является одной из тех ситуаций, когда модульность кода и интерфейса не всегда работает.
Hashtable и Vector очень старые, начиная с JDK 1.0. Они предшествуют стандартным коллекциям из JDK1.2 и не должны использоваться в новом коде с давних пор. Используйте HashMap и ArrayList , заключенные в Collections.synchronizedMap () или Collections.synchronizedList () вместо этого.
Вы можете увидеть версия, когда что-то было введено в JDK в документации API под тегом Since.