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, обычно служит совершенно иным задачам.
- ну, и с обновлениями раз в сутки, оптимизировать что либо особого смысла нет. Достаточно следить за тем чтобы чтение не блокировалось и тяжелые вычисления не запускались параллельно. И если не блокируемое чтение мы тут видим, то что там как с обновлением приведенный код не особо объясняет.