Потокобезопасное назначение ссылок при работе с ConcurrentHashSet

Question

Немного запутался по поводу использования ConcurrentHashSets в DTO. К этому DTO одновременно обращаются многие потоки.

Первый случай

 public class LogDTO {
      private Set<String> person = ConcurrentHashMap.newKeySet();

      public void setPerson(Set<String> person) {
       this.person = person;
      }

      public Set<String> getPerson() {
       return this.person;
      }
    }

Обеспечивает ли это безопасность потоков?

ВторойДело

 public class LogDTO {

     private volatile Set<String> person;
      public void setPerson(Set<String> person) {
       this.person = person;
      }

      public Set<String> getPerson() {
       return this.person;
      }
 }

или мне нужно использовать AtomicReference?

Третий случай

 public class LogDTO {

     private AtomicReference<Set<String>> ref = new AtAtomicReference<>();

      public void setPerson(Set<String> person) {
       this.ref.set(person);
      }

      public Set<String> getPerson() {
       return this.ref.get();
      }
 }

Если заполнить совершенно новыйЗатем HashSet присваивает его существующей переменной, тогда лучше ли использовать volatile?

Answer 1

Первый случай

это не потокобезопасно, ConcurrentHashMap обеспечивает безопасность потоков только при работе с API HashMap, что означает добавление и удаление объектов из HashMap. он не обеспечивает безопасность потока при изменении ссылки на HashMap, если вы думаете об этом, изменение ссылки на HashMap не имеет никакого отношения к реализации HashMap.

Второй и третий случаи

Эти случаи являются поточно-ориентированными, в этих случаях вы изменили способ назначения и получения ссылки HashMap, чтобы обеспечить безопасность потоков.

в отношении того, использовать ли volatile или AtomicReference выможете прочитать this

, чтобы дать вам tl; dr: AtomicReference имеет больше функциональных возможностей, но использует дополнительную память для обеспечения этой функциональности, мое личное мнение таково, что если вы не заинтересованы в памяти, переходитевперед и используйте AtomicReference, он более читабелен, и вы не знаете, когда вам понадобится дополнительная функциональность.