Java Concurrency: Volatile vs final в каскадных переменных?

volatile влияет только на способность других потоков читать значение переменных, к которым он присоединен. Это никоим образом не влияет на способность другого потока видеть ключи и значения карты. Например, у меня может быть volatile int[]. Если я изменю ссылку, т.е. если я изменю фактический массив, на который он указывает, другие потоки, читающие массив, гарантированно увидят это изменение. Однако, если я изменю третий элемент массива, таких гарантий не будет.

Если status равно final, конструкция содержащего класса создает отношение happens-before с любыми последующими чтениями, поэтому они могут видеть значение состояния. Точно так же любое чтение вашей переменной volatile гарантированно увидит последнее присваивание ей ссылки. Это не похоже на то, что вы очень часто меняете реальную карту, больше похоже на то, что вы просто меняете ключи, а общий объект карты остается как есть.

Таким образом, для этого вопроса нам нужно обратиться к документации для ConcurrentHashMap:

Операции извлечения (включая получение) обычно не блокируются, поэтому могут пересекаться с операциями обновления (включая размещение и удаление). Извлечение отражает результаты самых последних завершенных операций обновления, удерживаемых при их начале.

Это довольно странно сформулировано, но суть в том, что любая get операция, начало которой происходит после возврата некоторой put операции, гарантированно увидит результаты этого пута. Так что вам даже не нужно volatile на внешней карте; сказал JLS:

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

Резюме

Достаточно final на внешней карте.

Стоит обратить внимание на Google-Collections и, в частности, MapMaker, который позволяет разумно настраивать и создавать Карты. . Возможность настроить слабые значения, чтобы включить лучшую сборку мусора и время истечения срока действия, чтобы вы могли использовать Карты для эффективного кэширования, — это блестяще. Поскольку Карты, создаваемые MapMaker (:p), имеют те же свойства, что и ConcurrentHashMap, вы можете быть довольны его потокобезопасностью.

final mapMaker = new MapMaker().weakValues(); //for convenience, assign
final Map<Integer,Map<String,Integer>> status = mapMaker.makeMap();
status.put(key, mapMaker.<String, Integer>makeMap());

Обратите внимание, что вы можете взглянуть на свое определение statusInner, так как оно кажется неправильным.

Я думаю, что лучший ответ здесь заключается в том, что volatile не является способом обеспечения потокобезопасности.

Использование ConcurrentHashMap — это почти все, что вам нужно. Да, сделайте ссылку на Map final верхнего уровня, если можете, но volatile ни в коем случае не нужно. Ссылка второго уровня Map внутри - это дело ConcurrentHashMap, чтобы сделать правильно, и предполагается, что это так.