Какая польза от ThreadGroup в java над созданием отдельных потоков?

Ответ 1

Использование ThreadGroup может быть полезным методом диагностики на больших серверах приложений с тысячами потоков. Если ваши потоки логически сгруппированы вместе, тогда, когда вы получаете трассировку стека, вы можете видеть, в какую группу был включен оскорбительный поток (например, "потоки Tomcat", "потоки MDB", "пул потоков X" и т.д.), Которые могут быть большая помощь в отслеживании и устранении проблемы.

Ответ 2

Не используйте ThreadGroup для нового кода. Используйте Executor в java.util.concurrent вместо этого.

Ответ 3

Скорее всего, этот ответ был предоставлен (6 лет назад или около того). Но, хотя API Concurrency предоставляет множество конструкций, ThreadGroup может быть полезен для использования. Он предоставляет следующие функции:

• Логическая организация ваших потоков (для диагностических целей).
• Вы можете interrupt() все потоки в группе. (Прерывание отлично, в отличие от suspend(), resume() и stop()).
• Вы можете установить максимальный приоритет потоков в группе. (не уверен, насколько это полезно, но там у вас есть).
• Устанавливает ThreadGroup в качестве демона. (Таким образом, все новые потоки, добавленные в него, будут потоками демона).
• Это позволяет вам переопределить его uncaughtExceptionHandler, чтобы, если один из потоков в группе выбрасывает исключение, у вас есть обратный вызов для его обработки.
• Он предоставляет вам дополнительные инструменты, такие как получение списка потоков, количество активных из них и т.д. Полезно при наличии группы рабочих потоков или некоторого пула потоков.

Ответ 4

Короткий ответ - нет, не совсем. Там мало какой-либо выгоды от использования.

Чтобы развернуть это немного, если вы хотите объединить рабочие потоки, вам гораздо лучше использовать ExecutorService. Если вы хотите быстро подсчитать количество потоков в концептуальной группе, вам все равно нужно проверить каждый поток отдельно (поскольку ThreadGroup.activeCount() является оценкой, что означает, что это не полезно, если правильность вашего кода зависит от его вывода).

Я бы зашел так далеко, что сказал, что единственное, что вы получили от одного из этих дней, помимо семантической компартиментации, - это то, что потоки, созданные как часть группы, поднимут флаг демонов и разумное имя основанные на их группе. И используя это как ярлык для заполнения нескольких примитивов в вызове конструктора (который обычно вам нужно будет писать только один раз, sicne, вы, вероятно, запускаете потоки в вызове цикла и/или метода).

Итак - я действительно не вижу никаких веских оснований использовать его вообще. Я специально пытался, несколько месяцев назад, и не смог.

EDIT. Я полагаю, что одно потенциальное использование было бы, если вы работаете с SecurityManager, и хотите утверждать, что только потоки в одной группе могут прерывать друг друга. Даже эта красивая граница, поскольку реализация по умолчанию всегда возвращает true для Thread в любой группе, не относящейся к системе. И если вы внедряете свой собственный SecurityManager, у вас есть возможность заставить его принять решение по любым другим критериям (включая типичную технику хранения потоков в коллекциях по мере их создания).

Ответ 5

Великий ответ для @skaffman. Я хочу добавить еще одно преимущество:

Группы потоков помогают управлять всеми потоками, определенными в этом сразу.

Например: вы можете запускать или прерывать все потоки внутри группы с помощью одного вызова метода.