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

Помимо потоков, блокировок и мониторов, система многопоточной обработки предлагает еще одну базовую абстракцию: группа потоков (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