|
|
|
правильный подход к многопоточному разделения задания
|
|||
|---|---|---|---|
|
#18+
Всем привет! Подскажите плиз как правильно организовать многопоточное разделение таска. Например есть файл который надо распарсить, я разбиваю его на 10 частей и 10 потоками надо паралельно его парсить и потом дождавшись отработки все потоков общий рез-т послать jms месаджем. TIJ не сильно помогла, не понятно как это правильно организовавать через Executors (Callable и т.д.) или Synchronizers (CountDownLatch и тд) ? То есть что лучше юзать для окончания работы всех потоков? Заранее спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2013, 13:32:31 |
|
||
|
правильный подход к многопоточному разделения задания
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2013, 14:25:57 |
|
||
|
правильный подход к многопоточному разделения задания
|
|||
|---|---|---|---|
|
#18+
ForkJoinPool - ровно то, что вам нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.09.2013, 14:57:48 |
|
||
|
правильный подход к многопоточному разделения задания
|
|||
|---|---|---|---|
|
#18+
pasha701 , cdtyjv , огоромное спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.09.2013, 15:17:11 |
|
||
|
правильный подход к многопоточному разделения задания
|
|||
|---|---|---|---|
|
#18+
cdtyjvForkJoinPool - ровно то, что вам нужно. FJP не предназначен для выполнения тасков в которых есть IO или блокировки. Тем более когда количество подзадач настолько мало. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2013, 17:58:14 |
|
||
|
правильный подход к многопоточному разделения задания
|
|||
|---|---|---|---|
|
#18+
fixxerFJP не предназначен для выполнения тасков в которых есть IO или блокировки. Почему? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2013, 18:01:28 |
|
||
|
правильный подход к многопоточному разделения задания
|
|||
|---|---|---|---|
|
#18+
BlazkowiczПочему?Вот мне тоже очень интересно. Предполагаю, что сейчас нам скажут про NIO. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2013, 18:50:18 |
|
||
|
правильный подход к многопоточному разделения задания
|
|||
|---|---|---|---|
|
#18+
cdtyjvВот мне тоже очень интересно. Предполагаю, что сейчас нам скажут про NIO. Я даже явадок открыл из любопытства. Да там есть про блокирующее IO. Но там ничего нет про "не преднозначен". Просто немного иначе используется. Можно и через Executors конечно, просто дождаться окончания всех задач. Разницы особой нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.09.2013, 19:15:06 |
|
||
|
правильный подход к многопоточному разделения задания
|
|||
|---|---|---|---|
|
#18+
BlazkowiczfixxerFJP не предназначен для выполнения тасков в которых есть IO или блокировки. Почему? Вкратце, FJP сам управляет жизненным циклом тредов. Если поток долго не появляется в поле зрения пула, то он пытается это компенсировать созданием дополнительных потоков, что теоретически чревато, например, OOM при долгих блокирующих операциях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2013, 16:28:06 |
|
||
|
правильный подход к многопоточному разделения задания
|
|||
|---|---|---|---|
|
#18+
BlazkowiczfixxerFJP не предназначен для выполнения тасков в которых есть IO или блокировки. Почему? Про это говорил Шипилев на последней JUG в Москве. Не знаю, говорил ли в Питерской версии, но на всякий случай вот ссылка ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2013, 16:31:47 |
|
||
|
правильный подход к многопоточному разделения задания
|
|||
|---|---|---|---|
|
#18+
fixxerПро это говорил Шипилев на последней JUG в Москве. Не знаю, говорил ли в Питерской версии, но на всякий случай вот ссылка Да ничего подобного он не говорил. Идея очень простая: FJP хорошо разруливает ситуации, когда одному потоку надо дождаться окончания выполнения другого. В этом случае FJP может загрузить его полезной работой. Но такое на работает для других блокирующих операций (синхронайзеры, IO). И когда внутри таска вы сталкиваемся с блокирующими операциями, то FJP не может загрузить такие потоки полезной работой, они тупо простаивают так же, как и в обычных пулах. Чтобы это дело обойти были придуманы managed blockers ( http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ForkJoinPool.html#managedBlock(java.util.concurrent.ForkJoinPool.ManagedBlocker)). Когда FJP натыкается на такого блокера, в который завернута реальная блокирующая операция, то текущий тред блокируется, а FJP пытается компенсировать потерянный поток путем создания нового. И вот в этом случае у нас действительно есть опасность порушить все, например тем же OOME. Поэтому никаких проблем с обычным IO нет, можно спокойно его использовать в FJP, и не париться. А вот если хочется повысить эффективность работы FJP с блокирующими операциями, и вы решаете полезть в managed blockers, тогда да - надо быть осторожным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2013, 16:55:19 |
|
||
|
правильный подход к многопоточному разделения задания
|
|||
|---|---|---|---|
|
#18+
BlazkowiczcdtyjvВот мне тоже очень интересно. Предполагаю, что сейчас нам скажут про NIO. Я даже явадок открыл из любопытства. Да там есть про блокирующее IO. Но там ничего нет про "не преднозначен". Просто немного иначе используется. Можно и через Executors конечно, просто дождаться окончания всех задач. Разницы особой нет. ForkJoinTask , третий абзац Computations should avoid synchronized methods or blocks, and should minimize other blocking synchronization apart from joining other tasks or using synchronizers such as Phasers that are advertised to cooperate with fork/join scheduling. Tasks should also not perform blocking IO, and should ideally access variables that are completely independent of those accessed by other running tasks. Minor breaches of these restrictions, for example using shared output streams, may be tolerable in practice, but frequent use may result in poor performance, and the potential to indefinitely stall if the number of threads not waiting for IO or other external synchronization becomes exhausted. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2013, 16:57:59 |
|
||
|
правильный подход к многопоточному разделения задания
|
|||
|---|---|---|---|
|
#18+
cdtyjvfixxerПро это говорил Шипилев на последней JUG в Москве. Не знаю, говорил ли в Питерской версии, но на всякий случай вот ссылка Да ничего подобного он не говорил. Идея очень простая: FJP хорошо разруливает ситуации, когда одному потоку надо дождаться окончания выполнения другого. В этом случае FJP может загрузить его полезной работой. Но такое на работает для других блокирующих операций (синхронайзеры, IO). И когда внутри таска вы сталкиваемся с блокирующими операциями, то FJP не может загрузить такие потоки полезной работой, они тупо простаивают так же, как и в обычных пулах. Чтобы это дело обойти были придуманы managed blockers ( http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ForkJoinPool.html#managedBlock(java.util.concurrent.ForkJoinPool.ManagedBlocker)). Когда FJP натыкается на такого блокера, в который завернута реальная блокирующая операция, то текущий тред блокируется, а FJP пытается компенсировать потерянный поток путем создания нового. И вот в этом случае у нас действительно есть опасность порушить все, например тем же OOME. Поэтому никаких проблем с обычным IO нет, можно спокойно его использовать в FJP, и не париться. А вот если хочется повысить эффективность работы FJP с блокирующими операциями, и вы решаете полезть в managed blockers, тогда да - надо быть осторожным. Да, ты прав . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2013, 17:20:53 |
|
||
|
правильный подход к многопоточному разделения задания
|
|||
|---|---|---|---|
|
#18+
fixxercdtyjvпропущено... Да ничего подобного он не говорил. Идея очень простая: FJP хорошо разруливает ситуации, когда одному потоку надо дождаться окончания выполнения другого. В этом случае FJP может загрузить его полезной работой. Но такое на работает для других блокирующих операций (синхронайзеры, IO). И когда внутри таска вы сталкиваемся с блокирующими операциями, то FJP не может загрузить такие потоки полезной работой, они тупо простаивают так же, как и в обычных пулах. Чтобы это дело обойти были придуманы managed blockers ( http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ForkJoinPool.html#managedBlock(java.util.concurrent.ForkJoinPool.ManagedBlocker)). Когда FJP натыкается на такого блокера, в который завернута реальная блокирующая операция, то текущий тред блокируется, а FJP пытается компенсировать потерянный поток путем создания нового. И вот в этом случае у нас действительно есть опасность порушить все, например тем же OOME. Поэтому никаких проблем с обычным IO нет, можно спокойно его использовать в FJP, и не париться. А вот если хочется повысить эффективность работы FJP с блокирующими операциями, и вы решаете полезть в managed blockers, тогда да - надо быть осторожным. Да, ты прав . Что, тем не менее, не отменяет того, что к блокирующему IO в FPJ следует отнестись с вниманием. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2013, 17:23:33 |
|
||
|
правильный подход к многопоточному разделения задания
|
|||
|---|---|---|---|
|
#18+
fixxer , Ну я бы еще больше обобщил: в любых пулах надо с опаской работать с блокирующими операциями. Так как это и сжигание тактов, и риск starvation, и риск OOME. Причем риск всей этой фигни выше, если мы из одного таска плодим другие таски ... а именно так и работает FJP. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2013, 17:45:17 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=38400240&tid=2128550]: |
0ms |
get settings: |
13ms |
get forum list: |
29ms |
check forum access: |
7ms |
check topic access: |
7ms |
track hit: |
301ms |
get topic data: |
15ms |
get forum data: |
4ms |
get page messages: |
73ms |
get tp. blocked users: |
2ms |
| others: | 279ms |
| total: | 730ms |

| 0 / 0 |
