Избегайте группировки потоков

 

Помимо потоков, блокировок и мониторов, система многопоточной обработки предлагает еще одну базовую абстракцию: группа потоков (thread gгоuр). Перво­начально группировка потоков рассматривалась как механизм изоляции апплетов

 

 

197

 

 

в целях безопасности. В действительности своих обязательств они так и не выпол­нили, а их роль в системе безопасности упала до такой степени, что в работе, где выстраивается модель безопасности для платформы Java 2 (Gong99], они даже не упоминаются.

Но если группировка потоков l:Ie несет никакой функциональной нагрузки в сис­теме безопасности, то какие же функции она выполняет? В общих словах, она позво­ляет применять примитивы класса Thread сразу к целой группе потоков. Некоторые из этих примитивов уже устарели, остальные используются нечасто. В итоге группи­ровка потоков не может дать достаточного количества полезной функциональности.

По иронии судьбы, API ThreadGroup слаб с точки зрения поддержки много­поточности. Чтобы для некоей группы получить перечень активных потоков, вы должны вызвать метод enumerate. В качестве параметра ему передается массив, достаточно большой, чтобы в него можно было записать все активные потоки. Метод activeCount возвращает количество активных потоков в группе, однако нет никакой' гарантии, что это количество не изменится в то время, пока вы создаете массив и передаете его методу enumerate. Если указанный массив окажется слишком мал, метод enumerate без каких-либо предупреждений игнорирует потоки, не помес­тившиеся в массив.

Точно так же API некорректен, когда ему передается список подгрупп, входящих в группу потоков. И хотя указанные проблемы можно было решить, добавив в класс ThreadGroup новые методы, этого не было сделано из-за отсутствия реальной потреб­ности. Группировка потоков сильно устарела.

Подведем итоги. Группировка потоков практически не имеет сколь-нибудь по­лезной функциональности, и большинство предоставляемых ею возможностей имеет дефекты. Группировку потоков следует рассматривать как неудачный эксперимент, а существование групп можно игнорировать. Если вы проектируете класс, который работает с логическими группами потоков, вам нужно записывать ссылки Thread, соответствующие каждой логической группе, в массив или коллекцию. Вы могли заметить, что этот совет вступает в противоречие со статьей 30 "Изучите библиотеки и пользуйтесь ими". Однако в данном случае статья 30 не права.

В большинстве случаев следует игнорировать группировку потоков. Однако есть одно небольшое исключение. Нечто полезное можно найти в интерфейсе класса ThreadGroup. Когда какой-либо поток в группе инициирует исключение, не отлавливае­мое в приложении, автоматически вызывается метод ThreadGroup.uncaughtException. Этот метод используется "рабочим окружением" для того, чтобы должным образом реагировать на необработанные исключения. Реализация, предлагаемая по умолчанию, печатает трассировку стека в стандартный поток сообщений об ошибках. Возможно, вы захотите поменять такую реализацию, направив, например, трассировку стека в определенный журнал регистрации.

 

 

198

 

 

Глава 10

Сериализация

В этой главе описывается API сериализации объекта (object serialization), который формирует среду для представления объекта в виде потока байтов и, наоборот, для восстановления объекта из соответствующего потока байтов. Процедура представле­ния объекта в виде потока байтов называется сериализациеu объекта (serializing), обратный процесс называется его десериализациеu (deserializing). Как только объект сериализован, его представление можно передавать с одной работающей виртуальной машины Java на другую или сохранять на диске для последующей десериализации. Сериализация обеспечивает стандартное представление объектов на базовом уровне, которое используется для взаимодействия с удаленными машинами, а также как стан­дартный формат для сохранения данных при работе с компонентами JavaBeans ТМ.

 

⇐ Предыдущая38394041424344454647Следующая ⇒

Поделиться: