pc网站制作是指什么意思,潍坊建设gc局网站,网站的设计 改版 更新,网站建设讯美目录 一、常见的锁策略1.1 悲观锁 vs 乐观锁1.2 重量级锁 vs 轻量级锁1.3 挂起等待锁 vs 自旋锁1.4 普通互斥锁 vs 读写锁1.5 可重入锁 vs 不可重入锁1.6 不公平锁 vs 公平锁 二、synchronized特性2.1 synchronized的锁策略2.2 synchronized加锁过程2.3 其它优化措施 三、CAS3.… 目录 一、常见的锁策略1.1 悲观锁 vs 乐观锁1.2 重量级锁 vs 轻量级锁1.3 挂起等待锁 vs 自旋锁1.4 普通互斥锁 vs 读写锁1.5 可重入锁 vs 不可重入锁1.6 不公平锁 vs 公平锁 二、synchronized特性2.1 synchronized的锁策略2.2 synchronized加锁过程2.3 其它优化措施 三、CAS3.1 CAS概念3.2 CAS应用场景3.2.1 实现原子类。3.2.2 实现自旋锁 3.3 CAS的ABA问题3.3.1 ABA问题简介3.3.2 解决方案 四、JUC组件4.1 Callable接口4.2 ReentrantLock类4.3 Semaphore类4.4 CountDownLatch类 一、常见的锁策略
1.1 悲观锁 vs 乐观锁
悲观和乐观是指锁竞争的激烈情况。
悲观锁加锁的时候预测接下来的锁竞争会非常激烈就需要针对这样的激烈情况额外做工作乐观锁加锁的时候预测接下来的锁竞争不激烈就不需要额外做工作去处理锁竞争情况
1.2 重量级锁 vs 轻量级锁
这两种锁就对应上诉的悲观乐观情况下的处理机制。
重量级锁应对上面的锁竞争激烈的悲观情况效率更低轻量级锁应对上面的锁竞争不激烈的情况效率更高。
1.3 挂起等待锁 vs 自旋锁
这又是对上面的重量级与轻量级锁的典型实现。
挂起等待锁重量级锁的典型实现是操作系统内核级别的加锁发生竞争线程进入阻塞后就需要内核进行唤醒。获取锁的周期会变长但是这期间不会消耗CPU资源。自旋锁轻量级锁的典型实现是应用程序级别的加锁时发生竞争一般不进行阻塞而是通过忙等等待后续程序唤醒。获取锁的周期很短可以及时获取到锁但是这期间会一直消耗CPU资源。
1.4 普通互斥锁 vs 读写锁
这两种锁是针对加锁解锁时的线程安全问题。
普通互斥锁只有加锁解锁操作并且读操作不会出现线程安全问题而读写锁有读加锁写加锁和解锁操作 读锁与读锁之间不互斥 读锁与写锁之间存在互斥 写锁与写锁之间也存在互斥。 读写锁主要是针对读操作多写操作少的情况服务。
1.5 可重入锁 vs 不可重入锁
这组锁就是针对同一个线程多次嵌套获取同一把锁。
可重入锁字面意思是“可以重新进入的锁”即允许同一个线程多次获取同一把锁。不可重入锁字面意思是“不可以重新进入的锁”即同一个线程多次获取同一把锁会报错。
1.6 不公平锁 vs 公平锁
这组锁是针对线程获取锁的概率设置的。
不公平锁在Java中不公平锁是概率均等的随机分配锁公平锁在Java中公平锁是按照等待的时间先来后到分配锁。因为操作系统是随机调度为了实现公平锁就需要数据结构来记录先后调度顺序。
二、synchronized特性
2.1 synchronized的锁策略
锁策略如下
synchronized是一个自适应的锁开始时是乐观锁, 如果锁冲突频繁, 就转换为悲观锁。开始是轻量级锁实现, 如果锁被持有的时间较长, 就转换成重量级锁。是一种普通互斥锁。是一种不公平锁。是一种可重入锁。
2.2 synchronized加锁过程
synchronized的自适应过程称为锁升级无锁 - 偏向锁 - 自旋锁 - 重量级锁。 偏向锁偏向锁不是真的 “加锁”, 只是给对象头中做一个 “偏向锁的标记”, 记录这个锁属于哪个线程. 如果后续没有其他线程来竞争该锁, 那么就不用进行其他同步操作了(避免了加锁解锁的开销) 如果后续有其他线程来竞争该锁(刚才已经在锁对象中记录了当前锁属于哪个线程了, 很容易识别 当前申请锁的线程是不是之前记录的线程), 那就取消原来的偏向锁状态, 进入一般的轻量级锁状态. 就像跟你搞暧昧但是不正式跟你确认关系如果没人来追求你就一直不确定关系如果有人追求你就确认关系。 无锁 - 偏向锁 这个阶段是进入synchronized代码块 偏向锁 - 自旋锁这个阶段是拿到偏向锁后遇到其他线程来竞争这个锁 自旋锁 - 重量级锁这个阶段是JVM发现当前的锁竞争非常激烈。
2.3 其它优化措施
除了上面的synchronized锁升级以外还有以下的优化措施 锁消除编译器优化措施编译器会对加锁的代码进行判断但这种判断是非常保守的只有100%确定当前是单线程如果当前逻辑不需要加锁编译器就会自动去除synchronized。 锁粗化一个代码对细粒度的代码反复加锁解锁就会将这个步骤优化为更粗粒度的加锁解锁。 锁的粒度加锁和解锁之间包含的代码执行的逻辑/时间越多则锁的粒度就越粗反之越细。
三、CAS
3.1 CAS概念
CAS: 全称Compare and swap字面意思:”比较并交换“一个 CAS 涉及到以下操作 我们假设内存中的原数据V旧的预期值A需要修改的新值B。 比较 A 与 V 是否相等。比较如果比较相等将 B 写入 V。交换返回操作是否成功。 伪代码表示如下
boolean CAS(address, expectValue, swapValue) {if (address expectedValue) {address swapValue;return true;}return false;
}3.2 CAS应用场景
3.2.1 实现原子类。
原子类特指java.util.concurrent.atomic 包下的类这些类中的操作都是原子的。
像我们前面Thread类详解这篇文章介绍的非原子的操作带来的线程安全问题如果使用原子类就不存在了。 例如执行下面这段代码结果就一直是100000。 import java.util.concurrent.atomic.AtomicInteger;public class Demo {private static AtomicInteger count new AtomicInteger(0);public static void main(String[] args) throws InterruptedException {Thread thread1 new Thread(() - {for (int i 0; i 50000; i) {count.getAndAdd(1);}});Thread thread2 new Thread(() - {for (int i 0; i 50000; i) {count.getAndAdd(1);}});thread1.start();thread2.start();thread1.join();thread2.join();System.out.println(count.get());}
}原子类线程安全的原理 假设两个线程同时调用 getAndIncrement 两个线程都读取 value 的值到 oldValue 中。 (oldValue 是一个局部变量, 在栈上. 每个线程有自己的栈)线程1 先执行 CAS 操作. 由于 oldValue 和 value 的值相同, 直接进行对 value 赋值。线程2 再执行 CAS 操作, 第一次 CAS 的时候发现 oldValue 和 value 不相等, 不能进行赋值。因此需要进入循环。在循环里重新读取 value 的值赋给 oldValue。线程2 接下来第二次执行 CAS, 此时 oldValue 和 value 相同, 于是直接执行赋值操作。线程1 和 线程2 返回各自的 oldValue 的值即可。 3.2.2 实现自旋锁
基于 CAS 实现更灵活的自旋锁, 获取到更多的控制权。
主要逻辑如下
通过 CAS 看当前锁是否被某个线程持有。如果这个锁已经被别的线程持有, 那么就自旋等待。如果这个锁没有被别的线程持有, 那么就把 owner 设为当前尝试加锁的线程.
伪代码描述如下
public class SpinLock {private Thread owner null;public void lock(){while(!CAS(this.owner, null, Thread.currentThread())){}}public void unlock (){this.owner null;}
}3.3 CAS的ABA问题
3.3.1 ABA问题简介 假设存在两个线程 t1 和 t2. 有一个共享变量 num, 初始值为 A。 接下来, 线程 t1 想使用 CAS 把 num 值改成 Z, 那么就需要先读取 num 的值, 记录到 oldNum 变量中.。 使用 CAS 判定当前 num 的值是否为 A, 如果为 A, 就修改成 Z。 但是, 在 t1 执行这两个操作之间, t2 线程可能把 num 的值从 A 改成了 B, 又从 B 改成了 A。 线程 t1 的 CAS 是期望 num 不变就修改. 但是 num 的值已经被 t2 给改了. 只不过又改成 A 了. 这 个时候 t1 究竟是否要更新 num 的值为 Z 。就不符合预期出现bug。 过程图 bug例子 假如你去取钱有1000取500不小心按了两次取款我们只想扣一次500第一次按相当于T2第二次按相当于T1先执行T2读取操作修改为500这时又正好有人给你汇款了500内存中与寄存器中又相等了T1扣款的操作也会执行成功。 造成ABA问题的原因就是内存值既有加又有减所以我们的解决ABA的方式如下。
3.3.2 解决方案
给要修改的值, 引入版本号. 在 CAS 比较数据当前值和旧值的同时, 也要比较版本号是否符合预期。 CAS 操作在读取旧值的同时, 也要读取版本号。 真正修改的时候,
如果当前版本号和读到的版本号相同, 则修改数据, 并把版本号 1。如果当前版本号高于读到的版本号. 就操作失败(认为数据已经被修改过了)。
四、JUC组件
JUC组件就是指 java.util.concurrent 这个包下面的类。
4.1 Callable接口
Callable 接口就和java.lang包下的Runnable接口的定位差不多只不过给了我们一个返回值在Runnable接口要重写run方法而在Callable接口中要重写call方法。
在使用Callable接口传入线程时需要借助JUC下的另一个类FutureTask。
使用例子一般如下
public class Demo {public static void main(String[] args) {//创建实现了Callable接口的方法CallableInteger callable new CallableInteger() {Overridepublic Integer call() throws Exception {return null;}};//将实现Callable接口的对象作为参数传入FutureTask泛型参数要一致FutureTaskInteger futureTask new FutureTask(callable);//将FutureTask对象作为参数传入Thread thread new Thread(futureTask);}
}4.2 ReentrantLock类
ReentrantLock类可重入互斥锁和synchronized的定位是差不多的。 ReentrantLock 的用法:
public void lock(): 加锁, 如果获取不到锁就死等。public boolean trylock(超时时间): 加锁, 如果获取不到锁, 等待一定的时间之后就放弃加锁。public void unlock(): 解锁。 使用这个类加锁需要我们手动解锁为避免解锁执行不到的情况我们一般将unlock放在finally代码块中。 ReentrantLock locker new ReentrantLock();try {locker.lock();}finally {locker.unlock();}ReentrantLock与synchronized的区别
ReentrantLock是类是Java代码实现的synchronized是关键字由JVM使用c代码实现的。ReentrantLock是需要lock()方法加锁unlock()方法解锁。synchronized是通过进出代码块加锁解锁。ReentrantLock还提供了tryLock()方法可以设置超时时间不会一直阻塞加锁成功返回true调用者可以根据返回值自己操作。ReentrantLock还提供了公平锁的实现默认是非公平锁但是构造方法传参true实现公平锁。 ReentrantLock搭配的通知机制是Condition类可以更精确控制唤醒某个指定的线程相比wait / notify功能更强大。
4.3 Semaphore类
信号量,用来表示 “可用资源的个数”。 本质上就是一个计数器能够协调多个线程之间的资源调配。 最主要的就是申请资源P操作调用acquire方法释放资源V操作调用release方法 可以把信号量想象成是停车场的展示牌: 当前有车位 100 个。表示有 100 个可用资源。当有车开进去的时候, 就相当于申请一个可用资源, 可用车位就 -1 (这个称为信号量的 P 操作)当有车开出来的时候, 就相当于释放一个可用资源, 可用车位就 1 (这个称为信号量的 V 操作)如果计数器的值已经为 0 了, 还尝试申请资源, 就会阻塞等待, 直到有其他线程释放资源. 4.4 CountDownLatch类
CountDownLatch类的作用同时等待 N 个任务执行结束。就像跑步比赛10个选手依次就位哨声响才同时出发所有选手都通过终点才能公布成绩。 使用多线程的时候经常会把一个大任务拆分为多个子任务使用CountDownLatch衡量子任务完成让整个任务完成。 构造 CountDownLatch 实例, 参数传入任务个数初始化 10 表示有 10 个任务需要完成。每个任务执行完毕, 都调用 countDown()方法 . 在 CountDownLatch 内部的计数器同时自减.主线程中使用 await()方法; 阻塞等待所有任务执行完毕后wait结束。 相当于计数器为 0 了。
