Синхронізація нефінального поля

Question 1

Попередження відображається кожного разу, коли я синхронізуюсь із нефінальним полем класу. Ось код:

public class X  
{  
   private Object o;  

   public void setO(Object o)  
   {  
     this.o = o;  
   }  

   public void x()  
   {  
     synchronized (o) // synchronization on a non-final field  
     {  
     }  
   }  
 }

тому я змінив кодування таким чином:

 public class X  
 {  

   private final Object o;       
   public X()
   {  
     o = new Object();  
   }  

   public void x()  
   {  
     synchronized (o)
     {  
     }  
   }  
 }

Я не впевнений, що наведений вище код є правильним способом синхронізації в нефінальному полі класу. Як я можу синхронізувати не остаточне поле?

Question 2

Перш за все, я закликаю вас реально постаратися вирішити проблеми паралельності на вищому рівні абстракції, тобто вирішити їх за допомогою класів з java.util.concurrent таких як ExecutorServices, Callables, Futures тощо.

З огляду на це, немає нічого поганого в синхронізації в нефінальному полі як такому. Потрібно лише мати на увазі, що якщо посилання на об’єкт змінюється, той самий розділ коду може виконуватися паралельно . Тобто, якщо один потік запускає код у синхронізованому блоці і хтось дзвонить setO(...), інший потік може одночасно запускати той самий синхронізований блок на тому самому екземплярі .

Синхронізуйте об’єкт, до якого вам потрібен ексклюзивний доступ (або, ще краще, об’єкт, призначений для його охорони).

Question 3

Це насправді не є гарною ідеєю - адже ваші синхронізовані блоки вже насправді не є синхронізовані послідовно.

Якщо припустити, що синхронізовані блоки мають забезпечувати доступ до деяких спільних даних одночасно лише одним потоком, розглянемо:

Потік 1 надходить у синхронізований блок. Так - він має ексклюзивний доступ до спільних даних ...
Виклики потоку 2 setO ()
Потік 3 (або ще 2 ...) входить до синхронізованого блоку. Ік! Він вважає, що має ексклюзивний доступ до спільних даних, але потік 1 все ще метушиться з ним ...

Чому ви хочете, щоб це сталося? Можливо, є деякі дуже спеціалізовані ситуації, коли це має сенс ... але вам доведеться представити мені конкретний випадок використання (разом із способами пом'якшення такого роду сценаріїв, які я наводив вище), перш ніж я буду задоволений це.

Question 4

Я погоджуюсь з одним із зауважень Джона: Ви завжди повинні використовувати фіктивну фіктивну фіксацію під час доступу до не остаточної змінної, щоб запобігти невідповідностям у разі зміни посилання на змінну. Отже, у будь-яких випадках і як перше правило:

Правило №1: Якщо поле не є остаточним, завжди використовуйте (приватний) фінальний фіктивний замок.

Причина №1: Ви тримаєте замок і змінюєте посилання на змінну самостійно. Інший потік, який чекає за межами синхронізованого блокування, зможе увійти в захищений блок.

Причина 2: Ви тримаєте замок, а інший потік змінює посилання на змінну. Результат той самий: інший потік може потрапити в захищений блок.

Але при використанні фінального фіктивного фіксатора виникає ще одна проблема : ви можете отримати неправильні дані, оскільки ваш нефінальний об'єкт буде синхронізований лише з оперативною пам'яттю під час виклику синхронізації (об'єкта). Отже, як друге правило:

Правило №2: При блокуванні нефінального об'єкта вам завжди потрібно робити обидва: Використання фіктивного фіктивного блокування та блокування нефінального об'єкта задля синхронізації оперативної пам'яті. (Єдиною альтернативою буде оголошення всіх полів об’єкта мінливими!)

Ці замки ще називають «вкладеними замками». Зверніть увагу, що ви повинні телефонувати їм завжди в однаковому порядку, інакше ви отримаєте глухий замок :

public class X {
    private final LOCK;
    private Object o;

    public void setO(Object o){
        this.o = o;  
    }  

    public void x() {
        synchronized (LOCK) {
        synchronized(o){
            //do something with o...
        }
        }  
    }  
}

Як бачите, я записую два замки безпосередньо в одному рядку, тому що вони завжди належать разом. Ось так ви могли б навіть зробити 10 вкладених замків:

synchronized (LOCK1) {
synchronized (LOCK2) {
synchronized (LOCK3) {
synchronized (LOCK4) {
    //entering the locked space
}
}
}
}

Зверніть увагу, що цей код не зламається, якщо ви просто придбаєте внутрішній замок, як synchronized (LOCK3)у інших потоках. Але це зламається, якщо ви зателефонуєте в інший потік приблизно так:

synchronized (LOCK4) {
synchronized (LOCK1) {  //dead lock!
synchronized (LOCK3) {
synchronized (LOCK2) {
    //will never enter here...
}
}
}
}

Існує лише одне обхідне рішення щодо таких вкладених блокувань під час обробки нефінальних полів:

Правило №2 - Альтернатива: оголосіть усі поля об’єкта мінливими. (Я не буду тут говорити про недоліки цього, наприклад, запобігання будь-якому сховищу в кешах рівня x навіть для читання, aso.)

Тож aioobe цілком має рацію: просто використовуйте java.util.concurrent. Або починайте розуміти все, що стосується синхронізації, і робіть це самостійно за допомогою вкладених замків. ;)

Щоб отримати докладнішу інформацію, чому синхронізація в нефінальних полях переривається, ознайомтесь із моїм тестовим прикладом: https://stackoverflow.com/a/21460055/2012947

А для більш детальної інформації, чому вам взагалі потрібна синхронізація завдяки оперативній пам’яті та кешам, дивіться тут: https://stackoverflow.com/a/21409975/2012947

Question 5

Я насправді не бачу правильної відповіді тут, тобто, цілком нормально робити.

Я навіть не впевнений, чому це попередження, у ньому немає нічого поганого. JVM гарантує, що ви отримаєте якийсь дійсний об'єкт назад (або нульовий) при читанні значення, і ви можете синхронізувати з будь-яким об'єктом.

Якщо ви плануєте фактично змінити замок під час його використання (на відміну від, наприклад, зміни його з методу init, перед тим, як почати його використовувати), вам слід зробити змінну, яку ви плануєте змінити volatile. Тоді все, що вам потрібно зробити, це синхронізувати як старий, так і новий об’єкт, і ви можете безпечно змінити значення

public volatile Object lock;

...

synchronized (lock) {
    synchronized (newObject) {
        lock = newObject;
    }
}

Там. Це не складно, написання коду із замками (мьютекси) надзвичайно просто. Написати код без них (заблокувати безкоштовний код) - це важко.

Question 6

РЕДАКТУВАТИ: Отже, це рішення (як запропонував Джон Скіт) може мати проблему з атомністю реалізації "синхронізованого (об’єкта) {}", коли посилання на об’єкт змінюється. Я запитав окремо, і, за словами містера Еріксона, це не є безпечним для потоку - див .: Чи є введення синхронізованого блоку атомним? . Тож візьміть це як приклад, як цього НЕ робити - із посиланнями чому;)

Подивіться, як би це працювало, якби синхронізація () була атомною:

public class Main {
    static class Config{
        char a='0';
        char b='0';
        public void log(){
            synchronized(this){
                System.out.println(""+a+","+b);
            }
        }
    }

    static Config cfg = new Config();

    static class Doer extends Thread {
        char id;

        Doer(char id) {
            this.id = id;
        }

        public void mySleep(long ms){
            try{Thread.sleep(ms);}catch(Exception ex){ex.printStackTrace();}
        }

        public void run() {
            System.out.println("Doer "+id+" beg");
            if(id == 'X'){
                synchronized (cfg){
                    cfg.a=id;
                    mySleep(1000);
                    // do not forget to put synchronize(cfg) over setting new cfg - otherwise following will happend
                    // here it would be modifying different cfg (cos Y will change it).
                    // Another problem would be that new cfg would be in parallel modified by Z cos synchronized is applied on new object
                    cfg.b=id;
                }
            }
            if(id == 'Y'){
                mySleep(333);
                synchronized(cfg) // comment this and you will see inconsistency in log - if you keep it I think all is ok
                {
                    cfg = new Config();  // introduce new configuration
                    // be aware - don't expect here to be synchronized on new cfg!
                    // Z might already get a lock
                }
            }
            if(id == 'Z'){
                mySleep(666);
                synchronized (cfg){
                    cfg.a=id;
                    mySleep(100);
                    cfg.b=id;
                }
            }
            System.out.println("Doer "+id+" end");
            cfg.log();
        }
    }

    public static void main(String[] args) throws InterruptedException {
        Doer X = new Doer('X');
        Doer Y = new Doer('Y');
        Doer Z = new Doer('Z');
        X.start();
        Y.start();
        Z.start();
    }

}

Question 7

AtomicReference відповідає вашим вимогам.

З документації Java про атомний пакет:

Невеликий набір інструментів із класів, що підтримують безблокове програмування потоків для окремих змінних. По суті, класи в цьому пакеті розширюють поняття нестабільних значень, полів та елементів масиву до тих, які також забезпечують атомарну умовну операцію оновлення форми:

boolean compareAndSet(expectedValue, updateValue);

Зразок коду:

String initialReference = "value 1";

AtomicReference<String> someRef =
    new AtomicReference<String>(initialReference);

String newReference = "value 2";
boolean exchanged = someRef.compareAndSet(initialReference, newReference);
System.out.println("exchanged: " + exchanged);

У наведеному вище прикладі ви замінюєте StringсвоїмObject

Пов’язане питання SE:

Коли використовувати AtomicReference в Java?

Question 8

Якщо oніколи не змінюється протягом життя екземпляра X, друга версія є кращим стилем незалежно від того, чи задіяна синхронізація.

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

Question 9

Просто додавши свої два центи: у мене було це попередження, коли я використовував компонент, який створюється за допомогою конструктора, тому це поле насправді не може бути остаточним, оскільки конструктор не може приймати параметри. Іншими словами, у мене було квазіфінальне поле без остаточного ключового слова.

Думаю, саме тому це лише попередження: ви, мабуть, робите щось не так, але це може бути і правильно.