JVM поддерживает максимальное количество простых тестов потоков

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

Программа тестирования заключается в следующем: код Java:

 импортировать java.util.concurrent.atomic.atomicinteger; Public Class TestThread Extends Thread {Private Static Final AtomicInteger Count = new Atomicinteger (); public static void main (string [] args) {while (true) (new TestThread ()). start (); } @Override public void run () {System.out.println (count.incrementAndget ()); while (true) try {thread.sleep (integer.max_value); } catch (прерванная экспрессия e) {break; }}}

Тестовая среда: Система: Ubuntu 10.04 Linux Kernel 2.6 (32-битный)
Память: 2G
JDK: 1,7

Результаты теста:
Ø Не учитывая системные ограничения

Когда количество созданных потоков достигает 31 842, в системе не может быть создано нити.

Из приведенных выше результатов теста можно видеть, что увеличение памяти кучи (-xms, -xmx) уменьшит количество потоков, которые могут быть созданы, и увеличение памяти стека потоков (-xss минимальное значение этого параметра в 32-битных системах составляет 60 тыс.) Также уменьшит количество потоков, которые могут быть созданы.

Ø в сочетании с системными ограничениями

Предел количества потоков 31842 определяется максимальным количеством потоков, которые система может генерировать:/proc/sys/kernel/threads-max, но ее значение по умолчанию составляет 32080. Модифицировать его значение до 10000: Echo 10000>/Proc/Sys/Kernel/Threads-max, а результаты модифицированных тестов являются следующими:

В этом случае это означает, что может быть настроено как можно больше потоков? Сделайте еще одну модификацию: Echo 1000000>/proc/sys/kernel/threads-max, модифицированные результаты теста следующие:

Установлено, что количество потоков больше не будет увеличиваться после достижения 32279. После проверки максимальное количество PID, которые могут быть созданы с помощью 32-разрядной системы Linux, составляет 32678. Это значение может быть изменено через/proc/sys/kernel/pid_max (метод модификации одинаково, что и потоки), но в системе 32, это может быть изменено, и это может быть меньше, и может быть меньше, и может быть меньше, и это может быть меньше, и это может быть меньше. Когда Threads-Max определенно, результаты теста для изменения PID_MAX заключаются в следующем:

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

На максимальное число, которое может быть сгенерировано в JVM, влияет размер памяти кучи JVM, размер памяти стека и максимальное количество потоков, которые может создать система (реализация потоков Java основана на механизме резьбы под Linux). Конкретное количество может быть оценено на основе максимальной памяти, к которой может получить доступ процесс Java (обычно 2G в 32-битных системах), памяти кучи и памяти стека потока.

последовательность:

Протестированный на 64-разрядной системе Linux (Memory CentoS6, 3G), я обнаружил, что существует другой параметр, который ограничивает количество потоков: maxuserProcess (можно просматривать через Ulimita, значение по умолчанию составляет 1024, и это значение может быть изменено через Ulimitu). Это значение не ограничено в вышеуказанной 32-битной тестовой среде Ubuntu.

Измените Threads -Max, PID_MAX, MaxuserProcess, все три параметра до 100000, -xms, -xmx как можно меньше (128 м, 64 м) и -xS как можно меньше (104K при 64 битах, значение может быть 128 тыс.). Предсказанный заранее в этой тестовой среде количество потоков будет ограничено только размером памяти (3G) тестовой среды. Тем не менее, фактический результат теста заключается в том, что когда количество потоков достигает 32 тыс. (32768, максимальное количество созданных составляет около 33 000), JVM бросает предупреждение: попытка ToallocateStackGuardPages не удалось, а затем OutofmemoryError не может создать локальную нить. После проверки памяти я обнаружил, что есть еще много свободного времени, поэтому это не должно быть связано с емкостью памяти. Предупреждение Google бесплодно. Я не знаю почему, и это требует дальнейших исследований.

Шаг 2:

Я случайно обнаружил статью [7] сегодня и попробовал ее немедленно. Конечно же, этот коэффициент повлияет на количество создания потоков. Согласно описанию в статье, количество/proc/sys/vm/max_map_count удваивается с 65536 до 131072. Общее количество созданных потоков достиг 65000+. Компьютер в основном должен застрять (память 3G) ... Я кратко проверил функцию этого параметра, и описание в [8] выглядит следующим образом:

«Этот файл содержит максимальное количество MemoryMapareasPocessmayhave.memorymapareasareusedasaside-эффект Callingmalloc, непосредственно Bymmapandmprotect, Andalso при загрузке общих библиотек.

В то время как большинство приложений необходимы меньше, чем у карт, определенные программы, особенно Mallocdebuggers, могут потреблять задницу, например, UptoOneortWomapsPerallocation.

Thedefaultvalueis65536 ".

Хорошо, эта проблема наконец была решена полностью. Наконец, факторы, влияющие на количество потоков Java, обобщены:

Сама виртуальная машина Java: -xms, -xmx, -xss;

Системные ограничения:

/proc/sys/kernel/pid_max,

/proc/sys/kernel/thread-max,

max_user_process (ulimit-u),

/proc/sys/vm/max_map_count.

Суммировать

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