2012-02-29 4 views
1

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

But..I в отличие от python, мои процессоры не получают 100% -ное использование (они около 70-80%), и я подозреваю, что это так, как я создаю потоки (код один и тот же между python/java и proceses являются независимыми). В Java, я не знаю, как создать одну нить таким образом я создаю поток для каждого элемента в списке, я хочу, чтобы обработать, например:

for (int i = 0; i < 500; i++) { 
     Runnable task = new MyRunnable(10000000L + i); 
     Thread worker = new Thread(task); 
     // We can set the name of the thread 
     worker.setName(String.valueOf(i)); 
     // Start the thread, never call method run() direct 
     worker.start(); 
     // Remember the thread for later usage 
     threads.add(worker); 
    } 

Я взял его из here. Мой вопрос заключается в том, что это правильный способ запуска потоков или есть способ заставить java самостоятельно управлять количеством потоков, чтобы он был оптимальным? Я, как и все, что мне кажется, хочет, чтобы мой код работал как можно быстрее, и я пытаюсь понять, как рассказать и решить любые проблемы, которые могут возникнуть из-за слишком большого количества создаваемых потоков. Это не главная проблема, просто любопытно, как она работает под java hood.

Спасибо!

ответ

4

Посмотрите на Java Executor API. См. Это, например, article.

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

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

Модель потоковой передачи данных Java и модель Python (не многопроцессорная) действительно очень похожи, кстати. В Python отсутствует глобальный блокиратор Interpreter, поэтому, как правило, меньше необходимости отказываться от нескольких процессов.

+0

+1 Большое вам спасибо. У меня было это чувство о потоках, но поскольку я не мог контролировать их нерестилище (так, как я это делал), я не мог взломать и проверить его больше. Я думаю, что Исполнитель - это именно то, что я могу использовать для этого.Еще один вопрос (несколько связанный), выполняет ли исполнитель статическое количество потоков или если есть избыточная емкость, экзектор автоматически может создавать (или умереть) потоки по мере необходимости? –

+0

Возможно, это возможно, в зависимости от того, создаете ли вы фиксированный пул потоков или пул кэшированных потоков. – DNA

5

Вы используете Executor, реализация которого обрабатывает пул потоков, решает, сколько и так далее. См. the Java tutorial для многих примеров.

В общем, голые потоки не используются на Java, за исключением очень простых вещей. Вместо этого будет существовать некоторый API более высокого уровня, который получает ваш Runnable или Task и знает, что делать.

+0

+1. Исполнители и ExecutorServices - это способ распространения задач между ядрами. –

+0

Большое спасибо, Джош, я предопределю. смотрите глубже в исполнителя и играйте вокруг. Еще раз спасибо! –

2

Thread - это API уровня «низкого уровня».

В зависимости от того, что вы хотите сделать, и версии java, которую вы используете, это лучшее решение. Если вы используете Java 7, и если ваша задача разрешить это, вы можете использовать вилку/нарисуй рамки: http://docs.oracle.com/javase/tutorial/essential/concurrency/forkjoin.html

Однако, посмотрите на Java параллелизм учебник: http://docs.oracle.com/javase/tutorial/essential/concurrency/executors.html

Смежные вопросы