RM
Чем тебе пепе не угодил? А насчёт политики - это оффтоп и должны соблюдаться разумные пределы
Size: a a a
2020 August 24
RM
SK
Чем тебе пепе не угодил? А насчёт политики - это оффтоп и должны соблюдаться разумные пределы
Ну, как там выше было? Кому нужно - пусть видит, мне - не нужно? Для меня он - бородатый мем, который изначально то не особо доставлял, но его продолжают пихать везде снова и снова и снова.
Но не суть. Я не за цензуру, по крайней мере - не здесь.
Но не суть. Я не за цензуру, по крайней мере - не здесь.
2020 August 25
SS
Обновлённая версия
SS
SK
Хм. Седня прям день граальВМа какой то, буквально утром доклад смотрел: https://www.youtube.com/watch?v=gmfM_pAbBdU
2020 August 27
SK
Народ, возможно не самый умный вопрос задам, но все же: есть у concurrent hash map одна не самая приятная особенность - https://www.javacodegeeks.com/2015/05/puzzler-nested-computeifabsent.html. Вопрос - если тредсейфети нужно, нэстить compute if absent чревато, а менять мапу на concurrent skip list map - не вариант, как бы вы стали убирать этот дедлок, если б впоролись в такое?
RM
что то я вопрос не понял, если честно, ты внутри функции вычисления аргумента для мапы модифицируешь эту же мапу?
RM
и ты спрашиваешь что нужно делать?
RM
если сложилась такая ситуация, что если в мапе нету элемента надо не только этот элемент положить, но и еще какой то - это явно лучше написать скажем так без лямбд. вообще модифицировать внешний мир из лямбды спорный момент как минимум. могу предложить только написать на обычных локах и синхронайзах корректную проверку и упаковку значений без компута
RM
map.computeIfAbsent(Key.Hello, s -> {
map.computeIfAbsent(Key.Hello, t -> 1);
return 2;
});
как вообще так можно было изначально написать?
RM
то есть ты сначала одно скомпутил, потом другое на тот же ключ и ожидаешь какого то адекватного поведения - нужен кейс в студию, иначе не ясно
SK
Изначальная история не настолько прямолинейна. Я её упростил малясь. Ты спрашиваешь - как так вышло? Представь что две этих лямбды - это некие вычисления, которые должны быть мемоизированны. В спринге для целей кеширования есть контракт Cache с методом get(ключ, лямбда). Лямбда вызывается если по ключу в кеше ничего нет. Одна из имплементаций этого кеша - Concurrentmapcache, по умолчанию использующая concurrenthashmap в качестве стореджа. Ну а представить себе две вложенные друг в друга и кешируемые лямбды не так и сложно.
И чтоб впороться, ключ необязательно должен быть одинаковым. Достаточно того, чтоб два ключа залочились на одном бакете.
И чтоб впороться, ключ необязательно должен быть одинаковым. Достаточно того, чтоб два ключа залочились на одном бакете.
RM
Изначальная история не настолько прямолинейна. Я её упростил малясь. Ты спрашиваешь - как так вышло? Представь что две этих лямбды - это некие вычисления, которые должны быть мемоизированны. В спринге для целей кеширования есть контракт Cache с методом get(ключ, лямбда). Лямбда вызывается если по ключу в кеше ничего нет. Одна из имплементаций этого кеша - Concurrentmapcache, по умолчанию использующая concurrenthashmap в качестве стореджа. Ну а представить себе две вложенные друг в друга и кешируемые лямбды не так и сложно.
И чтоб впороться, ключ необязательно должен быть одинаковым. Достаточно того, чтоб два ключа залочились на одном бакете.
И чтоб впороться, ключ необязательно должен быть одинаковым. Достаточно того, чтоб два ключа залочились на одном бакете.
все еще не понял. если нет одного ключа ты пытаешься еще и другой ключ заодно вычислить?
RM
если очень хочется вычислять сразу все на свете - помогает внешний объект контейнер с несколькими полями нужного типа. вместо кампут иф абсент - гет ор дефолт, результат в контейнер, в конце делаешь пут
RM
раз хочется писать странные вещи
SK
все еще не понял. если нет одного ключа ты пытаешься еще и другой ключ заодно вычислить?
Есть одна лямбда, ей нужен результат другой лямбды. Обе лямбды нужно мемоизировать, при этом доступ к лямбдам конкурентный, и инициализация кеша должна происходить не больше одного раза.
RM
вот так задача уже звучит не так безумно