BlazkowiczquestionerСогласен, но распределение это обычно маленькая часть от работы. Во многих случаях это нормально.
А Вы можете предложить более производительный вариант?
А "производительность" она в многопоточности штука относительная. Мы же не знаем ни на сколько конкурентной будет борьба за критические ресурсы, ни на сколько часто у будут пересекаться ключи. В зависимости от подобных параметров разные решения будут выдавать разную производительность.

Согласен, Вы считаете, что текстом нужно было это отразить?

Как по мне это решение явно не проигрывает никакому из тех, что мне в голову пришли. Если бы у меня для одного распределения было решение явно лучше, чем для другого, то я бы это указал. Может какие то решения и будут лучше, но явно не на порядок и надо садиться и измерять, а тут ведь явно была задача на алгоритм.

vimbaquestionervimba,

Ну допустим. там уже предложили вариант полаконичнее с whenCompleteAsync

С whenCompleteAsync у меня все мои тесты прошли нормально, нет проблем не с утечками паямити, не с паралельным выполнением по одному ключу, не с бесконечным зацикливанием. Думаю ситуация с ревью развивалась следующим образом: у них есть набор заковыристых тестов, включая и таски падающие с эксепшенами и таски мгновенно завершающиеся, тесты пофэйлились потому, что у тебя тред повис из-за remove внутри compute, профилировать не стали(а я твой код пронаблюдал в Mission Control где он у тебя зависает), и просто быстро просмотрев код отписали самое на первый взгляд очевидное - проблема в remove, не доглядев как и я что remove не просто по ключу.

В общем я бы на твоем месте сильно не обижался не проверяющих, потому что в коде бага была, и даже с первого раза ты её правильно не исправил.

Ну это недочёт)

Не то, чтобы я действительно искал работу, меня моя работа вполне устраивает.
Просто интересно было решить задание и было время для этого. Я потратил время и решил таки задачу. Я считаю, что я решение придумал и это самое главное, а мелочи небольшие...так без этого никуда. А мне ответили, что я всё не так сделал и идея неправильная. Ну если вы уж даёте такую задачу - будьте в ней экспертами.

Andrei TquestionerЕсли имелось ввиду то, что whenComplete(Async) может не выполниться, то это не правда
Наверно все-таки имелось в виду то, что надо делать так:




Иначе возникает race condition между экзекутором и тредом, выполняющим compute, и как следствие блокировка с зависанием в отдельных случаях.
я думаю это по другому называется) просто произойдёт зависание в случае если таска выплюнет эксекпшн

Andrei Tquestionerпропущено...

я думаю это по другому называется) просто произойдёт зависание в случае если таска выплюнет эксекпшн
Даже если не выплюнет, а просто выполнится раньше, чем будет привязан колбэк. На второй странице это обсуждали. В принципе не суть важно, как это называть, но обычно зависимость результата от порядка выполнения кода в многопоточной среде называют именно так :)

Если просто раньше выполнится - всё будет Ok

Andrei Tquestionerпропущено...


Если просто раньше выполнится - всё будет Ok
Ты вроде сам уже проверял, что Ок не будет: 20769167

Ну ты опять ничего не понял)




так работает нормально.


По ссылке проблема в том, что колбэк должен был выполняться в треде таски и поэтому перед завершением этой таски я жду когда compute вызовет whenComplete. Если whenComplete вызвался когда таска уже завершилась, то коллбэк выховется в треде compute.

а твой код



решает проблему если эксепшн вылетит.

Теперь понятно?

0FDBlazkowiczСогласно документации метод compute() выполняется атомарно . На практике это обозначает что для разных ключей метод исполняется пареллельно, а для ключей из одного бакета, метод блокируется. По-моему это единственный, возможный, недостаток.
Это и есть та самая синхронизацию по ключу.

Да, но здесь блокируется на время создания future, а taskMap.remove разве не выполняется в потоке myTask( который выполняет complete), запущенной из CompletableFuture.runAsync?



Выяснили, что если CompletableFuture.runAsyn уже закончилось к строке
future.whenComplete то тело whenComplete будет вызвано в треде compute