Потоки на процессор

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

Лучший номер зависит от задачи. Если это задача, которая потребляет много ресурсов ЦП и не требует ввода-вывода (например, вычисления числа Пи, простых чисел и т. Д.), Тогда лучше всего будет использовать 1 поток на ЦП. Если задача больше связана с вводом / выводом. Подобно обработке информации с диска, вы, вероятно, получите лучшую производительность, если будете иметь более одного потока на процессор. В этом случае доступ к диску может иметь место, пока ЦП обрабатывает информацию из предыдущего чтения с диска.

Я предлагаю вам провести некоторое тестирование того, как производительность в вашей ситуации зависит от количества потоков на ядро ​​ЦП, и принять решение на основе этого. Затем, когда ваше приложение запускается, оно может проверить availableProcessors() и решить, сколько потоков должно появиться. Благодаря гиперпоточности одно ядро ​​будет отображаться в операционной системе и во всех приложениях, включая availableProcessors(), как 2 ЦП, поэтому, если ваше приложение может использовать гиперпоточность, вы получите преимущество. Если нет, то производительность будет немного снижаться, но, вероятно, этого будет недостаточно, чтобы приложить дополнительные усилия для удовлетворения своих потребностей.

Нет никакого стандартного способа получить количество поддерживаемых потоков на ядро процессора в Java. Ваш лучший выбор состоит в том, чтобы получить утилиту Java CPUID, которая дает Вам информацию о процессоре, и затем соответствуйте ему против таблицы, которую необходимо будет генерировать, который дает Вам потоки на ядро, которым процессор управляет без "реального" контекстного переключения.

-Adam

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

В классе Runtime существует метод availableProcessors () . Это то, что вы ищете?

Каждый процессор или ядро процессора, может сделать точно 1 вещь за один раз. С гиперпоточностью вещи становятся немного отличающимися, но по большей части который все еще остается верным, который является, почему моя машина HT на работе почти никогда не выходит за предел 50%, и даже когда это в 100%, это не обрабатывает вдвое больше сразу.

необходимо будет, вероятно, просто сделать некоторое тестирование на общих архитектурах, на которых Вы планируете развернуться определить, сколько потоков Вы хотите работать на каждом ЦП. Просто использование 1 потока может быть слишком медленным, если Вы ожидаете большого количества ввода-вывода. Выполнение большого количества потоков замедлит вещи, поскольку процессор должен будет переключать потоки чаще, которые могут быть довольно дорогостоящими. Я не уверен, существует ли трудно кодированный предел тому, сколько потоков можно работать, но я гарантирую, что приложение, вероятно, пришло бы к проверке от слишком большого количества потока, переключающегося перед достижением любого вида жесткого предела. В конечном счете необходимо просто оставить его как опцию в конфигурационном файле, так, чтобы можно было легко настроить приложение на любой процессор, Вы работаете на нем.

Основы: приложение, загруженное в память, является процессом . Процесс имеет как минимум 1 поток . Если вы хотите, вы можете создать столько потоков, сколько хотите в процессе (теоретически). Так что количество потоков зависит от вас и алгоритмов, которые вы используете.

Если вы используете пулы потоков , это означает, что пул потоков управляет количеством потоков, поскольку создание потока потребляет ресурсы. Пулы потоков перерабатывают темы. Это означает, что многие логические потоки могут работать в одном физическом потоке один за другим.

Вам не нужно учитывать количество потоков , оно управляется алгоритмами пула потоков. Пулы потоков выбирают разные алгоритмы для серверов и настольных компьютеров (ОС).

Edit1: Вы можете использовать явные потоки , если считаете, что пул потоков не использует имеющиеся у вас ресурсы. В этом случае вы можете явно управлять количеством потоков.

Это - функция VM, не ЦП. Это имеет отношение к сумме "кучи", использованной на поток. Когда у Вас заканчивается пространство на "куче", Вы сделаны. Как с другими плакатами, я подозреваю, что Ваше приложение становится неприменимым перед этой точкой при превышении пространства "кучи" из-за количества потока.

Посмотрите этот обсуждение .

Runtime.availableProcessors возвращает количество логических процессоров (т.е. аппаратные потоки) не физические ядра. См. CR 5048379.