В чем преимущество ThreadGroup в Java над созданием отдельных потоков?

Question

Многие методы, такие как stop(), resume(), suspend() и т. Д. Устарели.

Так полезно ли создавать потоки, используя ThreadGroup?

Answer 1

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

Answer 2

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

Answer 3

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

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

Answer 4

Краткий ответ - нет, не совсем. Использование одного мало что дает.

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

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

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

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

Answer 5

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

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

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