++操做的线程安全性及相关问题

众所周知，++操做并非线程安全的。这篇文章主要讲述其非线程安全的缘由以及相关问题。

使用volatile修饰仍不是线程安全的缘由

i++分为如下3步：

1. 从内存中读取到count
2. count+1
3. 将结果写回内存

这3步每一步之间都是能够被中断的，加volatile只是保证从内存中读取到的count值是最新的值，可是存在在别的线程中的count还未写回主存的可能。

例如：

1. 线程A读取到count为10，此时线程中断
2. 线程B读取到count也为10，线程B进行++操做，结果为11写回主存，
3. 此时线程A恢复，因为它已经从内存中读到count了，因此它仍会从10开始加，获得11写回主存。
4. 咱们能够发现，10++在线程A,B各自进行了一次

线程安全的写法

加锁

public class ThreadTest implements Runnable {
    int count = 0;

    @Override
    public void run() {
        synchronized (this) {
            for (int i = 0; i < 100000; i++) {
                count++;
            }
        }
    }

    public static void main(String[] args) throws ExecutionException, InterruptedException {
        Runnable runnable = new ThreadTest();
        ExecutorService executorService = Executors.newFixedThreadPool(3);
        Future f1, f2;
        f1 = executorService.submit(runnable);
        f2 = executorService.submit(runnable);
        f1.get();
        f2.get();
        System.out.println(((ThreadTest) runnable).count);
        executorService.shutdown();
    }
}

使用原子类

原子类能够的单一操做都是原子性的。它的实现并非依赖于加锁而是使用CAS。

CAS的基本原理以下：

从内存位置V中读取值A，并根据A计算值B，而后再将值B写回V。
可是写回V以前，会检查内存位置V的值是否等于A，若是不等于，就不会将值写回V。而是从新进行一次上述操做。

public class ThreadTest2 implements Runnable {
    AtomicInteger count = new AtomicInteger();

    @Override
    public void run() {
        synchronized (this) {
            for (int i = 0; i < 100000; i++) {
                count.getAndIncrement();
            }
        }
    }

    public static void main(String[] args) throws ExecutionException, InterruptedException {
        Runnable runnable = new ThreadTest2();
        ExecutorService executorService = Executors.newFixedThreadPool(3);
        Future f1, f2;
        f1 = executorService.submit(runnable);
        f2 = executorService.submit(runnable);
        f1.get();
        f2.get();
        System.out.println(((ThreadTest2) runnable).count.get());
        executorService.shutdown();
    }
}

性能问题

加锁固然会必定程度上影响性能，可是正确性优于性能。

使用java.util.concurrent.atomic中的原子类在不少状况下都有着优于锁的性能，可是在本例中并非如此。我认为是由于compare比较错误次数太多，重复次数太多致使的。