Действительно ли AtomicInteger производит атомарное целое число?

Одна из основных проблем с вашим кодом заключается в том, что вы добавляете числа в HashSet, который не является потокобезопасным. Это причина того, что вы наблюдаете. Если вы использовали потокобезопасную коллекцию, вы получите ожидаемый результат:

final Set<Integer> integers = new ConcurrentSkipListSet<>();

Но это вводит дополнительный уровень синхронизации. Другой альтернативой является использование простого массива int[] numbers = new int[1000]; и использование: numbers[next-1]++; для подсчета вхождений.

Новый код для справки:

public static void main(String[] args) throws Exception {

    final AtomicInteger sequencer = new AtomicInteger(1);
    final int[] integers = new int[1000];

    final Runnable task = new Runnable() {

        @Override
        public void run() {
            int next = sequencer.getAndIncrement();
            integers[next-1]++;
        }
    };
    List<Thread> threads = new ArrayList<>();
    for (int i = 0; i < 1000; i++) {
        Thread t = new Thread(task);
        t.start();
        threads.add(t);
    }
    for (Thread t : threads) {
        t.join();
    }
    for (int i = 0; i < 1000; i++) {
        if (integers[i] != 1) System.out.println(i + " -> " + integers[i]);
    }
}

Если я запускаю вашу программу на своем компьютере, я наблюдаю неправильный вывод примерно в 1 из 10 раз. (Это с эмулятором консоли в Netbeans 7.)

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

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

public static void main(String[] args) throws InterruptedException {

    final AtomicInteger sequencer = new AtomicInteger(1);
    final Set<Integer> integers = new ConcurrentSkipListSet<Integer>();

    final Runnable task = new Runnable() {

        @Override
        public void run() {
            int next = sequencer.getAndIncrement();
            integers.add(next);
            System.out.println(next);
        }
    };
    List<Thread> threads = new ArrayList<Thread>(1000);
    for (int i = 0; i < 1000; i++) {
        Thread t = new Thread(task);
        t.start();
        threads.add(t);
    }

    for (Thread t : threads) {
        t.join();
    }
    System.out.println(integers.size());
}

AtomicInteger вызывает класс Unsafe, который, в свою очередь, выполняет собственные вызовы. Так что да, AtomicInteger теоретически может возвращать неатомарные обновления. Это будет зависеть от JVM и базовой архитектуры, на которой она работает.

Однако, учитывая характер потоков, я всегда предполагаю, что ошибка в моем коде, а не в JVM.

Я запустил этот код и не смог обнаружить никаких столкновений. JDK 1_7_45 победа 7

  public static void main(String[] args) {

      final AtomicInteger sequencer = new AtomicInteger(1);
      final Set<Integer> integers = new HashSet<Integer>();

      final Runnable task = new Runnable() {

          @Override
          public void run() {
              int next = sequencer.getAndIncrement();
              synchronized (integers){
                  if(integers.contains(next)){
                      System.out.println("duplicate detected " + next);
                  }
                  integers.add(next);
              }
          }
      };


      for(int j = 0; j < 1000; j++){
          System.out.print("testing " + j +" ");
          sequencer.set(0);
          integers.clear();
          List<Thread> threads = new ArrayList<Thread>(10000);
          for (int i = 0; i < 1000; i++) {
              Thread t = new Thread(task);
              threads.add(t);
              t.start();
          }
          for (Thread t : threads) {
              try {
                  t.join();
              } catch (InterruptedException e) {
                  e.printStackTrace();
              }
          }
          System.out.println("integers size " + integers.size());
      }
  }

Как говорили другие:

1. Дождитесь завершения всех потоков в конце цикла, используя Thread.join(). Ссылки на все потоки должны быть сохранены в коллекции, конечно
2. close() STDOUT перед выходом

Вокруг программы:

1. Направьте вывод через sort и/или wc -l
2. Используйте diff для проверки списка чисел, созданного простым циклом
3. Выход с предупреждением, если diff находит разницу

Повторите 10 000 раз в запрограммированном цикле.

Доложить.

Обновленный вывод содержит 7 целых чисел, напечатанных дважды.

(взял ваш вывод | sort | uniq --count | sort )

печатает это в конце (первый столбец - это количество просмотров, 2-й столбец - это значение)

  1 991
  1 992
  1 993
  2 519
  2 52
  2 661
  2 848
  2 875
  2 985
  2 995

Это связано с тем, что вы печатаете размер HashSet, который не является потокобезопасным, поэтому иногда размер не показывает обновленное значение.

Переход на поточно-ориентированную реализацию Set должен работать.

Для меня это из-за ConcurrentSkipListSet.size(). Этот тип слабо согласованной коллекции, хотя и потокобезопасный, не является точным в отношении итераций или подсчета в целом.

Из Javadoc ConcurrentSkipListSet.size()

Имейте в виду, что, в отличие от большинства коллекций, метод size не является операцией с постоянным временем. Из-за асинхронного характера этих наборов определение текущего количества элементов требует обхода элементов. Кроме того, не гарантируется атомарное выполнение массовых операций addAll, removeAll, keepAll и containsAll. Например, итератор, работающий одновременно с операцией addAll, может просматривать только некоторые добавленные элементы.