Как приоритеты потоков Java транслируются в приоритет потоков ОС?

Question

Как приоритеты потоков API Java (1-10) переводятся в приоритеты уровня ОС, так как большинство ОС не имеют уровней приоритетов потоков (с точки зрения числа), которые соответствуют этому.

Итак, помните, может ли быть сценарий, когда два или более потоков с разными приоритетами в конечном итоге получают одинаковый приоритет на уровне ОС.

Пожалуйста, уточните, если в моем понимании есть некоторая поправка.

Answer 1

Действительно, некоторые уровни приоритета могут отображаться на один и тот же «собственный» уровень приоритета. Вот список (на основе кода Hotspot в OpenJDK 6):

Solaris

• 1 ⇒ 0
• 2 ⇒ 32
• 3 ⇒ 64
• 4 ⇒ 96
• 5 - 10 ⇒ 127

Следует отметить, что в Solaris вы не можете повысить приоритет потока выше обычного, а только понизить его: значение приоритета для 5 совпадает с любым из более высоких значений.

Linux

• 1 - 10 ⇒ 4 - -5 (nice значения)

Следует отметить, что в Linux различные приоритеты потоков в Java сопоставляются с различными значениями приоритетов на собственном уровне.

Windows

• 1 - 2 ⇒ THREAD_PRIORITY_LOWEST
• 3 - 4 ⇒ THREAD_PRIORITY_BELOW_NORMAL
• 5 - 6 ⇒ THREAD_PRIORITY_NORMAL
• 7 - 8 ⇒ THREAD_PRIORITY_ABOVE_NORMAL
• 9 - 10 ⇒ THREAD_PRIORITY_HIGHEST

Answer 2

Я не уверен в Sun JVM в Linux. Написал быструю Java-прогу, чтобы породить 10 потоков с каждым приоритетом и вычислить число pi (4 * atan (1)) с BigDecimals 500 000 раз каждый, присоединиться к каждому потоку и сообщить прошедшее время для метода run. Да, возможно, это не лучший пример, но он остается базовым.

$uname -r && grep bogomips /proc/cpuinfo
2.4.33.3
bogomips        : 4312.26
$java -version 2>&1 |head -1
Java version "1.6.0_01"
$javac T.java && java -Xmx32m T
1:3112
2:2636
3:2662
4:3118
5:2870
6:3319
7:3412
8:3304
9:3299
10:3069

Похоже, не так много отклонений, которые можно было бы ожидать! Это было на маленькой виртуальной машине Linux. Давайте попробуем это на реальной плите на всякий случай, эта коробка также довольно активна со средними значениями нагрузки редко ниже 7, давайте просто посмотрим, как мы планируем в такой среде:

$uname -r && grep bogomips /proc/cpuinfo
2.6.9-67.ELsmp
bogomips        : 3992.93
bogomips        : 3990.00
$java -version 2>&1 |head -1
java version "1.4.2_14"
$javac T.java && java -Xmx32m T
1:63200
2:64388
3:62532
4:58529
5:62292
6:64872
7:64885
8:64584
9:61653
10:61575

Хммм, здесь не так уж много вариаций, не знаю, будет ли 1.4 даже отображённым потоком. Давайте попробуем коробку окон. Я знаю, что Windows имеет довольно агрессивную схему приоритетов потоков. Все, что выше нормальное анекдоталия, потребляет намного больше. Таким образом, давайте увеличим до 900 000 итераций в каждом потоке:

C:\>java -version
java version "1.6.0_11"
C:\>java -Xmx32m T
1:12578
2:12625
3:11469
4:11453
5:10781
6:8937
7:10516
8:8406
9:9953
10:7391

Очень много, что мы ищем, нет?

Answer 3

Ваше понимание верно - приоритеты потоков Java не соответствуют чисто приоритетам потоков ОС.

В результате, если ваш алгоритм каким-либо образом опирается на детали отображения приоритетов потоков, он нарушается, поскольку он будет варьироваться в зависимости от такого количества переменных. Например, обновление JRE или применение пакета исправлений / пакетов обновления к вашей ОС может привести к его поломке - и, конечно, простое выполнение на другой ОС также будет иметь последствия.

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

Хотя вы можете получить более детальную информацию, чем эта, если вы решите, вам нужно знать, что на целевой платформе, скорее всего, будут потеряны все более крупные детали.

Answer 4

Поскольку мы говорим о потоках, я думаю, что это никогда не достигнет ОС напрямую. Приоритет, вероятно, является подсказкой JRE о том, как планировать время процессора для каждого потока. Чтобы иметь дело с вашим примером, должен быть какой-то алгоритм «разрыва связи».

По сути, это будет приоритет приоритета процесса ОС, если JRE не использует сторонние стандарты потоков, такие как POSIX, вместо того, чтобы реализовывать все внутренне.