先说明下，本文要讨论的多线程读写是指一个线程写，一个或多个线程读，不包括多线程同时写的状况。html
试想下这样一个场景：一个线程往hashmap中写数据，一个线程往hashmap中读数据。 这样会有问题吗？若是有，那是什么问题？java
相信你们都知道是有问题的，但至于究竟是什么问题，可能就不是那么显而易见了。mysql
问题有两点。
一是内存可见性的问题，hashmap存储数据的table并无用voliate修饰，也就是说读线程可能一直读不到数据的最新值。
二是指令重排序的问题，get的时候可能获得的是一个中间状态的数据，咱们看下put方法的部分代码。sql
final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
boolean evict) {
...
if ((p = tab[i = (n - 1) & hash]) == null)
tab[i] = new Node<>(hash, key, value, next);
...
}
复制代码
能够看到，在put操做时，若是table数组的指定位置为null，会建立一个Node对象，并放到table数组上。但咱们知道jvm中 tab[i] = new Node<>(hash, key, value, next);这样的操做不是原子的，而且可能由于指令重排序，致使另外一个线程调用get取tab[i]的时候，拿到的是一个尚未调用完构造方法的对象，致使不可预料的问题发生。数据库
上述的两个问题能够说都是由于HashMap中的内部属性没有被voliate修饰致使的，若是HashMap中的对象所有由voliate修饰，则一个线程写，一个线程读的状况是不会有问题（这里是个人猜想，证明这个猜想正确性的一点依据是ConcurrentHashMap的get并无加锁，也就是说在Map结构里读写实际上是不冲突）。见下方区sora-zero同窗的评论数组
有的同窗对于 Object obj = new Object();这样的操做在多线程的状况下会拿到一个未初始化的对象这点可能有疑惑，这里也作个简单的说明。以上java语句分为4个步骤：bash
以上步骤看起来也是没有问题的，毕竟建立的对象要调用完构造方法后才会被引用。多线程
但问题是jvm是会对指令进行重排序的，重排以后多是第4步先于第3步执行，那这时候另一个线程读到的就是没有还执行构造方法的对象，致使未知问题。jvm重排只保证重排前和重排后在单线程中的结果一致性。架构
注意java中引用的赋值操做必定是原子的，好比说a和b均是对象的状况下不论是32位仍是64位jvm，a=b操做均是原子的。但若是a和b是long或者double原子型数据，那在32位jvm上a=b不必定是原子的（看jvm具体实现），有多是分红了两个32位操做。 可是对于voliate的long,double 变量来讲，其赋值是原子的。mvc
具体能够看这里docs.oracle.com/javase/spec…
跳出hashmap，在数据库中都是要用mvcc机制避免加读写锁。也就是说若是不用mvcc，数据库是要加读写锁的，那为何数据库要加读写锁呢？缘由是写操做不是原子的，若是不加读写锁或mvcc，可能会读到中间状态的数据，以HBase为例，Hbase写流程分为如下几个步骤：
1.得到行锁
2.开启mvcc
3.写到内存buffer
4.写到append log
5.释放行锁
6.flush log
7.mvcc结束（这时才对读可见）
试想，若是没有不走 2，7 也不加读写锁，那在步骤3的时候，其余的线程就能读到该数据。若是说3以后出现了问题，那该条数据实际上是写失败的。也就是说其余线程曾经读到过不存在的数据。
同理，在mysql中，若是不用mvcc也不用读写锁，一个事务还没commit，其中的数据就能被读到，若是用读写锁，一个事务会对中更改的数据加写锁，这时其余读操做会阻塞，直到事务提交，对于性能有很大的影响，因此大多数状况下数据库都采用MVCC机制实现非锁定读。
原文：Java架构笔记