Java多线程运行环境中，在哪些情况下会使对象锁释放？
释放锁：

（1）执行完同步代码块，就会释放锁。（synchronized）
（2）在执行同步代码块的过程中，遇到异常而导致线程终止，锁也会被释放。（exception）
（3）在执行同步代码块的过程中，执行了锁所属对象的wait()方法，这个线程会释放锁，进入对象的等待池。(wait)

不释放锁的情况：

在下面情况下，线程是不会释放锁的：
（1）执行同步代码块的过程中，执行了Thread.sleep()方法，当前线程放弃CPU，开始睡眠，在睡眠中不会释放锁。
（2）在执行同步代码块的过程中，执行了Thread.yield()方法，当前线程放弃CPU，但不会释放锁。
（3）在执行同步代码块的过程中，其他线程执行了当前线程对象的suspend()方法，当前线程被暂停，但不会释放锁

interrupted()和isInterrupted()方法

//中断线程，并清除中断状态（中断的线程，复位其中断状态为false）（实例方法）
public void Thread.interrupt();
//判断线程是否被中断，不会复位中断状态（实例方法）
public boolean Thread.isInterrupted();
//判断是否被中断并清除当前中断状态（静态方法）
public static boolean Thread.interrupted();

synchronized依赖于java头对象进行加锁
java头对象

java对象头

32位jvm中的对象头Mark word，2bit的锁标志
无锁情况下，mark work记录了对象的分代年龄等GC信息、hash code
重量级锁的mark word指向mointer的起始地址，当一个 monitor 被某个线程持有后，它便处于锁定状态。
同步语句块：
其实现使用的是monitorenter 和 monitorexit 指令，其中monitorenter指令指向同步代码块的开始位置，monitorexit指令则指明同步代码块的结束位置，当执行monitorenter指令时，当前线程将试图获取 objectref(即对象锁) 所对应的 monitor 的持有权，当 objectref 的 monitor 的进入计数器为 0，那线程可以成功取得 monitor，并将计数器值设置为 1，取锁成功。如果当前线程已经拥有 objectref 的 monitor 的持有权，那它可以重入这个 monitor (关于重入性稍后会分析)，重入时计数器的值也会加 1。倘若其他线程已经拥有 objectref 的 monitor 的所有权，那当前线程将被阻塞，直到正在执行线程执行完毕，即monitorexit指令被执行，执行线程将释放 monitor(锁)并设置计数器值为0 ，其他线程将有机会持有 monitor 。值得注意的是编译器将会确保无论方法通过何种方式完成，方法中调用过的每条 monitorenter 指令都有执行其对应 monitorexit 指令，而无论这个方法是正常结束还是异常结束
同步方法：
JVM可以从方法常量池中的方法表结构(method_info Structure) 中的 ACC_SYNCHRONIZED 访问标志区分一个方法是否同步方法。

JVM对synchronized的优化
偏向锁->轻量级锁->....自旋锁....->重量级锁 （只能锁升级，不能降级）
Monitor:
monitor为线程私有的数据结构，同时有一个全局的可用列表。每一个锁住的对象都会和monitor有关联（对象头的lock word中的mark word指向monitor的起始位置），Monitor的owner字段会记录当前获得锁的线程的唯一标识，其结构如下：

monitor

锁粗化：
我们知道在使用同步锁的时候，需要让同步块的作用范围尽可能小—仅在共享数据的实际作用域中才进行同步，这样做的目的是为了使需要同步的操作数量尽可能缩小，如果存在锁竞争，那么等待锁的线程也能尽快拿到锁。
在大多数的情况下，上述观点是正确的。但是如果一系列的连续加锁解锁操作，可能会导致不必要的性能损耗，所以引入锁粗话的概念。
锁粗话概念比较好理解，就是将多个连续的加锁、解锁操作连接在一起，扩展成一个范围更大的锁。如上面实例：vector每次add的时候都需要加锁操作，JVM检测到对同一个对象（vector）连续加锁、解锁操作，会合并一个更大范围的加锁、解锁操作，即加锁解锁操作会移到for循环之外。stringBuffer的append()方法同理

偏向锁：
引入偏向锁的目的是：在无锁竞争的情况下，为了避免不必要的轻量级锁的CAS操作而引入的。那么偏向锁是如何避免不必要的CAS操作呢？只需要检测锁标识、是否为偏向锁及thread id就可以了。
1.检测mark word是否为可偏向状态，是否为偏向锁及锁标识是否为01
2.若为可偏向状态，则检测当前持有锁的线程是否为当前线程。如果是执行5，否则执行3
3.如果线程Id不为当前线程的id，则CAS竞争锁，如果成功，则将mark word中的线程id设置为当前线程。如果失败，执行4
4.持有所得线程到达全局安全点，获得偏向锁的线程被挂起，偏向锁升级为轻量级锁，然后被阻塞在安全点的线程继续往下执行同步代码块
5.执行同步代码块
释放锁：
获取偏向锁的线程不会主动释放锁，只有在其他线程竞争偏向锁时才会释放，步骤:
1.暂停拥有偏向锁的线程，判断对象是否处于被锁定状态
2.撤销偏向锁，恢复到无锁状态或轻量级锁状态

偏向锁的获取和释放

轻量级锁
使用轻量级锁的目的：在没有多线程竞争的前提下，减少使用操作系统级的mutex锁导致用户态到内核态频繁切换引起的性能开销。当关闭偏向锁、或者多个线程竞争偏向锁导致锁升级为轻量级锁，尝试获取轻量级锁，步骤如下：
1.判断当前对象是否为无锁状态（hash code,偏向锁：0，锁标识：11），如是，则在当前线程的栈帧中创建一个锁记录（lock record），并存储对象当前的mark word的拷贝(官方将这份拷贝加dispatch，称之为 dispatch mark word )。如果不是，则执行3
2.CAS操作将对象的mark word替换为指向lock record的指针。如果成功，则表明竞争到锁，则将锁标识改为00，并执行同步块。如果失败，则执行3
3.判断当前对象的mark word是否指向了线程的lock record，如果是则表明当前线程已经持有了对象的锁，如果不是则说明对象锁已经被其他线程抢占，当前线程会自旋一段时间，如果还没有获取到锁，则将锁升级为重量级锁，将锁状态变为10，后面等待的线程将进行阻塞

释放锁：
轻量级锁的释放也是通过CAS操作来完成，步骤如下：
1.取出轻量级锁保存在线程lock record中的dispatch mark word信息
2.CAS的替换为对象mark word。如果成功，则说明释放锁成功，如果失败，则执行3
3.如果CAS操作替换失败，说明有其他线程尝试获取该锁，则需要在释放锁的同时需要唤醒被挂起的线程（其他线程CAS失败后，自旋，然后将锁升级为重量级锁，mark word的内容变了，所以持有锁的线程CAS释放锁时，就会失败）。
对于轻量级锁，其性能提升的依据是“对于绝大部分的锁，在整个生命周期内都是不会存在竞争的”，如果打破这个依据则除了互斥的开销外，还有额外的CAS操作，因此在有多线程竞争的情况下，轻量级锁比重量级锁更慢；

轻量级锁获取及释放

重量级锁
重量级锁通过对象内部的监视器（monitor）实现，其中monitor的本质是依赖于底层操作系统的Mutex Lock实现，操作系统实现线程之间的切换需要从用户态到内核态的切换，切换成本非常高
【参考博客】
1.http://www.importnew.com/23511.html
2.https://blog.csdn.net/u012465296/article/details/53022317