|
|
|
Почему этот код иногда приводит к дедлоку?
|
|||
|---|---|---|---|
|
#18+
Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. на моей машине это код ИНОГДА заканчивается дедлоком, а как иногда проходит нормально. Как это можно объяснить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2018, 16:36 |
|
||
|
Почему этот код иногда приводит к дедлоку?
|
|||
|---|---|---|---|
|
#18+
Если метод sum сунуть внутрь IntBinaryOperator, то дедлок не случается Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2018, 16:52 |
|
||
|
Почему этот код иногда приводит к дедлоку?
|
|||
|---|---|---|---|
|
#18+
questioner, В первом случае sum - статичный метод. Во втором - нет. По этому в первом deadlock, а во втором нет. :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2018, 07:58 |
|
||
|
Почему этот код иногда приводит к дедлоку?
|
|||
|---|---|---|---|
|
#18+
mad_nazgulquestioner, В первом случае sum - статичный метод. Во втором - нет. По этому в первом deadlock, а во втором нет. :-) А почему в первом случается ИНОГДА, а не всегда? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2018, 09:55 |
|
||
|
Почему этот код иногда приводит к дедлоку?
|
|||
|---|---|---|---|
|
#18+
questionermad_nazgulquestioner, В первом случае sum - статичный метод. Во втором - нет. По этому в первом deadlock, а во втором нет. :-) А почему в первом случается ИНОГДА, а не всегда? Потому что, как повезет. :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2018, 11:32 |
|
||
|
Почему этот код иногда приводит к дедлоку?
|
|||
|---|---|---|---|
|
#18+
mad_nazgulquestionerпропущено... А почему в первом случается ИНОГДА, а не всегда? Потому что, как повезет. :-) А можете объяснить кейс при котором везёт? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2018, 11:44 |
|
||
|
Почему этот код иногда приводит к дедлоку?
|
|||
|---|---|---|---|
|
#18+
Можно даже ещё проще ту же проблему сделать: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Точно такая же ерунда - иногда нормально проходит, а иногда(почти всегда) зависает ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2018, 13:08 |
|
||
|
Почему этот код иногда приводит к дедлоку?
|
|||
|---|---|---|---|
|
#18+
questionerМожно даже ещё проще ту же проблему сделать: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Точно такая же ерунда - иногда нормально проходит, а иногда(почти всегда) зависает Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2018, 14:42 |
|
||
|
Почему этот код иногда приводит к дедлоку?
|
|||
|---|---|---|---|
|
#18+
dimonz80 questionerМожно даже ещё проще ту же проблему сделать: Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Точно такая же ерунда - иногда нормально проходит, а иногда(почти всегда) зависает Код: java 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Ну это всё прям объясняет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2018, 16:08 |
|
||
|
Почему этот код иногда приводит к дедлоку?
|
|||
|---|---|---|---|
|
#18+
Потому что Fork/Join имеет скорее академический интерес, реально не может управлять внутренними join. "result in a stall (thread in a wait state) when the recursion level becomes long." Годится для быстрых операций (убрали SUM() ВНУТРЬ - работает). Никаких блокировок, вводов/выводов и методов синхронизации использовать нельзя. PS По-моему, это исключает серьезное использование многопоточных stream, основанных на F/J, а так, побаловаться на собеседовании. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2018, 22:02 |
|
||
|
Почему этот код иногда приводит к дедлоку?
|
|||
|---|---|---|---|
|
#18+
questionerна моей машине это код ИНОГДА заканчивается дедлоком, а как иногда проходит нормально. Как это можно объяснить? Ну уже правильно объяснили - везет иногда :). Это пример на class initialization deadlock из вашей соседней темы (правда в данном случае - с самим собой). Ну т.е. main->stream->workers done->some (non-current thread) worker->main. Плюс особенности реализации Fork/Join где вызывающий поток тоже выполняет вычисления. И некоторая задержка на инициализацию пула, потоков и всех остальных локов в worker thread. В первом случае вы вызваете sum на Test, который еще не до конца инициализирован (не отработал static initializer). Поэтому все потоки, обращающиеся к классу Test (кроме main thread) будут ждать. Для FJP - все потоки кроме main при вызове sum будут ждать завершения инициализаци Test, которая в свою очередь ждет завершения вычислений. Если вдруг main успел все обсчитать до других потоков (у него лок на инициализацию Test) - тогда все работает. Увеличьте range или добавьте sleep небольшой - будет стабильнее блокироваться. Во втором примере у вас анонимный класс. Его экземпляр создается в main потоке (все необходимые обращения к Test - допускаются). Экземпляр самодостаточный (к классу Test он не обращается), поэтому все workers могут отработать нормально. Третий пример (с лямбдой) полностью аналогичен первому примеру с дополнительной задержкой. Курите javap -private -v Test. Интересные места - метод lambda$static$0 и BootstrapMethods (которое в конце). В переводе на человеческий, на месте лямбды в коде будет сгенерирован класс, реализующий IntFunction и вызывающий Test.lambda$static$0. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2018, 22:46 |
|
||
|
Почему этот код иногда приводит к дедлоку?
|
|||
|---|---|---|---|
|
#18+
maxkar, авторВ первом случае вы вызваете sum на Test, который еще не до конца инициализирован (не отработал static initializer). Поэтому все потоки, обращающиеся к классу Test (кроме main thread) будут ждать. Для FJP - все потоки кроме main при вызове sum будут ждать завершения инициализаци Test, которая в свою очередь ждет завершения вычислений. Если вдруг main успел все обсчитать до других потоков (у него лок на инициализацию Test) - тогда все работает. Увеличьте range или добавьте sleep небольшой - будет стабильнее блокироваться. Вы будете удивлены, но иногда дедлока не случается даже в случае, когда воркеры обсчитывают лямбду ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2018, 12:56 |
|
||
|
Почему этот код иногда приводит к дедлоку?
|
|||
|---|---|---|---|
|
#18+
questionerВы будете удивлены, но иногда дедлока не случается даже в случае, когда воркеры обсчитывают лямбду Вы будете удивлены, но такие заявления не появляются, когда автор хоть что-то понимает. Повторюсь - вам сначала читать научиться надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2018, 14:36 |
|
||
|
Почему этот код иногда приводит к дедлоку?
|
|||
|---|---|---|---|
|
#18+
alex55555questionerВы будете удивлены, но иногда дедлока не случается даже в случае, когда воркеры обсчитывают лямбду Вы будете удивлены, но такие заявления не появляются, когда автор хоть что-то понимает. Повторюсь - вам сначала читать научиться надо. И что же автор конкретно не понимает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2018, 15:21 |
|
||
|
Почему этот код иногда приводит к дедлоку?
|
|||
|---|---|---|---|
|
#18+
maxkarВ первом случае вы вызваете sum на Test, который еще не до конца инициализирован (не отработал static initializer). Поэтому все потоки, обращающиеся к классу Test (кроме main thread) будут ждать. Для FJP - все потоки кроме main при вызове sum будут ждать завершения инициализаци Test, которая в свою очередь ждет завершения вычислений. Если вдруг main успел все обсчитать до других потоков (у него лок на инициализацию Test) - тогда все работает. Увеличьте range или добавьте sleep небольшой - будет стабильнее блокироваться. Не могу согласиться, работают все потоки (у меня их 8, включая main), поэтому при range=100 у меня вообще никак не падает. ЗАТО ПРИ УВЕЛИЧЕНИИ RANGE стабильно падает после выполнения примерно 80-83% работы (r=400 -> 335, r=1000 -> 830 операций, при r=10 000 немного больше 8 000), видимо начинается "кража работы". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2018, 16:15 |
|
||
|
|

start [/forum/search_topic.php?author=Kuzya&author_mode=last_topics&do_search=1]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
156ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
| others: | 663ms |
| total: | 931ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...