Должны ли все эти потоки по умолчанию работать?И они поддерживают мою JVM? - PullRequest
8 голосов
/ 09 февраля 2012

У меня есть вопрос относительно потоков, которые мое приложение порождает во время выполнения, и об их статусе.

У меня есть приложение Swing, и я заметил несколько странных поведений в некоторых тестовых сценариях с использованием Java VisualVM.Запустив мою программу в течение 30 с лишним минут, ничего не делая (только что запустил и оставил ее там работающей), я заметил следующее.

Прежде всего, на вкладке «Потоки» я вижу много живых потоков.Situation of my application after 30mins or so of not doing anything

Чтение (среди прочего) Потоки по умолчанию, такие как DestroyJavaVM, Обработчик ссылок, Диспетчер сигналов и Что это за потоки, которые запускаются, когда приложение Java начинает свое выполнение? Я понимаю, что у большинства из этих тем есть очень веская причина быть там.(Я все еще пытаюсь выяснить "RMI TCP")
Однако у меня есть сомнения относительно их состояния.Это нормально, что первые шесть из них были в состоянии бега 100% времени?

Кроме того, может ли какой-либо из этих потоков объяснить потребление кучи следующим образом?Heap consumption of my application doing nothing, over 30+ mins

Я заметил, что на многие экземпляры HashMap $ Entry и TreeMap $ Entry ссылаются и создают библиотеки, происходящие из sun.rmi. * И я подумал, что это может быть связано с "RMI TCP"потоки ...

И последнее, но не менее важное: если я попытаюсь избавиться () от моего основного JFrame, сам кадр исчезнет, ​​но приложение все еще будет работать .... может быть причина в этих потоках (или частично) ??

Спасибо всем.

1 Ответ

8 голосов
/ 09 февраля 2012

Я все еще пытаюсь выяснить, какие "RMI TCP"

Эти потоки используются для приема и обработки соединений JMX через RMI.Вы используете один прямо сейчас, когда смотрите на JVisualVM.Вы заметили свой IP в имени рабочего потока?

У меня есть сомнения относительно их состояния.Это нормально, что первые шесть из них находились в состоянии выполнения 100% времени?

То, что поток выполняется , не означает, что он работает и занимает процессорное время.Цитирование Thread.State:

  • NEW - поток, который еще не запущен, находится в этом состоянии.

  • RUNNABLE - Поток, выполняющийся на виртуальной машине Java, находится в этом состоянии.

  • BLOCKED - поток, который заблокирован в ожидании блокировки монитора, находится в этом состоянии.

  • WAITING - Поток, который неопределенно долго ожидает, пока другой поток выполнит определенное действие, находится в этом состоянии.

  • TIMED_WAITING - Поток, ожидающий, пока другой поток выполнит действие в течение указанного времени ожидания, находится в этом состоянии.

  • TERMINATED - выходящий поток находится в этом состоянии.

Как вы можете видеть этоВ списке не упоминается о ожидании ввода-вывода, подобных сокетам.Потоки, выполняющие эту задачу, все еще помечены как runnable .Очевидно, что ожидание данных не потребляет ресурсов процессора.Также поток, принимающий соединения, является runnable , хотя он ничего не делает.Он проснется, когда клиент попытается установить новое соединение.

Кроме того, может ли какой-либо из этих потоков объяснить потребление кучи следующим образом?

Ваша кучапотребление нормальное и здоровое.Форма зубьев обусловлена ​​вывозом мусора, убирающим ненужные предметы.JVM также выясняет, что ваше потребление кучи довольно постоянное, поэтому оно продолжает уменьшать максимальный размер кучи, поскольку считает, что вам не нужно так много (оранжевый график).

Последнее, но не менее важное, если япопробуй dispose () мой основной JFrame, сам кадр исчезнет, ​​но приложение все еще будет работать .... могут ли эти потоки быть причиной (или ее частью) ??

Этопотому что вы закрываете только JFrame, но не все приложение.Swing EDT ( поток диспетчеризации событий ) все еще работает.Но это не имеет к этому никакого отношения.Просто используйте:

jFrame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );

на вашем основном кадре.

TL; DR

Ваше приложение полностью в порядке , если потоки и потребление памятиучтено.Не волнуйтесь!

См. Также

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...