Synchronized同步关键字和Lock锁

1.Synchronized同步关键字

1.1.Synchronized同步关键字简介

synchronized是属于JVM层面的一个关键字,底层是通过一个monitor对象(/管程对象)来完成,由于wait()/notify()等方法也依赖于monitor对象,所以只有在同步的块或者方法中才能调用wait/notify等方法

1.2.同步代码块中synchronized底层实现

说明:

1. Synchronized同步语句块的实现使用的是monitorenter 和 monitorexit 指令,其中monitorenter指令指向同步代码块的开始位置,monitorexit指令则指明同步代码块的结束位置,当执行monitorenter指令时,当前线程将试图获取 objectref(即对象锁) 所对应的 monitor 的持有权,当 objectref 的 monitor 的进入计数器为 0,那线程可以成功取得 monitor,并将计数器值设置为 1,取锁成功.如果当前线程已经拥有 objectref 的 monitor 的持有权,那它可以重入这个 monitor (关于重入性稍后会分析),重入时计数器的值也会加 1.倘若其他线程已经拥有 objectref 的 monitor 的所有权,那当前线程将被阻塞,直到正在执行线程执行完毕,即monitorexit指令被执行,执行线程将释放 monitor(锁)并设置计数器值为0,其他线程将有机会持有 monitor ;
2. 为了保证在方法异常完成时 monitorenter 和 monitorexit 指令依然可以正确配对执行,编译器会自动产生一个异常处理器,这个异常处理器声明可处理所有的异常,它的目的就是用来执行 monitorexit 指令.从字节码中也可以看出多了一个monitorexit指令,它就是异常结束时被执行的释放monitor 的指令;

1.1.1.monitorenter(进入管程对象)

每个对象有一个管程对象(monitor),当monitor被占用时就会处于锁定状态;线程执行monitorenter指令时尝试获取monitor的所有权,过程如下:

1. 如果monitor的进入计数器为0,则该线程进入monitor,然后将进入计数器设置为1,该线程即为monitor的所有者;
2. 如果线程已经之前占用了该monitor,本次只是重新进入,则将monitor的进入计数器加1;
3. 如果其他线程已经占用了monitor,则该线程进入阻塞状态,直到monitor的进入计数器为0,再重新尝试获取monitor的所有权;

1.1.2.monitorexit(退出管程对象,有两个)

1. 执行monitorexit的线程必须是objectref(即对象锁)所对应的monitor的所有者;
2. 指令执行时,monitor的进入计数器减1,如果减1后进入计数器为0,那线程退出monitor,不再是这个monitor的所有者.其他被这个monitor阻塞的线程可以尝试去获取这个 monitor 的所有权.

1.3.同步方法中synchronized底层实现

说明:

方法级的同步是隐式,即无需通过字节码指令(monitorenter和monitorexit)来控制的,它实现在方法调用和返回操作之中.JVM可以从方法常量池中的方法表结构(method_info Structure) 中的 ACC_SYNCHRONIZED 访问标志区分一个方法是否同步方法.当方法调用时,调用指令将会检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置,如果设置了,执行线程将先持有monitor（虚拟机规范中用的是管程一词）,然后再执行方法,最后在方法完成(无论是正常完成还是非正常完成)时释放monitor.在方法执行期间,执行线程持有了monitor,其他任何线程都无法再获得同一个monitor.如果一个同步方法执行期间抛出了异常,并且在方法内部无法处理此异常,那这个同步方法所持有的monitor将在异常抛到同步方法之外时自动释放.

2.Lock锁

2.1.Lock锁简介

1. Lock是Java并发包(java.util.concurrent)下的一个具体类,他是API层面的锁;
2. Lock主要是通过CAS和ASQ(AbstractQueuedSynchronizer)来实现,通过加锁和解锁的过程来分析锁的实现;总体来讲线程获取(非公平)锁要经历以下过程:
   ①.调用lock方法,会先进行cas操作看下设置同步状态1可否成功,如果成功执行临界区代码
   ②.如果不成功获取同步状态,如果状态是0那么cas设置为1;
   ③.如果同步状态既不是0也不是自身线程持有,那就说明当前锁资源已经被其他线程占用,当前线程需要等待,那么会把当前线程构造成一个节点.
   ④.把当前线程节点以CAS的方式放入队列中,行为上线程阻塞,内部自旋获取同步状态.
   ⑤.线程释放锁,唤醒队列第一个节点,参与竞争.重复上述.

2.2.Lock非公平锁实现细节

AbstractQueuedSynchronizer会把所有的请求线程构成一个CLH队列,当一个线程执行完毕（lock.unlock()）时会激活自己的后继节点,但正在执行的线程并不在队列中,而那些等待执行的线程全部处于阻塞状态,经过调查线程的显式阻塞是通过调用LockSupport.park()完成,而LockSupport.park()则调用sun.misc.Unsafe.park()本地方法,再进一步,HotSpot在Linux中中通过调用pthread_mutex_lock函数把线程交给系统内核进行阻塞.

2.3.Lock方法实现

当有线程竞争锁时,当前线程会首先尝试获得锁而不是在队列中进行排队等候,这对于那些已经在队列中排队的线程来说显得不公平,这也是非公平锁的由来.源码如下 :
对于刚来竞争的线程首先会通过CAS设置状态,如果设置成功那么直接获取锁,执行临界区的代码,反之调用acquire(1)进入同步队列中.如果已经存在Running线程,那么CAS肯定会失败,则新的竞争线程会通过CAS的方式被追加到队尾.

2.3.1.解析acquire（1）方法

当CAS设置同步状态为1失败时才会执行上面的代码,上面的代码的作用是完成同步状态的获取,构造用于放入队列中的节点(可以理解为线程任务),加入到队列中,单个节点自己自旋用于检查目前队列中的状况以及当前节点或者是线程阻塞.该方法主要由以下几个方法构成 tryAcquire() ,addWaiter()和AcquireQueued();

2.3.2.acquireQueued(addWaiter(Node mode))方法

acquireQueued()方法的主要作用是把已经追加到队列的线程节点（addWaiter()方法返回值）进行阻塞,但阻塞前又通过tryAccquire重试是否能获得锁,如果重试成功能则无需阻塞,直接返回; 仔细看看这个方法是个无限循环,感觉如果p == head && tryAcquire(arg)条件不满足循环将永远无法结束,当然不会出现死循环,parkAndCheckInterrupt()方法会把当前线程挂起,从而阻塞住线程的调用栈.

2.3.3.addWaiter(Node mode)方法

addWaiter()方法负责把当前无法获得锁的线程包装为一个Node添加到队尾.
其中参数mode是独占锁还是共享锁,默认为null,独占锁.追加到队尾的动作分两步： 1、如果当前队尾已经存在(tail!=null),则使用CAS把当前线程更新为Tail; 2、如果当前Tail为null或则线程调用CAS设置队尾失败,则通过enq()方法继续设置Tail;