【我要去面试】- 锁机制

线程安全问题

线程安全问题是指多个线程同时对某个资源的有序访问或修改，而在这些线程之间没有产生冲突。在JAVA里，线程安全体现在下面两个方面：

1. 多个thread对同一个java实例的访问（read和modify）不会相互干扰，主要体现在synchronized。如ArrayList和Vecor，HashMap和HashTable，（后者类都有synchronized关键字）。如果你在interator一个list对象时，其他线程remove一个element，问题就出现了。
2. 每个线程都有自己的字段，而不会在多个线程之间共享。主要体现在java.lang.ThreadLocal类，而没有java关键字支持，如像static、transient。

volatile实现原理

Volatile 是轻量级的 synchronized，它在多处理器开发中保证了共享变量的“可见性”。可见性的意思是当一个线程修改一个共享变量时，另外一个线程能读到这个修改的值。
Volatile 变量修饰符如果使用恰当的话，它比 synchronized 的使用和执行成本会更低，因为它不会引起线程上下文的切换和调度。

悲观锁和乐观锁

是一种思想，可以用在很多方面。
比如数据方面：
悲观锁是for update（锁定查询的行）
乐观锁就是version字段（比较跟上一次的版本号，如果一样则更新，如果失败则要重复读取比较写操作）
JDK方面：
悲观锁就是sync
乐观锁就是原子类（内部使用CAS实现）
本质来说，就是悲观锁认为总会有人抢我的。
乐观锁就任务，基本没人抢。

CAS乐观锁

乐观锁是一种思想，认为读多写少，遇到并发写的可能性较低，所以采取在写时先读出当前版本号，然后加锁操作（比较跟上一次的版本，如果一样则更新），如果失败要重读比较写的操作。
CAS是一种更新的原子操作，比较当前值跟传入值是否一样，一样则更新，否则失败。
CAS顶多算是乐观锁写那一步操作的一种实现方式，不用CAS自己加锁也是可以的。
ABA问题
如果另外一个线程修改V值假设原来是A，先修改成B，在修改回A，当前线程的CAS操作无法分辨当前V值是否发生过变化。

乐观锁的业务场景及实现方式

每次获取数据的时候，都不会担心数据被修改。所以每次获取数据的时候都不会进行加锁，但是在更新数据的时候需要判断该数据是否被别人修改过。如果数据被其他线程修改，在不进行数据更新，如果数据没有被其他线程修改，在进行更新。由于数据没有加锁，期间该数据可以被其他线程进行读写操作。
比较适合读取数据频繁的场景，如果出现大量的写操作，数据发生冲突的可能性就增大，为了保证数据的一致性，应用层需要不断重新获取数据，这样会增加大量查询操作，降低了系统的吞吐量。