Java线程安全之可见性和原子性

Java线程安全

Java线程安全问题，是我们在写多线程程序的时候需要考虑的。
具体一点来说，是当且仅当多线程有共享的变量的时候（堆内存中。堆内存：放实例字段，静态字段和数组元素。共享变量：非局部变量——比如在线程执行方法中的变量；也不是ThreadLocal声明的变量。每个线程有自己的工作内存，主要用于完成代码操作，有虚拟机栈——Java方法，本地方法栈——Native方法，程序计数器——记录当前线程执行字节码的位置。所有线程共享堆内存和方法区）。
再具体一点，是有线程写变量，同时也有线程读或者写共享变量的时候：显而易见地，如果所有线程都只是读共享变量，并不会产生什么冲突。

可见性

可见性，扩句：一个写线程的修改对其他读线程的可见。
比如说，脏读，是没有满足可见性的情况。举例：t1将共享变量v的值从0修改成1，但是t2读的时候，读到的还是0.
造成脏读的原因：

• CPU的缓存机制：正常数据都存在主内存（main memory），但是读写都比较慢，所以CPU做了一点优化：在CPU内使用cache，缓存部分数据。 从多线程的角度上来说，就是，每个线程可能有自己的cache，并且，不一定什么时候更新到主内存的值。对于写和读都是如此，我们无法决定CPU什么时候把值从缓存写到主内存，或者从主内存读到缓存，所以就有了滞后性，可能造成脏读。
• 指令重排：缓存机制造成的脏读，只是一时性的。但是指令重排（as-if-serial，重新排列指令，在单个线程结果不会改变的条件上，所以，在多线程的情况下，这种顺序改变，可能造成使用的是其他线程修改之前的值），可能造成永久性的脏读。CPU会做这种指令重排；Java编译器也会做：JIT (Just In Time)编译。Java程序的运行过程是，先被Java编译器编译成字节码文件（这里没有任何性能优化），然后被JVM解释运行，一行行的。从这个角度上来说，Java是脚本语言。但是！这样很耗时间，比如在循环之中，JIT编译器就会编译重复解释的语句以提高性能：编译完后放在方法区，下次跑的时候就不解释了，直接去拿。从这个角度上来说，Java是编译语言。总而言之，Java是两者的结合，并且，在JIT升级编译的过程中，JVM会进行上述可能产生问题的指令重排

Java制定的规范：Java内存模型（描述多线程程序的语义）规定了volatile关键字，需要实现：对被此关键字修饰的变量的写操作，需要对之后所有的读操作同步。这样，用volatile关键字修饰的变量，就不会产生脏读问题了：所有的读，读到的都一定是更新的写之后的数据。
JVM的实现方法：禁止CPU缓存；对volatile变量相关的指令不做指令重排（反过来说，也就是：只有指令重排影响到可见性的时候，才会禁止）。
其他的例子：读写操作扩展开来，就是：一个程序执行的操作可被其他线程感知或被其他线程直接影响。具体的例子有：Lock, Unlock；db数据修改，等等。对于所有的线程间操作，都存在可见性问题，JMM都作了规范。
重申：脏读，即是想定了，只有一个线程写，其他都是读的情况。如果有多个线程写？详见下文。

原子性

原子性，意即一个操作的不可分割性——如果分割了，可能会产生失效。
比如说，脏写。举例：t1和t2一起读了v的值：1，然后t1进行+1操作，把v的值从1变成了2，写回；t2同理，也想进行+1操作，于是把v的值从1变成了2，也写回了。这样，我们第一次的写操作就丢失了。或者说，从t1写回了的那个时间点开始，t2拿到的v的值实际上就已经失效/过期/不合法了。
Naive的解决方法：直接用synchronized保证一时间只有一个线程进行这个操作，或者用ReentrantLock在操作前后加锁、解锁，实现同样效果。但是这样的话，并发度只有1:一时间只有一个能操作。如何加速？
聪明的解决办法：有点像乐观锁的思想，就是总之先操作，然后看操作的合法性——写回的时候，如何看操作的合法性？记录变化前的旧值，和内存中的值进行比较；如果没有变化，才交换新值。这个比较和交换操作（CAS）是一个从硬件层面上保证的原子操作，所以保证了不会在这期间有冲突。如果有变化的话，则从头开始任务。如此不断循环，直到成功（自旋）。实际上，AtomicInteger的，比如incrementAndGet方法就是这么做的。
一些随之产生的问题：

1. 不断循环，消耗CPU（实际上碰撞的几率不高；如果并发实在是大的话，就参照Map/Reduce的思想，多创建几个可操作的对象，减少失败率，最后sum up）；
2. CAS是仅针对单个变量的原子操作（虽然可以通过创建对象的方式规避）；
3. ABA问题：我们只比较了旧值，如果有操作多次修改而值没有改变？那我们的目标：保持共享变量的合法性，就还是没有达到（可以通过增加修改版本号的方式解决）。