Это кажется, пожалуй, наивным вопросом, но я вступил в дискуссию с коллегой, где я утверждал, что нет никакой необходимости в том, чтобы кэш был потокобезопасным / синхронизированным, поскольку я предположил бы, что это не имеет значения кто вводит значение, так как значение для данного ключа должно быть «постоянным» (в том смысле, что оно в конечном итоге исходит из того же источника). Если значения могут легко меняться, то сам кеш не кажется всем полезным (в том случае, если вам важно, чтобы значение было «текущим правильным», вам следует перейти к исходному источнику).
Основная причина, по которой я вижу, по крайней мере, синхронизацию GET, заключается в том, что если пропустить в кеше очень дорого, и вы не хотите, чтобы несколько потоков каждый выходили, чтобы получить значение для возврата в кеш. Даже тогда вам нужно что-то, что фактически блокирует всех потребителей во время цикла чтения-извлечения-вставки.
Во всяком случае, мое рабочее предположение состоит в том, что хеш по своей природе является поточно-ориентированным, потому что для любой комбинации {ключ, значение} значение является либо нулевым, либо чем-то, что не имеет значения, кто перейдет туда «первым» написать.
Вопрос: это разумное предположение?
Обновление: реальная область моего вопроса заключается в очень простых кэшах стилей id-> value (или {параметры} -> {вычисляемое значение}, где независимо от того, кто пишет в кеш, значение будет одинаковым, и мы просто пытаюсь спасти от «перерасчета» / возврата к базе данных. Фактический график объекта не имеет значения, а кэш, как правило, долговечен.