Сборка мусора и синхронизированная видимость - PullRequest
0 голосов
/ 15 декабря 2018

Я читал о маркировке объекта как volatile, не гарантирующего видимость его членов ( Я не говорю о безопасности потоков, просто видимость памяти , цитата:

JVM будет считать энергозависимой только ссылку на объект, а не сами данные объекта, которые будут находиться в куче

мои вопросы:

  1. Синхронизация обеспечитвидимость элементов (в одном и том же объекте блокировки) в случае, если они были отредактированы. Это потому, что происходит до конца в конце (освобождение) блокировки , что делает действия видимыми для другого потока
  2. В случае использования volatile на объекте и изменения ссылки на объект, что произойдет, если старая ссылка кэшируется в однопоточном кэше ЦП? Будет ли ГХ поддерживать его живым?

Пример кода:

class Test{
  volatile Data data;

}

Class Data{
 int x;
 int y;
}


data= new Data(); // happens-before relationship only on creation

 //writer
 Thread writerThread = new Thread(() -> {
    data.setX(a);
    data.setY(b);
   });


 //reader
 Thread readerThread = new Thread(() -> {

  // read here is not guaranteed visibility, x,y not volatile
   int x = data.getX(); 
   int y = data.getY();          
  });

1 Ответ

0 голосов
/ 15 декабря 2018
  1. Да, happens-before отношения гарантируют это.В то время как ключевое слово volatile также создает отношение happens-before между потоком записи и потоком чтения.

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

В спецификации языка Java не упоминается ни какой-либо конкретный механизм о том, как реализовать volatile.Так что, думаю, это зависит от конкретной JVM.
...