Приоритет потока сборки мусора Java
Мне задали в интервью следующий вопрос:: "Каков приоритет по умолчанию потока сбора мусора?" Я знаю, что мы не можем заставить GC или изменить его приоритет, хотя я никогда не слышал о его приоритете по умолчанию. Кто-нибудь знает?
5 ответов
вероятно, ответ, который искал интервьюер, заключается в том, что GC находится на низкоприоритетном фоновом процессе. Причина этого заключается в том, что запуск GC является дорогостоящим, но это не (обычно) критический процесс, поэтому его следует делать только тогда, когда у системы есть время, чтобы сделать это, а не прерывать критические задачи. (Аналогичная идея существует в системах реального времени-делать неважные процессы в фоновой задаче, а все критические процессы на переднем плане - все из которых будут иметь более высокий приоритет, чем фоновые задачи.)
с учетом сказанного, если Вы читаете литературу Sun по сбору мусора, просто запуск GC в качестве низкоприоритетного потока не совсем право. На самом деле GC может быть не просто одним потоком. Вместо этого GC запускается, когда память низкая (хотя, определение, когда память низкая, все еще, вероятно, выполняется в фоновом потоке - возможно, кто-то еще может это прояснить).
вот несколько хороших ссылок для чтения на GC:
Я бы сказал, что правильный ответ на этот вопрос: "если вы думаете, что вам нужно беспокоиться о приоритете потока сборщика мусора, вы, вероятно, делаете что-то неправильно".
помните, что приоритет потока не обязательно напрямую связан с тем, сколько времени процессора получает процесс. Он варьируется от системы к системе, но в Windows приоритет потока по существу используется для определения порядка, в котором потоки, ожидающие запуска, запланированы к доступным процессорам, поэтому эти высокоприоритетные потоки могут предвосхищать потоки с низким приоритетом, предполагая, что оба потока фактически конкурируют за CPU. Нет никакого реального правила "дать процессорам с меньшим приоритетом меньше времени процессора". (Для чего это стоит, в Linux, есть немного больше прямой связи между приоритетами потоков (хорошие значения) и выделенным временем процессора.)
с приоритетами потоков, используемыми в Windows, для фонового потока, такого как сборщик мусора, более подходящее решение может-- возможно, парадоксально-дать ему высокий приоритет, а затем контролировать долю использования ЦП каким-то другим способом (по сути, намеренно спать в течение соответствующих пропорций времени или ждать соответствующих сигналов). В частности, высокий приоритет подходит для фонового потока, которому не нужно ничего делать большую часть времени, но когда ему нужно что-то сделать, он должен сделать это как можно скорее.
Я на самом деле не смотрел, какие приоритеты потока используется, если таковые имеются, определенными алгоритмами сбора мусора. Но я считаю, что ситуация несколько сложна, и кажется странным основывать любые предположения о поведении сборщика мусора на приоритетах потоков.
те, кто больше интересуется приоритетами потоков, могут посмотреть на некоторые измерения влияния приоритетов потока что я взял-по общему признанию, пару лет назад, и этот материал может сделать с усовершенствованный.
обновление: по совпадению, a talk by Cliff Click был опубликован на YouTube вчера. Примерно через 35 минут он упоминает именно этот момент, что некоторые потоки JIT и GC должны работать с высоким приоритетом, чтобы они не голодали.
возможно, вопрос был направлен на фактическую реализацию JVM. Как вы можете прочитать в интернете ссылок существует несколько способов реализации сборщика мусора, и это может меняться от версии к версии. Вот почему все говорят вам не полагаться на поведение GC. Это может работать по-другому на другом JVM.
Это поток с низким приоритетом (не уверен в точном приоритете). Дело здесь в том, чтобы избежать GC, чтобы замедлить обычный поток, где это возможно. Я бы сказал, что он имеет более низкий, чем обычный приоритет:)
по крайней мере, в Java RTS приоритет потока(ов) сборки мусора может быть скорректирован в зависимости от необходимости. Настройка приоритета (и планирование потоков в целом) также довольно отличается от нескольких процессоров, чем только с одним.
на данный момент я предполагаю конфигурацию с несколькими процессорами, так как это (на сегодняшний день) наиболее распространено. Я также говорю только о планировщике по умолчанию - другие планировщики могут делать вещи совершенно по-другому. Ваши нити в основном распадаются на две классы: критический и некритический приоритет (у вас также могут быть потоки "без кучи в реальном времени", которые выше, чем либо, но поскольку они не могут/не могут использовать кучу, они имеют мало отношения к GC). Поток(ы) сборки мусора обычно выполняется(ы) с более низким приоритетом, чем любой из них, но can быть повышен до более высокого приоритета, чем ваши некритические потоки, когда/если это необходимо. Приоритет потока GC всегда остается ниже, чем у критических потоков реального времени хотя.
Я был немного расплывчатым о разграничении между "критическими" и "некритическими" приоритетами по причине: это открыто для настройки. Вы можете выбрать, какие приоритеты ваших потоков могут быть предвосхищены GC, а какие нет. Цель состоит в том, чтобы критические потоки получали жесткий ответ в реальном времени, а некритические потоки-мягкий ответ в реальном времени. Это зависит от вас, чтобы решить / настроить, какие потоки попадают в какую категорию.