почему мой собственный AtomicLong работает медленнее, чем тот, что есть в JDK? - PullRequest
Новая
       35

почему мой собственный AtomicLong работает медленнее, чем тот, что есть в JDK?

1 голос
/ 20 апреля 2019

Я писал свой собственный класс AtomicLong, и я только что обнаружил, что моя функция намного медленнее, чем та, которая предусмотрена в классе Unsafe.Мне интересно, почему?

Ниже приведены коды, которые у меня есть: 

public interface Counter {
    void increment();
    long get();
}


public class PrimitiveUnsafeSupportCounter implements Counter{

    private volatile long count = 0;
    private Unsafe unsafe;
    private long offset;

    public PrimitiveUnsafeSupportCounter() throws IllegalAccessException, NoSuchFieldException {
        Field f = Unsafe.class.getDeclaredField("theUnsafe");
        f.setAccessible(true);
        this.unsafe = (Unsafe) f.get(null);
        this.offset = this.unsafe.objectFieldOffset(PrimitiveUnsafeSupportCounter.class.getDeclaredField("count"));
    }

    @Override
    public void increment() {

        this.unsafe.getAndAddLong(this, this.offset, 1);
    }

    @Override
    public long get() {
        return this.count;
    }
}

public class CounterThread implements Runnable {

    private Counter counter;

    public CounterThread(Counter counter){
        this.counter = counter;
    }
    @Override
    public void run() {

        for (int i = 0; i < 100000; i ++){
            this.counter.increment();
        }
    }
}

class Test{

    public static void test(Counter counter) throws NoSuchFieldException, IllegalAccessException, InterruptedException {

        ExecutorService executor = Executors.newFixedThreadPool(1000);

        long start = System.currentTimeMillis();
        for (int i = 0 ; i < 1000; i++){
            executor.submit(new CounterThread(counter));
        }

        executor.shutdown();
        executor.awaitTermination(1, TimeUnit.MINUTES);
        long stop = System.currentTimeMillis();

        System.out.println(counter.get());
        System.out.println(stop - start);
    }

}

public class Main {
    public static void main(String[] args) throws NoSuchFieldException, IllegalAccessException, InterruptedException {

        Counter primitiveUnsafeSupportCounter = new PrimitiveUnsafeSupportCounter();
        Test.test(primitiveUnsafeSupportCounter);

    }

}

Чтобы завершить приведенные выше коды, требуется около 3000 мс.однако, если я использовал приведенные ниже коды вместо this.unsafe.getAndAddLong(this, this.offset, 1);. 

long before;
do {
     before = this.unsafe.getLongVolatile(this, this.offset);
} while (!this.unsafe.compareAndSwapLong(this, this.offset, before, before + 1));

, мне понадобилось бы даже 7000 мс., так что я должен пропустить?

1 Ответ

0 голосов
/ 20 апреля 2019

Это версия встроенного и рукописного цикла JVM, в которой для этой цели используется неэффективный скомпилированный код.На x86 вы можете иметь атомарную версию таких операций чтения-изменения-записи через префикс lock.См. Руководство Intel 8.1.2.2 Программно-управляемая блокировка шины :

Для явного форсирования семантики LOCK программное обеспечение может использовать префикс LOCK со следующими инструкциями, когда они используются для измененияячейка памяти.

В частности, вы можете иметь что-то вроде lock add op1 op2.В вашем примере вы проверяете результат cmpxchg и делаете некоторый прыжок, который явно медленнее.Кроме того, насколько я помню, для x86 энергозависимый доступ требует некоторого вида mfence или lock для обеспечения упорядочения памяти.

...