Как гарантировать get () ConcurrentHashMap, чтобы всегда возвращать последнее фактическое значение?

введение
Предположим, у меня есть ConcurrentHashMap singleton:

public class RecordsMapSingleton {

    private static final ConcurrentHashMap<String,Record> payments = new ConcurrentHashMap<>();

    public static ConcurrentHashMap<String, Record> getInstance() {
        return payments;
    }

}

тогда у меня три в последующем запросы (все обрабатываются разными потоками) из разных источников.
Первая служба делает запрос, который получает синглтон, создает Record например, генерирует уникальный идентификатор и помещает его в Map, затем отправляет этот код в другой сервис.
Затем Вторая служба делает другую запрос, с этим удостоверением. Он получает синглтон, находит Record экземпляр и изменяет его.
Наконец (вероятно, через полчаса) Вторая служба делает еще один запрос, чтобы изменить Record далее.

В некоторых действительно редких случаях я испытываю плавающая ошибка. В логах я вижу, что первый запрос успешно размещен Record на Map, второй запрос нашел его по ID и изменил его, а затем третий запрос попытался найти запись по ID, но ничего не нашел (get() вернулся null).
Единственное, что я нашел о ConcurrentHashMap гарантии, составляет:

действия в потоке перед помещением объекта в любой параллельный collection happen-перед действиями, последующими за доступом или удалением этого элемента из коллекции в другом потоке.

С здесь. Если я правильно понял, это буквально означает, что get() может вернуть любое значение, которое на самом деле было когда-то на карте, насколько это не разрушает happens-before отношения между действиями в разных потоках.
В моем случае это относится так: если третий запрос не заботится о том, что произошло во время обработки первого и второго, то он может прочитать null С Map.

Это не подходит мне, потому что мне действительно нужно получить от Map последние актуальные Record.

что я пробовал
Поэтому я начал думать, как сформировать happens-before отношения между последующими Map модификации; и пришел с идеей. JLS говорит (в 17.4.4), что:

запись в изменчивую переменную v (§8.3.1.4) синхронизируется-со всеми последующие чтения v любым потоком (где" последующий " определяется согласно порядку синхронизации).

так, предположим, я модифицирую свой синглтон следующим образом:

public class RecordsMapSingleton {

    private static final ConcurrentHashMap<String,Record> payments = new ConcurrentHashMap<>();
    private static volatile long revision = 0;

    public static ConcurrentHashMap<String, Record> getInstance() {
        return payments;
    }

    public static void incrementRevision() {
        revision++;
    }
    public static long getRevision() {
        return revision;
    }

}

затем, после каждой модификации Map или Record внутри, я позвоню incrementRevision() и перед любым чтением с карты я позвоню getRevision().

вопрос
Из-за природы heisenbugs никакое количество тестов не достаточно, чтобы сказать, что это решение правильно. И я не эксперт в параллелизме, поэтому не мог проверить это формально.

Может кто-то одобрить, что следуя этому подходу, я всегда буду получать последнее фактическое значение от ConcurrentHashMap? Если этот подход неверен или кажется неэффективным, не могли бы вы порекомендовать мне что-то еще?