1、synchronized、Lock、volatile

1、synchronized

1.1 synchronized原理

修饰代码块 底层实现，通过 monitorenter & monitorexit 标志代码块为同步代码块。
修饰方法 底层实现，通过 ACC_SYNCHRONIZED 标志方法是同步方法。
修饰类 class 对象时，实际锁在类的实例上面。

单例模式

public class Singleton {
	private static volatile Singleton instance = null;

	private Singleton(){}

	public static Singleton getInstance(){
	if (null == instance) {
   		 synchronized (Singleton.class) {
       		 if (null == instance) {
        	 instance = new Singleton();
        	}
   		 }
  	}
    return instance;
    }
}

偏向锁，自旋锁，轻量级锁，重量级锁
通过 synchronized 加锁，第一个线程获取的锁为偏向锁，这时有其他线程参与锁竞争，升级为轻量级锁，其他线程通过循环的方式尝试获得锁，称自旋锁。如果自旋的次数达到一定的阈值，则升级为重量级锁。
需要注意的是，在第二个线程获取锁时，会先判断第一个线程是否仍然存活，如果不存活，不会升级为轻量级锁。

1.2、synchronized 和 volatile 的区别是什么？

volatile本质是在告诉jvm当前变量在寄存器（工作内存）中的值是不确定的，需要从主存中读取； synchronized则是锁定当前变量，只有当前线程可以访问该变量，其他线程被阻塞住。
volatile仅能使用在变量级别；synchronized则可以使用在变量、方法、和类级别的。
volatile仅能实现变量的修改可见性，不能保证原子性；而synchronized则可以保证变量的修改可见性和原子性。
volatile不会造成线程的阻塞；synchronized可能会造成线程的阻塞。
volatile标记的变量不会被编译器优化；synchronized标记的变量可以被编译器优化。

1.3、synchronized 和 Lock 有什么区别？

首先synchronized是java内置关键字，在jvm层面，Lock是个java类；
synchronized无法判断是否获取锁的状态，Lock可以判断是否获取到锁；
synchronized会自动释放锁(a 线程执行完同步代码会释放锁 ；b 线程执行过程中发生异常会释放锁)，Lock需在finally中手工释放锁（unlock()方法释放锁），否则容易造成线程死锁；
用synchronized关键字的两个线程1和线程2，如果当前线程1获得锁，线程2线程等待。如果线程1阻塞，线程2则会一直等待下去，而Lock锁就不一定会等待下去，如果尝试获取不到锁，线程可以不用一直等待就结束了；
synchronized的锁可重入、不可中断、非公平，而Lock锁可重入、可判断、可公平（两者皆可）；
Lock锁适合大量同步的代码的同步问题，synchronized锁适合代码少量的同步问题。

1.4、synchronized 和 ReentrantLock 区别是什么？

synchronized是和if、else、for、while一样的关键字，ReentrantLock是类，这是二者的本质区别。既然ReentrantLock是类，那么它就提供了比synchronized更多更灵活的特性，可以被继承、可以有方法、可以有各种各样的类变量，ReentrantLock比synchronized的扩展性体现在几点上：

ReentrantLock可以对获取锁的等待时间进行设置，这样就避免了死锁
ReentrantLock可以获取各种锁的信息
ReentrantLock可以灵活地实现多路通知
另外，二者的锁机制其实也是不一样的:ReentrantLock底层调用的是Unsafe的park方法加锁，synchronized操作的应该是对象头中mark word。

2、Lock

a、ReentrantLock
基于 AQS （AbstractQueuedSynchronizer）实现，主要有 state (资源) + FIFO (线程等待队列) 组成。
公平锁与非公平锁：区别在于在获取锁时，公平锁会判断当前队列是否有正在等待的线程，如果有则进行排队。
使用 lock() 和 unLock() 方法来加锁解锁。

b、ReentrantReadWriteLock
同样基于 AQS 实现，内部采用内部类的形式实现了读锁（共享锁）和写锁 （排它锁）。
非公平锁吞吐量高 在获取锁的阶段来分析，当某一线程要获取锁时，非公平锁可以直接尝试获取锁，而不是判断当前队列中是否有线程在等待。一定情况下可以避免线程频繁的上下文切换，这样，活跃的线程有可能获得锁，而在队列中的锁还要进行唤醒才能继续尝试获取锁，而且线程的执行顺序一般来说不影响程序的运行。

2.1、多线程锁的升级原理是什么？

在Java中，锁共有4种状态，级别从低到高依次为：无状态锁，偏向锁，轻量级锁和重量级锁状态，这几个状态会随着竞争情况逐渐升级。锁可以升级但不能降级。

锁升级的图示过程：

2.2、什么是死锁？

死锁是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。是操作系统层面的一个错误，是进程死锁的简称，最早在 1965 年由 Dijkstra 在研究银行家算法时提出的，它是计算机操作系统乃至整个并发程序设计领域最难处理的问题之一。

2.3、怎么防止死锁？

死锁的四个必要条件：

互斥条件：进程对所分配到的资源不允许其他进程进行访问，若其他进程访问该资源，只能等待，直至占有该资源的进程使用完成后释放该资源
请求和保持条件：进程获得一定的资源之后，又对其他资源发出请求，但是该资源可能被其他进程占有，此事请求阻塞，但又对自己获得的资源保持不放
不可剥夺条件：是指进程已获得的资源，在未完成使用之前，不可被剥夺，只能在使用完后自己释放
环路等待条件：是指进程发生死锁后，若干进程之间形成一种头尾相接的循环等待资源关系
这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之 一不满足，就不会发生死锁。

理解了死锁的原因，尤其是产生死锁的四个必要条件，就可以最大可能地避免、预防和 解除死锁。

所以，在系统设计、进程调度等方面注意如何不让这四个必要条件成立，如何确 定资源的合理分配算法，避免进程永久占据系统资源。

此外，也要防止进程在处于等待状态的情况下占用资源。因此，对资源的分配要给予合理的规划。

2.4、javaSE1.6对锁的优化？

在JDK1.5中，synchronized是性能低效的。因为这是一个重量级操作，它对性能大的影响是阻塞的是实现，挂起 线程和恢复线程的操作都需要转入内核态中完成，这些操作给系统的并发性带来了很大的压力
javaSE1.6引入了偏向锁，轻量级锁（自旋锁）后，synchronized和ReentrantLock两者的性能就差不多了
锁可以升级, 但不能降级. 即: 无锁 -> 偏向锁 -> 轻量级锁 -> 重量级锁是单向的.

3、volatile

Java 内存模型

在多线程环境下，保证变量的可见性。使用了 volatile 修饰变量后，在变量修改后会立即同步到主存中，每次用这个变量前会从主存刷新。
禁止 JVM 指令重排序。
单例模式双重校验锁变量为什么使用 volatile 修饰？ 禁止 JVM 指令重排序，new Object()分为三个步骤：申请内存空间，将内存空间引用赋值给变量，变量初始化。如果不禁止重排序，有可能得到一个未经初始化的变量。