+1, если бы у меня были баллы за "до вас, чтобы сделать этот потокобезопасным"

вы определите свой сервис в одноэлементной области действия в своем весеннем конфиге, что произойдет, если более одного пользователя попытаются получить к нему доступ (т.е. как зависимость вводится в ваш контроллер) одновременно? Должно ли это вызвать конфликт? Или контейнер IoC будет удерживать более поздний вызов до завершения первого? Если это так, то это должно замедлить производительность в больших приложениях, что мне не подходит. Кто-нибудь может дать мне правильный ответ?

Кстати, насколько я помню, если он не одноэлементный, контейнер IoC будет объединять несколько экземпляров в зависимости от количества запросов. Может ли кто-нибудь это подтвердить?

Ответы на вопрос(2)

Решение Вопроса

если несколько пользователей попытаются получить к нему доступ (т. е. в виде зависимости, введенной в ваш контроллер) одновременно?

Доступ к одноэлементному бобу возможен много раз одновременно. Вот почему это всегда должно быть потокобезопасным

Должно ли это вызвать конфликт?

Только если вам не удастся сделать потокобезопасным

Или контейнер IoC будет удерживать более поздний вызов до завершения первого?

Нет, это было бы ужасно

Кстати, насколько я помню, если он не одноэлементный, контейнер IoC будет объединять несколько экземпляров в зависимости от количества запросов. Может ли кто-нибудь это подтвердить?

Spring имеет следующие области применения (см. справку по Бобовым областям):

одиночка (для одного приложения управляется только один экземпляр)прототип (новый экземпляр для каждой инъекции)сессия (один экземпляр на сеанс HTTP, только в Spring MVC)запрос (один экземпляр на HTTP-запрос, только в Spring MVC)глобальная сессия (один экземпляр на глобальный сеанс HTTP, только в Spring MVC на основе портлетов)

Также:

Начиная с Spring 3.0 область потока доступна, но по умолчанию она не зарегистрирована. Для получения дополнительной информации см. Документацию дляSimpleThreadScope.

То, что вы описываете, это пул объектов. Весной это будет реализовано в виде прототипаFactoryBean, И внутренне он будет использовать библиотеку какApache Commons / Pool.

 Brolinuk07 янв. 2011 г., 13:10
Спасибо за ответ. Какова была бы лучшая практика, чтобы сделать поток класса singleton безопасным? Я не думаю, что использование блока синхронизации было бы хорошей идеей, так как это слишком дорого для производительности.
 Sean Patrick Floyd07 янв. 2011 г., 13:45
@Brolinuk Иногда вам нужны синхронизированные блоки, иногда нет. ЧитатьJava-параллелизм на практике для дальнейшего использования. В основном: если у вас нет изменяемого состояния, вы обычно потокобезопасны. Если вы это сделаете, вам понадобится какой-то способ синхронизации доступа к изменяемому состоянию. Там также естьсоответствующий вопрос SO

м Spring, и все запросы проходят через этот экземпляр одновременно. Это зависит от вас, чтобы сделать этот потокобезопасным.

Если ваш bean-компонент не является потокобезопасным, подумайте о том, чтобы использовать bean-объекты не синглтоновой области. Spring позволяет использовать области запросов, сеансов и прототипов.

 Kurru06 янв. 2011 г., 17:59
+1, если бы у меня были баллы за "до вас, чтобы сделать этот потокобезопасным"

Ваш ответ на вопрос