Сколько потоков может Java поддержка VM?

После прочтения поста Чарли Мартина мне стало интересно, влияет ли размер кучи на количество потоков, которые вы можете создать, и я был совершенно ошеломлен результатом.

Использование JDK 1.6.0_11 в Vista Home Premium SP1, я выполнил тестовое приложение Чарли с разными размерами кучи, от 2 МБ до 1024 МБ.

Например, чтобы создать кучу 2 МБ, я бы вызвал JVM с аргументами -Xms2m -Xmx2m.

Здесь Вот мои результаты:

2 mb --> 5744 threads
4 mb --> 5743 threads
8 mb --> 5735 threads
12 mb --> 5724 threads
16 mb --> 5712 threads
24 mb --> 5687 threads
32 mb --> 5662 threads
48 mb --> 5610 threads
64 mb --> 5561 threads
96 mb --> 5457 threads
128 mb --> 5357 threads
192 mb --> 5190 threads
256 mb --> 5014 threads
384 mb --> 4606 threads
512 mb --> 4202 threads
768 mb --> 3388 threads
1024 mb --> 2583 threads

Итак, да, размер кучи определенно имеет значение. Но соотношение между размером кучи и максимальным количеством потоков пропорционально пропорционально.

Что странно.

Гм, лоты.

Здесь есть несколько параметров. Конкретная виртуальная машина, а также обычно есть параметры времени выполнения на виртуальной машине. Это в некоторой степени зависит от операционной системы: какая поддержка потоков в базовой ОС и какие ограничения на них накладываются? Если виртуальная машина вообще использует потоки уровня ОС, старый добрый красный поток / зеленый поток.

Что означает «поддержка» - другой вопрос. Если вы пишете программу на Java, которая похожа на

   class DieLikeADog {
         public static void main(String[] argv){
             for(;;){
                new Thread(new SomeRunaable).start();
             }
         }
    }

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

Обновление

Ладно, не удержался. Вот моя небольшая тестовая программа с парочкой украшений:

public class DieLikeADog {
    private static Object s = new Object();
    private static int count = 0;
    public static void main(String[] argv){
        for(;;){
            new Thread(new Runnable(){
                    public void run(){
                        synchronized(s){
                            count += 1;
                            System.err.println("New thread #"+count);
                        }
                        for(;;){
                            try {
                                Thread.sleep(1000);
                            } catch (Exception e){
                                System.err.println(e);
                            }
                        }
                    }
                }).start();
        }
    }
}

В OS / X 10.5.6 на Intel и Java 6 5 (см. Комментарии), вот что у меня получилось

New thread #2547
New thread #2548
New thread #2549
Can't create thread: 5
New thread #2550
Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread
        at java.lang.Thread.start0(Native Method)
        at java.lang.Thread.start(Thread.java:592)
        at DieLikeADog.main(DieLikeADog.java:6)

После игры с классом Чарли DieLikeACode он выглядит как стек потоков Java Размер - это огромная часть того, сколько потоков вы можете создать.

-Xss установить размер стека Java-потока

Например,

java -Xss100k DieLikeADog

Но у Java есть интерфейс Executor . Я хотел бы использовать это, вы сможете отправить тысячи задач Runnable, и исполнитель будет обрабатывать эти задачи с фиксированным числом потоков.

Я вспоминаю, как слышал лекцию Clojure, в которой он запустил одно из своих приложений на каком-то специализированном компьютере на выставке с тысячи ядер (9000?), и он загрузил их всех. К сожалению, я не могу сейчас найти ссылку (справку?).

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

If you are asking this question, you may want to rewrite your code.

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

Так, например, в 32-битной Windows, где каждый процесс имеет адресное пространство пользователя 2 ГБ, при котором каждому потоку присваивается размер стека 128 КБ, можно ожидать абсолютного максимума в 16384 потока (= 2 * 1024 * 1024/128). На практике я обнаружил, что могу запустить около 13000 под XP.

Затем, я думаю, вы по существу в том, можете ли (a) вы управлять жонглированием таким количеством потоков в вашем коде и не делать это явно глупые вещи (например, заставлять их ждать одного и того же объекта, затем вызывать notifyAll () ...) и (b) может ли операционная система. В принципе, ответом на (b) является «да», если ответом на (а) также является «да».

Кстати, вы можете указать размер стека в конструкторе потока ; для этого вам не нужно (и, вероятно, не следует) возиться с параметрами виртуальной машины.