Даже если ваша программа не создает поток явно, структуры могут создавать потоки от вашего имени, и код, вызываемый из этих потоков, должен быть потокобезопасным. Это добавляет разработчикам проблем.
JVM-машина при запуске создает потоки для служебных задач (например, сбора мусора) и главный поток для работы метода main. Инструментальный пакет AWT (Abstract Window Toolkit) и платформа программирования пользовательского интерфейса Swing создают потоки для управления событиями пользовательского интерфейса. Класс Timer создает потоки для выполнения отложенных задач. Компонентные структуры создают пулы (или пучки) потоков и активируют в них компонентные методы. Мы понимаем, что воспринимать конкурентность как необязательный расширенный функционал языка очень удобно, но реальность такова, что почти все приложения Java являются многопоточными, и имеющиеся структуры не избавляют вас от необходимости правильно координировать доступ к состоянию приложения.
Требование к потокобезопасности нельзя удовлетворить созданием структуры: оно распространяется на все ветви кода, его можно назвать «заразным».
Программные структуры вносят конкурентность в приложения, вызывая компоненты приложений из структурных потоков. Компоненты неизменно обращаются к состоянию приложения, требуя, чтобы всеlastfactors ветви кода, которые обращаются к этому состоянию, были потокобезопасными.
Все описанные ниже механизмы помогут вызывать код приложения из потоков, которые не управляются приложением.
Таймер. Класс Timer — это механизм для планирования задач, которые будут работать позже, один раз или периодически. Но введение этого класса может усложнить последовательную программу, поскольку задачи TimerTask выполняются в потоке, который управляется таймером , а не приложением. Если задача <TimerTask обращается к объектам вместе с другими потоками приложения, то за потокобезопасность эти потоки будут отвечать тоже вместе, поэтому рекомендуем обеспечить потокобезопасность самих объектов.Timer
Сервлеты и страницы JavaServer (JSP). Сервлет предназначен для обработки всей инфраструктуры развертывания приложения и доставки запросов от удаленных клиентов HTTP. Запрос, поступающий на сервер, может доставляться через цепочку фильтров в соответствующий сервлет или JSP. На крупных веб-сайтах многочисленным клиентам могут сразу потребоваться услуги одного сервлета. Поэтому он должен быть потокобезопасным, даже если вызывается из одного потока.
Вызов удаленного метода. Вызов удаленного метода позволяет активировать методы на объектах, работающих в другой виртуальной машине JVM. При вызове удаленного метода с помощью интерфейса RMI (remote method invocation) аргументы метода упаковываются (маршалируются) в байтовый поток и отправляются по сети в удаленную виртуальную машину JVM, где распаковываются (демаршалируются) и передаются удаленному методу.
Код RMI вызывает удаленный объект в некоем потоке, управляемом RMI. Сколько потоков создает RMI? Может ли один и тот же удаленный метод на одном и том же удаленном объекте вызываться одновременно в многочисленных потоках RMI?
Удаленный объект должен координировать доступ не только к состоянию, используемому совместно с другими объектами, но и к состоянию самого удаленного объекта (поскольку один объект может быть вызван в нескольких потоках одновременно). Как и сервлеты, объекты RMI должны быть подготовлены к многочисленным одновременным вызовам и обязаны обеспечивать собственную потокобезопасность.
Swing и AWT. GUI-приложения по определению являются асинхронными. Пользователи в любое время могут выбрать пункт меню или нажать кнопку. Поэтому Swing и AWT создают отдельные потоки для обработки инициируемых пользователем событий и обновления графического представления.
Компоненты Swing, такие как JTable, не являются потокобезопасными. Swing обеспечивает потокобезопасность, ограничивая весь доступ к компонентам GUI-интерфейса событийным потоком. Если приложение хочет управлять GUI-интерфейсом вне событийного потока, оно должно побудить управляющий код выполняться в событийном потоке.
Когда пользователь выполняет действие, в событийном потоке вызывается событийный обработчик для выполнения любой запрошенной операции. Если обработчику необходимо получить доступ к состоянию приложения из других потоков, то событийный обработчик вместе с любым другим кодом, обращающимся к этому состоянию, должен выполнить запрос потокобезопасным способом.
