Приоритет потока сборки мусора Java

Question

Мне задали в интервью следующий вопрос: "Какой приоритет по умолчанию у потока сборки мусора?" Я знаю, что мы не можем заставить GC или изменить его приоритет, хотя я никогда не слышал о его приоритете по умолчанию. Кто-нибудь знает?

Answer 1

Вероятно, ответ, который искал интервьюер, заключается в том, что сборщик мусора находится в фоновом процессе с низким приоритетом. Причина этого в том, что запуск ГХ стоит дорого, но это (как правило) не критичный процесс, поэтому его следует выполнять только тогда, когда у системы есть время, а не прерывать критические задачи. (Аналогичная идея существует в системах реального времени - выполняйте неважные процессы в фоновой задаче и все критические процессы на переднем плане - все они будут иметь более высокий приоритет, чем фоновая задача.)

С учетом сказанного, если вы читаете литературу Sun по сборке мусора, просто запускать GC как поток с низким приоритетом - это не вполне правильно. На самом деле, GC не может быть просто одним потоком. Вместо этого сборщик мусора запускается, когда памяти мало (хотя определение объема памяти все еще, вероятно, выполняется в фоновом потоке - возможно, кто-то другой может это прояснить).

Вот несколько хороших ссылок для чтения в GC: * ​​1007 *

• http://www.javacoffeebreak.com/articles/thinkinginjava/abitaboutgarbagecollection.html
• Можно ли изменить приоритет потока сборщика мусора?

Answer 2

Я бы сказал, что правильный ответ на этот вопрос: «Если вы думаете, что вам нужно беспокоиться о приоритете потоков сборщика мусора, вы, вероятно, делаете что-то не так».

Помните, что приоритет потока не обязательно напрямую связан с тем, сколько процессорного времени получает процесс. Он варьируется от системы к системе, но в Windows приоритет потоков в основном используется для определения того, в каком порядке, какие потоки, ожидающие запуска, запланированы для доступных процессоров, так что потоки с высоким приоритетом могут вытеснять потоки с низким приоритетом. Предполагая, что оба потока фактически конкурируют за процессор. Нет реального правила «давать процессорам с более низким приоритетом меньше процессорного времени». (На самом деле, в Linux существует немного больше прямой зависимости между приоритетами потоков (хорошими значениями) и выделенным временем ЦП.)

При использовании приоритетов потоков, как они есть в Windows, для фонового потока, такого как сборщик мусора, более подходящее решение может - возможно, как это ни парадоксально - дать ему ВЫСОКИЙ приоритет и затем контролировать пропорцию использования ЦП некоторыми другими означает (по сути, умышленно спать в подходящих пропорциях времени или ждать соответствующих сигналов). В частности, высокий приоритет подходит для фонового потока, который не должен ничего делать большую часть времени, но когда ему нужно что-то сделать, он должен сделать это как можно скорее.

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

Те, кто больше интересуется приоритетами потоков, могут захотеть взглянуть на некоторые измерения влияния приоритетов потоков , которые я принял - по общему признанию, пару лет назад, и этот материал может быть связан с обновлением.

Обновление: по стечению обстоятельств, вчера на YouTube был опубликован доклад Клиффа Клика . Примерно через 35 минут он упоминает именно этот момент, что некоторые потоки JIT и GC должны работать с высоким приоритетом, чтобы они не голодали.

Answer 3

Может быть, вопрос был нацелен на фактическое внедрение JVM. Как вы можете прочитать в онлайн-справках, существует множество способов реализации сборщика мусора, и он может меняться от версии к версии. Вот почему все говорят вам не полагаться на поведение GC. Это может работать по-другому на другой JVM.

Answer 4

По крайней мере в Java RTS, приоритет потока (ов) сборки мусора может быть скорректирован в зависимости от необходимости. Регулировка приоритета (и планирование потоков в целом) также несколько отличается для нескольких процессоров, чем для одного.

На данный момент я предполагаю конфигурацию с несколькими ЦП, поскольку это (безусловно) наиболее распространенная версия. Я также говорю только о планировщике по умолчанию - другие планировщики могут делать вещи совершенно по-другому. Ваши потоки в основном делятся на два класса: критический и некритический приоритет (у вас также могут быть потоки «без кучи в реальном времени», которые выше, чем любой, но поскольку они не / не могут использовать кучу, они имеют мало отношения к GC). Поток (-ы) сборки мусора обычно работают с более низким приоритетом, чем любой из них, но может быть увеличен до более высокого приоритета, чем ваши некритические потоки, когда / при необходимости. Приоритет потока GC всегда остается ниже, чем у критических потоков реального времени.

Я был немного расплывчат в отношении разграничения между «критическими» и «некритическими» приоритетами по причине: это открыто для настройки. Вы можете выбрать, какие приоритеты ваших потоков могут быть заменены GC, а какие нет. Смысл в том, что критические потоки получают жесткий ответ в реальном времени, а некритические потоки получают мягкий ответ в реальном времени. Вы сами решаете / настраиваете, какие потоки попадают в какую категорию.

Answer 5

Это поток с низким приоритетом (не уверен насчет точного приоритета).Дело здесь в том, чтобы избежать, когда GC замедляет обычные потоки, где это возможно.Я бы сказал, что у него приоритет ниже обычного:)