Java, многопоточный класс, конфигурация, избегая синхронизации

Question

Допустим, у меня есть класс, который требует настройки, внедрения зависимости и т. Д.

public class MyClass {
   private String someConfig;
   private SomeMutableClass anotherConfig;


   MyClass() {
     // impractical to set everything in ctor
     // otherwise I'd declare someConfig final and 
     // not worry about MT safety.
   }

   void setConfig(cfg) {
     this.someConfig = cfg;
   }
   void anotherConfig(cfg) {
     this.anotherConfig = cfg;
   }

   ...

   // below is code that uses the config set before, possibly by
   // multiple threads.

}

Это надуманный пример, но что, если я не могу легко выполнить всю конфигурацию в ctor?Допустим, конфигурация выполнена в начале выполнения и не изменяется.Строго говоря, из-за модели памяти мне пришлось бы синхронизировать все ссылки на someConfig.Может ли это требование быть смягчено на практике?

Answer 1

Да, объявив поле как volatile.

Answer 2

Если этот класс инициализируется через Spring, то этого определения достаточно. Нет необходимости синхронизировать доступ или сделать поля изменчивыми.

На практике, если инициализация была выполнена, например, внутри блока синхронизации, то все данные локальных потоков были сброшены в основную память и будут доступны всем потокам для чтения.

Answer 3

Я думаю, что biziciop - простой ответ, если он идеально подходит для вашего вопроса.Мой ответ больше говорит о философской причине выбора одного пути перед другим, поэтому примите его за то, что оно того стоит.

Вы могли бы быть в состоянии ослабить требования, которые вы можете доказать, с помощью правильноготестирование, никогда не бывает в действительности;то есть, чтобы смоделировать ситуацию, о которой вы беспокоитесь в тесте.Я поклонник того, чтобы не перегружать себя идеями, чтобы соответствовать лучшей практике, просто потому, что это лучшая практика.

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

Полагаю, вопрос в том, почему вы хотите избежать требования?Это (1), потому что в вашем дизайне это никогда не произойдет?Разве (2) сделать код понятным, что в противном случае было бы намного труднее / труднее читать / труднее поддерживать.Или это (3) из-за более глубокой возможности многопоточности и синхронизации в целом?

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