Copy on Write Map ?

zig zuА как в этом случае быть с обновлением мапы?

Посмотреть реализацию в существующих примерах?

zig zuМне ее сначала надо все очистить, и потом заново записть туда данные, получается, что в какой-то момент методы getData могут получить пустую или незаполненную мапу. Не?
Вы сами не понимаете как работает то что написали? Мапу зачем чистить?

zig zuЧтобы ее обновить. Приходят новые данные для мапы, старые все удаляем, записываем новые.
Или вы предлагаете усложнить процесс обновления мапы и каждый раз в цикле сравнивать старые и новые данные?
Тогда я не понял что у вас за кэш вообще. Идея Copy on Write в том что бегущие потоки используют старую версию данных, что вполне безопасно. А "новые" потоки, посетившие кэш уже получат новую копию. Таким образом нет никакого промежуточного состояния, когда поток может увидеть невалидный кэш.

Если вы имели ввиду что-то другое, то я не совсем понимаю что ваш код должен вообще делать.

zig zuКод делает следующее: получили данные, сохранили их(updateData()), пользуемся данными из нескольких потоков(getData()). Раз в сутки обновляем данные, опять через updateData().
Тогда у меня для вас вот ещё схема вечного двигателя.

zig zuСтареете?

Переходите на личности?

zig zuСначала не разобравшись в проблеме CopyOnWriteMap посоветовали.

Чтобы в чем-то разобраться, нужно что-то в чем можно было бы разобраться.

zig zuПотом еще раз не разобравшись картинку не в тему выложили.

Это намек на то что рассуждения о кешировании в этой теме, пока что на уровне обсуждения вот этой реализации вечного двигателя.

zig zuНет, просто мне кажется, что вы надо мной издеваетесь.

Ну, у меня аналогичные ощущения.
Вы привели код, который почти ничего не иллюстрирует, но отказываетесь его объяснить.
Код похож на концепцию copy-on-write, но вы это почему-то отрицаете, тоже не пытаясь объяснить причину.
Вы говорите о какой-то "очистке", которой в вашем коде нет, и которая особо не нужна. И тоже не объясняете для чего нужна эта "очистка".

zig zuНе знаю как еще подробнее объяснить задачу.

Задача - кеш в многопоточной среде.
Плюсы и минусы - изучаем copy on write и читаем про плюсы и минусы.
Будет ли он вообще безопасно работать в многопоточной среде? Сложно сказать, потому что не рассмотрены все сценарии использования - например совершенно неожиданно всплыли суточные обновления. Если данные обновлять раз в сутки, то вообще до одного места как там кеш реализован, можно спокойно в ReadWriteLock обернуть.

zig zuПопробую еще раз. Давайте уберем из обсуждения пока слово кеш, может оно сбило вас с толку.

Вот это поворот.

zig zuДелаем запрос через веб сервис, получаем немаленький ответ, сохраняем его в мапе. Далее потоки, которым нужны данные из ответа, берут его из мапы, а не делают каждый раз запрос к веб сервису.
В самом веб сервисе данные иногда обновляются и нам соотвтественно надо нашу мапу тоже обновлять.
Свое решение я привел в коде в самом первом посте.
Ну, так-то на много лучше. Что мешало сразу расписать сценарий использования?
Не понятно на сколько критично получать актуальные данные. Не понятно зачем два метода getData() и зачем в них хранить ссылку в локальной переменной.

zig zuКак вариант, можно еще использовть ehcache, но хотелось пока сделать что-нибудь попроще.
Его, например, можно сразу персистить, в отличие от велосипеда. Но надо оно вам или нет, мы не знаем.

maytonА вы не ругайтесь 20 страниц а просто приведите usecase когда его код будет делать damage
или overhead.
- updateData() стоило бы объявить synchronized, если там подразумеваются долгие вычисления. Если нет, то не понятно кто будет гарантировать, что "тяжелые" вычисления не будут запускаться параллельно.
- локальная переменная в get-методе лишняя, как и 2й get-метод
- сбивает с толку использование Map - так как там по задаче выходит любой бизнес-объкт. Так же как и применение сюда термина "кеш", который в комбинации с Map, обычно служит совершенно иным задачам.
- ну, и с обновлениями раз в сутки, оптимизировать что либо особого смысла нет. Достаточно следить за тем чтобы чтение не блокировалось и тяжелые вычисления не запускались параллельно. И если не блокируемое чтение мы тут видим, то что там как с обновлением приведенный код не особо объясняет.

zig zuКак пример:

Всё равно не очевидно. Вижу минимум 2 варианта.



Или

zig zuТак вся суть как раз в том, чтобы нигде synchronized не было.

Для записи раз в сутки очень важно чтобы методы записи были не блокирующими. Так?

zig zuМой класс Data вообще не блокирующий не для читающих ни для пишущего потока.

Я вижу. Поэтому объясняю к чем это приведет.

zig zuДля этого и локальные ссылки нужны в методах.

Не вижу связи, если вы читаете только по одному ключу. Если в get методе много операций, тогда ладно. Но вы же не напрягаете себя объяснением таких нюансов.

zig zuОбновлять может только один поток
"Я так сказал". Да? Других причин почему это так нет? Если без иронии, то вопрос простой. Кто гарантирует что это только один поток?

zig zuНесколько методов get осуществляют поиск по разным ключам.
Возможно это важно в вашем проекте, но приведенный код никак не объясняет зачем это сделано.

zig zuВот это правильное замечание, локальная ссылка в методах get может действительно не нужна?

Зависит от реализации метода, которую вы опустили.

zig zuЯ правильно понимаю, что при вызове метода get в стеке потока будет создана копия ссылки на мапу data?

Нет, не создаётся. Просто если ссылка используется только один раз, что для приведенного кода логично, то и для чего хранить эту ссылку на стеке, не ясно.

zig zuП.С. А разные методы get ищут по разным ключам.
Вариант сделать ключ аргуметом метода не рассматривается?

DEVcoachУчитывая логику этого метода - полная перезапись всей мапы - synchronized здесь не нужен совершенно.
Не нужен здесь, значит нужен где-то ещё. Потому как автор хочет тяжелые вычисления делать где-то единственным потоком.

DEVcoachОтнюдь, код, приведенный автором, - как раз таки является классическим кэшем, только вместо операции put у него bulk update.
Кешем оно не является вообще, так как код автора сводиться к одному единственному volatile полю, в итоге. Смотри.
HashMap к вопросу отношения не имеет. Значит это любой бизнес объект.
Заполнять бизнес объект в методе updateData тоже смысла нет, можно заполнить и снаружи, передавая готовое значение. Ведь метод не synchronized, значит тяжелые вычисления делаются вне его.
Точно так же getData это лишь делегат для volatileField.get();

В итоге, всё сводиться к тому что кроме объявления волатайл поля, весь остальной код это шум. Поэтому назвать поле кэшем у меня язык не поворачивается.

zig zuЯ гарантирую.

Ну, вот и я о том же.

zig zuЕсть специальный поток, который вызывает веб сервис и передает данные в полученном виде в метод updateData, там уже происходит конвертация и сохранение во внутреннею мапу.
В плане реализации это будет singleton ejb timer или спринговый шедулер.

Ню-ню.