java锁策略

加锁&＃xff0c;是一个开销比较大的过程&＃xff0c;我们希望在一些特定的场景下&＃xff0c;针对场景做出一些取舍&＃xff0c;可以让锁更加高效一些。就有了以下不同的锁。

乐观锁&＃xff1a; 假设一般情况下都不会产生锁冲突或基本没有冲突&＃xff0c;只有在数据访问的时候才会判断有没有锁竞争。没有就直接修改数据&＃xff0c;如果有锁冲突&＃xff0c;然后再去处理。

悲观锁 &＃xff1a; 假设一般情况下都会产生锁冲突&＃xff0c;每次去访问数据的时候都会先上锁&＃xff0c;然后再去访问数据。

ReadWriteLock 管理一组锁&＃xff0c;一个是读锁&＃xff08;共享锁&＃xff09;&＃xff0c;一个是写锁&＃xff08;互斥锁&＃xff09;&＃xff0c;读写锁默认是悲观锁策略 。
读锁&＃xff1a;可以在没有写锁的时候被多个线程同时持有&＃xff0c;但写锁是独占的&＃xff0c;同时只能有一个线程去写。

一个获得了读锁的线程必须能看到前一个释放的写锁更新的内容。读写锁比互斥锁允许对于数据更大程度上的并发。读写锁适用于读多写少的情况&＃xff0c;此时使用读写锁&＃xff0c;就能大大的提高效率。

例&＃xff1a;
假设有10个线程&＃xff0c;t1 和 t2 是写线程&＃xff0c;t3 - t9是读线程。

1. 如果 t3 和t4 两个线程同时访问数据&＃xff0c;此时两个读锁之间不会互斥&＃xff0c;完全并发的执行。
2. 如果 t1 和 t3 两个线程同时访问&＃xff0c;此时读锁和写锁之间就会互斥&＃xff0c;要么是读完再写&＃xff0c;要么是写完再读。
3. 如果是 t1 和 t2 两个写线程溶蚀访问&＃xff0c;此时写锁和写锁之间就会互斥&＃xff0c;执行过程一定是一个线程写完&＃xff0c;另一个线程再写。

一个线程针对同一把锁连续加锁两次&＃xff0c;如果出现死锁&＃xff0c;就是 不可重入锁&＃xff0c;如果没有出现死锁&＃xff0c;就是可重入锁。

对于可重入锁&＃xff0c;当前的锁会记录这个锁是谁持有的&＃xff0c;如果发现&＃xff0c;当前有同一个线程再次尝试获取锁。这个时候&＃xff0c;就让代码能够继续运行&＃xff0c;而不是阻塞等待。同时这个锁里面也维护一个计数器&＃xff0c;这个计数器记录了当前这个线程&＃xff0c;针对这把锁加了几次锁&＃xff0c;每次加锁&＃xff0c;计数器 &＃43;1 &＃xff0c;每次解锁&＃xff0c;计数器 -1 &＃xff0c;直到计数器为零&＃xff0c;此时才会真正的释放锁&＃xff0c;其他线程才能才能够获取到这个锁。

加锁很重要的特性就是要保证原子性&＃xff0c;原子性的共功能其实来源于硬件&＃xff08;硬件提供了相应的原子操作指令&＃xff09;&＃xff0c;所以在加锁的过程中&＃xff0c;如果整个加锁的逻辑过程都是依赖于操作系统内核&＃xff0c;那此时就是重量级锁&＃xff0c;此时代码在内核中的开销很大。如果大多数操作&＃xff0c;都是由用户自己完成的&＃xff0c;少数由操作系统完成就是轻量级锁。

重量级锁 &＃xff1a; 加锁、解锁的开销很大&＃xff0c;往往是通过内核来完成的
轻量级锁&＃xff1a; 加锁、解锁的开销很小&＃xff0c;往往只是在用户态完成的。

不同的锁策略之间&＃xff0c;并不是完全互不相关的&＃xff0c;可能会有部分的重叠&＃xff1a;
如 &＃xff1a;
悲观锁&＃xff0c;做的工作往往更过&＃xff0c;因此开销也就更大&＃xff0c;悲观锁大概率是重量级锁
乐观锁&＃xff0c;做的工作往往更少 &＃xff0c; 因此开销也更小&＃xff0c;乐观锁大概率是轻量级锁

公平锁&＃xff1a; 如果遵循先来后到的原则&＃xff0c;多个线程按照申请锁的顺序去获得锁&＃xff0c;线程会直接进入到队列去排队&＃xff0c;永远是队列的第一位才能获取到锁。

优点&＃xff1a; 所有的线程都能够得到资源&＃xff0c;不会饿死再队列中
缺点 &＃xff1a; 吞吐量会下降很多&＃xff0c;队列里面处理第一个线程&＃xff0c;其他的线程都会阻塞&＃xff0c;cpu 唤醒阻塞线程的开销比较大。

非公平锁&＃xff1a; 不遵循先来后到的原则&＃xff0c;多个线程抢占式执行&＃xff0c;获取不到锁的再去进入等待队列

优点&＃xff1a;可以减少 CPU 唤醒线程的开销&＃xff0c;整体的吞吐效率比较高
缺点 &＃xff1a;由于所有的线程都在抢占执行&＃xff0c;可能会导致队列中的线程一直获取不到锁导致饿死的现象。

自旋锁&＃xff1a; 如果线程获取不到锁&＃xff0c;不是阻塞等待而是循环的快速的再是一次~~&＃xff0c;因此就节省了操作系统调度线程的开销&＃xff0c;要比挂起等待锁更能及时的获取到锁。&＃xff08;假设有两个线程&＃xff0c;线程1 拿到了锁&＃xff0c;线程2就会不断的通过循环来尝试获取这个锁&＃xff0c;一旦线程1 释放了锁&＃xff0c;线程2 就能够第一时间时间获取到这个锁&＃xff0c;与此而来的问题是&＃xff0c;自旋锁更浪费 CPU 资源&＃xff0c;通常都是轻量级的锁&＃xff09;

挂起等待锁&＃xff1a; 如果线程获取不到锁&＃xff0c;就会阻塞等待&＃xff0c;具体什么时候结束阻塞&＃xff0c;取决于操作系统的具体调度&＃xff0c;当线程挂起的时候&＃xff0c;不占用 CPU 资源&＃xff0c;通常都是重量级锁

应用场景:

1. 如果锁的冲突的概率比较低&＃xff0c;使用自旋锁比挂起等待锁&＃xff0c;更合适
2. 如果线程持有锁的时间比较短&＃xff0c;使用自旋锁比挂起等待锁更合适
3. 如果对 CPU 比较敏感&＃xff0c;不希望占用太多的 CPU 资源&＃xff0c;那么就不太适合使用自旋锁

java对象在内存中的布局&＃xff0c;可分为三个部分&＃xff1a;

1. 对象头&＃xff1a;对象头主要包括 Mark Word&＃xff08;标记字段&＃xff09;&＃xff0c;用于存储对象自身的运行时数据。Klass Pointer&＃xff08;类型指针&＃xff09;&＃xff0c;对象指向它的类元数据的指针&＃xff0c;虚拟机通过这个指针来确定这个对象是哪个类的实例
2. 实例变量 &＃xff1a; 存储的是对象的属性信息&＃xff0c;包括父类的属性信息&＃xff0c;按照4字节对齐
3. 填充字节 &＃xff1a; 因为虚拟机要求对象字节必须是8字节的整数倍&＃xff0c;填充字节只是为了内存对齐
   
   Java SE1.6 为了减少获得锁和释放锁所带来的性能消耗&＃xff0c;引入了“偏向锁”和“轻量级锁”&＃xff0c;所以在 Java SE1.6 里锁一共有四种状态&＃xff0c;无锁状态&＃xff0c;偏向锁状态&＃xff0c;轻量级锁状态和重量级锁状态&＃xff0c;它会随着竞争情况逐渐升级。

锁可以升级但不能降级&＃xff0c;意味着偏向锁升级成轻量级锁后不能降级成偏向锁。这种锁升级却不能降级的策略&＃xff0c;目的是为了提高获得锁和释放锁的效率。

1、无锁&＃xff1a;

没有对资源进行锁定&＃xff0c;多有的线程都能够访问并修改同一个资源&＃xff0c;但同时只有一个线程能修改成功
无锁的特点是修改操作会在循环内进行&＃xff0c;线程会不断的尝试修改共享资源。如果没有冲突就修改成功并退出&＃xff0c;如果有冲突就会循环尝试。如果有多个线程修改同一个值&＃xff0c;必定会有一个线程能修改成功&＃xff0c;而其他修改失败的线程会不断重试直到修改成功。

2、 偏向锁&＃xff1a;

偏向锁引入&＃xff1a;
经过研究&＃xff0c;大多数时候是不存在锁竞争的&＃xff0c;常常是一个线程多次获得同一个锁&＃xff0c;因此如果每次都要竞争锁会增大很多没有必要付出的代价&＃xff0c;为了降低获取锁的代价&＃xff0c;才引入的偏向锁。

偏向锁升级过程&＃xff1a;

偏向锁是指当一段同步代码一直被同一个线程访问时&＃xff0c;即不存在多个线程的竞争时&＃xff0c;那么该线程在后续访问时变会自动获得锁&＃xff0c;从而降低获取锁代理的消耗。

当线程1 在访问同步代码块并获取到锁时&＃xff0c;会在java对象头和栈帧中记录偏向的锁的线程ID&＃xff0c;因为偏向锁不会主动释放锁&＃xff0c;&＃xff08;偏向锁只有遇到其他线程尝试竞争偏向锁时&＃xff0c;持有偏向锁的线程才会释放锁&＃xff0c;线程是不会主动释放偏向锁的&＃xff09;

因此以后线程1在次获取锁的时候&＃xff0c;只需要比较当前线程的ID 和 java对象头中的线程ID是否一致&＃xff1a;
如果一致&＃xff0c;则无需使用CAS来加锁&＃xff0c;解锁&＃xff1b;
如果不一致&＃xff0c;&＃xff08;如线程2需要竞争锁对象&＃xff0c;而偏向锁不会主动释放因此还是存储1的ID &＃xff09;&＃xff0c;那么就需要查看java对象头中记录的线程1是否存货&＃xff0c;如果没有存货&＃xff0c;那么锁对象被重置位无所状态&＃xff0c;其他线程可以竞争将其设置为偏向锁&＃xff1b;如果存活&＃xff0c;那么立刻查找该线程&＃xff08;线程1&＃xff09;的的栈帧信息&＃xff0c;如果还是需要继续下hi有这个锁对象&＃xff0c;那么暂停当前线程1&＃xff0c;撤销偏向锁&＃xff0c;升级位轻量级锁&＃xff0c;如果线程1不再使用该锁对象&＃xff0c;那么将锁对象状态设置为无锁状态&＃xff0c;重新偏向新的线程

3、 轻量级锁

轻量级锁引用&＃xff1a;
轻量级锁考虑的是竞争多对象的线程不多&＃xff0c;而且线程持有锁的时间也不长的情景。因为阻塞线程需要 CPU 从用户态转到内核态&＃xff0c;代价比较大&＃xff0c;如果刚刚阻塞不久&＃xff0c;这个锁就被释放了&＃xff0c;这个开销就很大&＃xff0c;因此这个时候就干脆不阻塞这个线程&＃xff0c;让他自旋着等待锁释放。线程不会阻塞&＃xff0c;从而提高了性能

轻量级锁的获取主要有两种情况

• 当关闭偏向锁功能时
• 由于多个线程竞争偏向锁导致偏向锁升级为轻量级锁。

线程1获取轻量级锁时&＃xff0c;会先把锁对象头 MarkWord 复制一份到线程1的栈帧中创建的用于存储锁记录的空间&＃xff08;称为DisplaceMarkWord&＃xff09;&＃xff0c;然后使用 CAS 把对象头中的内容替换位线程1存储的锁记录&＃xff08;DisplaceMarkWord&＃xff09;的地址&＃xff1b;

如果在线程1复制对象的同时&＃xff08;在线程1 CAS之前&＃xff09;&＃xff0c;线程2也准备获取锁&＃xff0c;复制了对象头到线程2的锁记录空间中&＃xff0c;但是在2线程 CAS的时候&＃xff0c;发现线程1已经把对象头换了&＃xff0c;线程2CAS 失败&＃xff0c;那么线程2就尝试使用自旋锁来等待线程1释放锁。&＃xff08;线程2不断CAS&＃xff09;

但是如果自旋时间太长&＃xff0c;因为自旋是要消耗CPU的&＃xff0c;因此自旋的次数是由限制的&＃xff0c;如果自旋次数到了&＃xff0c;线程1还没有释放锁&＃xff0c;或者线程1 还在执行&＃xff0c;线程2还在自旋等待&＃xff0c;这时又有一个线程3过来竞争这个锁对象&＃xff0c;那么这个轻量级锁就会膨胀为重量级锁。

4、重量级锁

重量级锁&＃xff0c;是指当一个线程获取锁之后&＃xff0c;其余所有等待获取该锁的线程都会处于阻塞状态&＃xff0c;除拥有锁的线程都阻塞。

重量级锁是通过对象内部的监视器实现&＃xff0c;而其中monitor的本质是依赖底层操作系统 Mutex Lock 实现&＃xff0c;操作系统实现线程之间的切换需要从用户态切换到内核态&＃xff0c;切换成本非常高。

由操作系统来负责线程间的调度和线程的状态变更。而这样出现偏饭的对线程云从状态的切换&＃xff0c;线程的挂起和唤醒&＃xff0c;从而消耗大量的系统资源&＃xff0c;导致性能降低。

总结

通常情况下&＃xff0c;为了保证多线程间的有效并发&＃xff0c;会尽量将同步代码块作用的范围控制的尽量小&＃xff0c;只在共享的数据的实际作用域中才进行同步&＃xff0c;这样是为了使得需要同步的操作数量尽可能变小&＃xff0c;如果存在锁竞争&＃xff0c;拿等待的锁的线程也能尽快拿到锁。

但是如果一个程序对同一个锁不间断、高频繁的反复加锁与解锁&＃xff0c;会消耗不必要的资源开销&＃xff0c;这样高频的锁请求反而不利于系统性能的优化。如果虚拟机探测到有这样遗传零碎的操作都对同一个对象加锁&＃xff0c;将会把锁的范围扩展到整个操作程序的外部&＃xff0c;合并成一个请求&＃xff0c;以降低短时间内大量锁请求&＃xff0c;同步。释放带来的性能损耗

fun(){synchronized(this){//任务1}synchronized(this){//任务2}synchronized(this){//任务3}
}


上面的代码会不断的加锁&＃xff0c;释放锁&＃xff0c;造成不必要的系统开销&＃xff0c;与其这样还不如一次加锁完成三个任务

fun(){synchronized(this){//任务1//任务2//任务3}
}

九、锁消除

锁消除&＃xff0c;是指虚拟机在执行编译器运行时&＃xff0c;会一些代码上要求同步&＃xff0c;但是被检测到不可能存在共享数据竞争的锁进行消除。显然这里有锁&＃xff0c;但是可以被安全的消除掉&＃xff0c;在即时编译之后。这段代码就会忽略掉所有的同步而直接执行。