Как продемонстрировать проблемы видимости многопоточности Java?

Заставьте их прочитать книгу Java Concurrency in Practice гуру параллелизма Java Брайана Гетца. Эта книга - обязательное чтение для любого, кому приходится писать серьезное параллельное программное обеспечение на Java!

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

Может ли кто-нибудь предоставить пример программы / фрагмента Java, который надежно показывает проблемы с видимостью данных.

Нет, не существует надежного примера, который показывает проблемы с видимостью данных.

Причина в том, что любое допустимое выполнение программы с volatile также является допустимым выполнением той же программы без volatile . (Однако обратное, очевидно, неверно!)

Наиболее распространенным примером, подчеркивающим важность использования volatile, является пример while (keepRunning) :

public class Test extends Thread {

    boolean keepRunning = true;

    public static void main(String[] args) throws InterruptedException {
        Test t = new Test();
        t.start();
        Thread.sleep(1000);
        t.keepRunning = false;
        System.out.println(System.currentTimeMillis() + ": keepRunning is false");
    }

    public void run() {
        while (keepRunning) 
            System.out.println(System.currentTimeMillis() + ": " + keepRunning);
    }
}

Поскольку keepRunning ] может (допустимо) храниться в кэше потока, выполняющего цикл while, эта программа может выводить «истина» для keepRunning еще долгое время после того, как для keepRunning установлено значение false.

Однако обратите внимание на , что не существует надежного способа выявления условий гонки. (См. Мой другой ответ.) Этот пример может раскрыть его при определенных обстоятельствах на определенных комбинациях оборудования / операционной системы / jvm.

У меня есть для вас фрагмент кода:

package test;

public class LoopTest {

 private boolean done = false;

 /**
  * @param args
  */
 public void start() {
  System.out.println(System.getProperty("java.vm.name"));
  System.out.println(System.getProperty("java.version"));
  for (int i = 0; i < 100; i++) {
   startNewThread();
  }

  try {
   Thread.sleep(1000);
  } catch (InterruptedException e) {
   e.printStackTrace();
  }
  done = true;
  System.out.println("forcing end");
 }

 private void startNewThread() {
  new Thread(new Runnable() {

   public void run() {
    long i = 0;
    while(!done) {
     i++;
     if(i % 100L == 0) {
      System.out.println("still working " + i);
     }
    }
    System.out.println("ending " + i);
   }

  }).start();
 }

 public static void main(String[] args) {
  new LoopTest().start();
 }

}

Этот пример, запущенный в режиме сервера JVM, сгенерировал следующие выходные данные на моей машине:

..
..
ending 14100
still working 14800
ending 14800
still working 26500
ending 26500
still working 18200
ending 18200
still working 9400
ending 9400
still working 1300
ending 1300
still working 59500
ending 59500
still working 1700
still working 75400
ending 75400
still working 33500
ending 33500
still working 36100
ending 36100
still working 121000
ending 121000
still working 3000
ending 3000
ending 1700
still working 5900
ending 5900
still working 7800
ending 7800
still working 7800
ending 7800
still working 6800
ending 6800
still working 5300
ending 5300
still working 9100
still working 10600
ending 10600
still working 9600
ending 9600
still working 10000
ending 10000
ending 9100
still working 1700
ending 1700
..
..

Посмотрите на " Завершающие операторы # ": все они имеют число, кратное 100, что, я думаю, маловероятно. Моя интерпретация заключается в том, что существует проблема видимости, из-за которой потоки все еще читают done == false, хотя он уже был обновлен до true. После вызова синхронизированного метода System.out.println () с оператором "still working #" потоки считывают обновленное значение для done и завершают работу.

Или кто-нибудь видит ошибку в моем коде / интерпретации?