Java, очень ограниченный на макс. количестве потоков?
У нас есть маленькое текстовое поле с 512 МБ поршня. Мы хотели видеть, сколько потоков мы можем создать в Java в этом поле. К нашему удивлению мы не можем создать многих. По существу минимальный размер стека, который можно установить с-Xss, является 64k. Простая математика скажет Вам, которые 64*7000 используют 430 МБ, таким образом, мы только смогли получить ее приблизительно до приблизительно 7 000 потоков, и затем мы встретились с этой ошибкой:
java.lang.OutOfMemoryError: unable to create new native thread.
Действительно ли это - истинный предел с Java? На 512 МБ поршня мы можем только сжать в 7k количестве потоков или так?
6 ответов
Попробуйте установить максимально допустимый объем памяти -Xmx на меньшее значение и посмотрите, можно ли увеличить количество потоков. В рабочем проекте я мог выделить около 2,5 тыс. Потоков с -Xmx512m и около 4 тыс. Потоков с -Xmx96m.
Чем больше ваша куча, тем меньше пространство стека потоков (по крайней мере, по моему опыту).
Дело не в языке программирования, это на уровне операционной системы.
Подробнее об этом для Windows:
После того, как вы создадите свои 7k потоков, у вас не останется памяти, чтобы делать что-нибудь полезное. Возможно, вам стоит переосмыслить дизайн вашего приложения?
В любом случае, разве 512 Мб не так уж мало? Не могли бы вы предоставить немного больше информации о своем приложении или, возможно, о домене?
Используйте асинхронный ввод-вывод (java nio) и вам не понадобится 7k потоков для поддержки 7k клиентов, будет достаточно нескольких потоков для обработки io (5?).
Взгляните на Netty ;)
Один поток для каждого клиента - действительно плохой дизайн.
Помните, что вы никогда не сможете выделить 100% ОЗУ для выполнения потоков Java. Некоторая часть оперативной памяти используется ОС и другими запущенными приложениями, а это означает, что у вас никогда не будет доступных 512 МБ.
Вам не обязательно нужен один поток на сеанс клиента. Если вы посмотрите на то, как сервер J2EE (или JavaEE) обрабатывает несколько соединений, он использует смесь стратегий, включая параллелизм, постановку в очередь и обмен. Обычно вы можете настроить максимальное количество одновременно работающих экземпляров и значения времени ожидания простоя во время развертывания, чтобы настроить производительность вашего приложения.