MB
И то и то. По запросу загружаем мапу и храним сутки. Если при запросе прошло больше дня - обновляем карту... Наверное все же немного больше читаем. Но на не сильно много.
Size: a a a
2020 March 20
VS
дык бери concurrenthashmap и радуйся
MB
Ну пркол в том что мы в большинстве случаев возвращаем на запрос всю карту
VS
и что
MB
Ну хорошо Вот пример Из одной нити мы обратились на считывание Прошел ень Мы очмстили карту и начали наполнять В это время другой поток тоже захочет считать карту А она наполовину заполнена
z
multipart formdata
Спасибо братишка
MB
Меняй ссылку на неё при кешировании. Не надо очищать. Создавай новую и заполняй. А старая в мусор пойдет
Как вариант кстати
MB
И что - в таком решении никакого подвоха незаметно?
MB
собираешься много писать в карту или много читать из карты?
А какие тут есть хорошие варианты? Огласите пожалуйста весь список.
MB
Ну, это надо архитектуру смотреть. Где-то это сработает, где-то нет
А какие есть хорошие альтернативы? Сейчас активно юзаются ReentrantLock но есть большая уверенность что они начнут течь (в смысле не сработает синхронизация). Либо все встанет.
ЕК
врядли я скажу что то новое, если собираешься много писать то нужно использовать синхронизацию потому что при большом объеме данных запись будет дорогостющей в concurentHashMap, для примерно равноценной записи и чтения можно использовать ReadWriteLock для того что бы задать какой-то алгоритм (он блокирует участок кода при записи и не блокирует при чтении думаю для тебя может быть хороший вариант)
ЕК
Ну хорошо Вот пример Из одной нити мы обратились на считывание Прошел ень Мы очмстили карту и начали наполнять В это время другой поток тоже захочет считать карту А она наполовину заполнена
карта обновляеться один раз в день или заполняеться на протяжении дня?
MB
карта обновляеться один раз в день или заполняеться на протяжении дня?
Заполняется при первом запросе на считывание
A
врядли я скажу что то новое, если собираешься много писать то нужно использовать синхронизацию потому что при большом объеме данных запись будет дорогостющей в concurentHashMap, для примерно равноценной записи и чтения можно использовать ReadWriteLock для того что бы задать какой-то алгоритм (он блокирует участок кода при записи и не блокирует при чтении думаю для тебя может быть хороший вариант)
Это глупость. Chm глубоко сегментирова и часто вообще никакие блокировки при обращении не берет. У локов пропускная способность гораздо ниже.
MB
Это глупость. Chm глубоко сегментирова и часто вообще никакие блокировки при обращении не берет. У локов пропускная способность гораздо ниже.
Так а что тогда делать?
ЕК
на сколько я знаю то put выполняеться в synchronized блоке , использование которого дороже чем Lock который реализован с помощью unsafe, другой вопрос что врядли получиться написать алгоритм который работает быстрее того который реализован в chm
ЕК
другой вопрос что нужно выполнить несколько запросов в мапу атомарно поэтому Николаю вероятнее всего CHM не подойдет
ЕК
вообщем думаю тебе стоит смотреть в сторону readWriteLock