Приращение AtomicInteger ведет себя не так, как ожидалось

Вы упускаете из виду, что HashSet не является потокобезопасным. Кроме того, свойства набора сотрут все повторяющиеся числа, поэтому ваш тест завершится ошибкой, если AtomicInteger не будет потокобезопасным.

Вместо этого попробуйте использовать ConcurrentLinkedQueue.

Редактировать: Потому что это было задано дважды: использование синхронизированного набора работает, но разрушает идею использования алгоритма без блокировки, такого как классы Atomic. Если в приведенном выше коде вы замените набор синхронизированным набором, то потоки должны будут блокироваться каждый раз, когда вызывается add.

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

HashSet не является потокобезопасным, поэтому вы сталкиваетесь с проблемой. Вы можете использовать Vector или любой класс коллекции, который является потокобезопасным, или запускать два потока последовательно, если вам строго необходимо использовать HashSet.

t1.start();
t1.join();

t2.start();
t2.join();

Как упоминалось в нескольких ответах, он терпит неудачу из-за того, что HashSet не является потокобезопасным.

Во-первых, давайте проверим ради вашего теста, что AtomicInteger действительно потокобезопасен, а затем перейдем к тому, почему ваш тест не удался. Немного измените свой тест. Используйте два набора хэшей, по одному для каждого потока. Наконец, после соединений объедините второй набор с первым, перебирая второй и добавляя его к первому, что устранит дубликаты (свойство набора). Затем сделайте счет в первом подходе. Счет будет таким, как вы ожидаете. Это доказывает, что HashSet не является потокобезопасным, а не AtomicInteger.

Итак, давайте посмотрим, какой аспект не является потокобезопасным. Вы делаете только add(), поэтому ясно, что add() - это операция, которая не является потокобезопасной, что приводит к потере чисел. Давайте посмотрим на пример псевдокода HashMap add(), небезопасного для потоков, который будет терять числа (очевидно, это не так, как он реализован, просто попробуем указать один способ, которым он может быть небезопасным для потоков):

class HashMap {
 int valueToAdd;
 public add(int valueToAdd) {
   this.valueToAdd = valueToAdd;
   addToBackingStore(this.valueToAdd);
 }
}

Если несколько потоков вызывают add() и все они достигают addToBackingStore() после изменения this.valueToAdd, добавляется только окончательное значение valueToAdd, все остальные значения перезаписываются и теряются.

Что-то подобное, вероятно, произошло в вашем тесте.

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

public class Sequencer {

    private final AtomicInteger i = new AtomicInteger(0);

    public static void main(String[] args) {

        final Sequencer seq = new Sequencer();

        final Set<Integer> notSafe = new HashSet<Integer>();
        final Set<Integer> set = Collections.synchronizedSet(notSafe);
        Thread t1 = new Thread(new Runnable() {
            @Override
            public void run() {
                for (int i = 0; i < 500; i++)
                    set.add(seq.getNext());

            }
        }, "T1");
        t1.start();


        Thread t2 = new Thread(new Runnable() {
            @Override
            public void run() {
                for (int i = 0; i < 500; i++)
                    set.add(seq.getNext());

            }
        }, "T2");

        t2.start();

        try {
            t1.join();
            t2.join();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        System.out.println(set.size());

    }

    public int getNext() {
        return i.incrementAndGet();
    }
}