线程安全问题

问题

线程安全是多线程领域的问题，线程安全可以简单理解为一个方法或者一个实例可以在多线程环境中使用而不会出现问题

在 Java 多线程编程当中，提供了多种实现 Java 线程安全的方式：

1）最简单的方式，使用 Synchronization 关键字
2）使用 java.util.concurrent.atomic 包中的原子类，例如 AtomicInteger
3）使用 java.util.concurrent.locks 包中的锁
4）使用线程安全的集合 ConcurrentHashMap
5）使用 volatile 关键字，保证变量可见性（直接从内存读，而不是从线程 cache 读）

volatile原理

如果一个变量被volatile所修饰的话，在每次数据变化之后，其值都会被强制刷入主存。而其他处理器的缓存由于遵守了缓存一致性协议，也会把这个变量的值从主存加载到自己的缓存中。这就保证了一个volatile在并发编程中，其值在多个缓存中是可见的。

synchronized

synchronized关键字可以用来修饰三个地方：

1.synchronized放在实例方法上，锁对象是当前的this对象
2.synchronized放在类方法上，也就是我们所说的静态方法上，锁对象是方法区中的类对象，是一个全局锁
3.synchronized修饰代码块，也就是synchronized(object){}，锁对象是()中的对象

1）synchronized修饰实例方法：
JVM就是根据该ACC_SYNCHRONIZED标识符来实现方法的同步：当方法被执行时，JVM调用指令会去检查方法上是否设置了ACC_SYNCHRONIZED标识符，如果设置了ACC_SYNCHRONIZED标识符，则会获取锁对象的monitor对象，线程执行完方法体后，又会释放锁对象的monitor对象。在此期间，其他线程无法获得锁对象的monitor对象

2）synchronized修饰静态方法：
synchronized放在实例方法上和放在类方法上的实现原理相同，都是ACC_SYNCHRONIZED标识符去实现的。只是它们锁住的对象不同

3）synchronized修饰代码块：
(1)monitorenter: monitorenter指令表示获取锁对象的monitor对象，这是monitor对象中的count并会加+1，如果monitor已经被其他线程所获取，该线程会被阻塞住，直到count=0,再重新尝试获取monitor对象
(2)monitorexit: monitorexit与monitorenter是相对的指令，表示进入和退出。执行monitorexit指令表示该线程释放锁对象的monitor对象,这时monitor对象的count便会-1变成0，其他被阻塞的线程可以重新尝试获取锁对象的monitor对象

从synchronized放置的位置不同可以得出，synchronized用来修饰方法时，是通过ACC_SYNCHRONIZED标识符来保持线程同步的。而用来修饰代码块时，是通过monitorenter和monitorexit指令来完成

另外：
monitor监视器对象存在于Java对象的对象头Mark Word中，

什么是Java对象头的Mark Word了？这就跟Java对象在JVM中的内存布局有关系，Java对象在JVM内存中分为三块区域：对象头，实例数据和对齐填充。

Mark Word中的锁状态发生的变化：

1.无锁
也就是代表对象的monitor对象并没有被线程所持有，代表的是对象处于无锁状态

2.偏向锁
偏向锁是JDK1.6后面引起的一项锁优化技术，在无锁竞争的情况下，一个线程通过一次CAS操作来尝试将对象头中的Thread ID字段设置为自己的线程号，如果设置成功，则获得锁，那么以后线程再次进入和退出同步块时，就不需要使用CAS来获取锁，只是简单的测试一个对象头中的Mark Word字段中是否存储 着指向当前线程的偏向锁。如果使用CAS设置失败时，说明存在锁的竞争，这时偏向锁便会升级成轻量级锁和重量级锁。偏向锁指的是这个锁会偏向于第一个获得它的线程。

3.轻量级锁
​ 表示线程通过一定的数量CAS操作(JDK1.6后默认10次)完成加锁和解锁操作，如果锁获取失败，会通过自旋来获取，竞争的线程不会阻塞，如果还是获取失败，表示此时存在其他线程竞争锁(两条或两条以上的线程竞争同一个锁)，则轻量级锁会膨胀成重量级锁。

4.重量级锁
​ 当一个锁被两条或两条以上的线程竞争的时候，这时候轻量级锁就会演变成重量级锁。

5.自旋锁
​ 当两个线程去竞争同一把锁时，一个线程获取成功，一个线程获取失败，这时可能会出现获取成功的线程持有锁的时间非常短，如果这时候将获取失败的线程进行挂起的话，会造成功线程上下文的切换，到时候又需要唤醒线程，这时我们可以让获取失败的线程进行一个自旋，无需将线程挂起。等到锁释放。但是这种方案适用于锁被占用的时间很短的情况，如果锁被持有的时间很长，然后线程将会一直处于自旋状态，白白消耗处理器资源。自旋等待的时间必须要有一定的限度，如果超过此数还是没有获取到，则将线程挂起。自旋此数的默认值是10次，可以使用JVM参数-XX:PreBlockSpin来进行更改。

6.自适应自旋锁
​ 自适应自旋锁是在自旋锁的基础上产生的，进行了一次优化。自适应意味着自旋的时间不再固定，而是由前一次在同一个锁上的自旋时间几锁的拥有者的状态来决定的。

synchronized和java.util.concurrent.locks.Lock的异同

Lock 和 synchronized 有一点明显的区别 —— lock 必须在 finally 块中释放。而使用同步，JVM 将确保锁会获得自动释放。Lock锁是对象，而synchronized是java关键字。
一个 Lock 对象和一个 synchronized 代码块之间的主要不同点是：
synchronized 代码块不能够保证进入访问等待的线程的先后顺序， 你不能够传递任何参数给一个 synchronized代码块的入口。因此，对于 synchronized 代码块的访问等待设置超时时间是不可能的事情。 synchronized块必须被完整地包含在单个方法里，而一个 Lock 对象可以把它的 lock() 和 unlock() 方法的调用放在不同的方法里。

乐观锁和悲观锁的理解及如何实现，有哪些实现方式？

乐观锁，每次操作时不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止
悲观锁是会导致其它所有需要锁的线程挂起，等待持有锁的线程释放锁。
乐观锁可以使用volatile+CAS原语实现，带参数版本来避免ABA问题，在读取和替换的时候进行判定版本是否一致
悲观锁可以使用synchronize的以及Lock