乐观锁
乐观锁是一种乐观思维,即认为读多写少,遇到并发写的可能性低,每次去拿数据的时候都认为他人不会批改,所以不会上锁,然而在更新时会判断此期间数据是否被更新
采取在写时先读出以后版本号,而后加锁操作(比拟跟上一次的版本号,如果一样则更新),如果失败则要反复读 - 比拟 - 写的操作 java 中的乐观锁根本通过 CAS 操作实现的,CAS 是一种更新的原子操作,比拟以后值跟传入值是否一样,一样则更新,否则失败
乐观锁
乐观锁是就是乐观思维,即认为写多,遇到并发写的可能性高,每次去拿数据的时候都认为他人会批改,所以每次在读写数据的时候都会上锁,这样他人想读写这个数据就会 block 直到拿到锁 Java 中的乐观锁就是 Synchronized
AQS 框架下的锁则是先尝试 cas 乐观锁去获取锁,获取不到,才会转换为乐观锁,如 RetreenLock
自旋锁
原理
自旋锁原理非常简单,如果持有锁的线程能在很短时间内开释锁资源,那么那些期待竞争锁的线程就不须要做内核态和用户态之间的切换进入阻塞挂起状态,它们只需自旋,等持有锁的线程开释锁后即可立刻获取锁,这样就防止用户线程和内核的切换的耗费。线程自旋需耗费 cup 的,如果始终获取不到锁,则线程长时间占用 CPU 自旋,须要设定一个自旋期待最大事件在最大等待时间内仍未取得锁就会进行自旋进入阻塞状态。
自旋锁优缺点
长处
自旋锁尽可能的缩小线程的阻塞,这对于锁的竞争不强烈,且占用锁工夫十分短的代码块来说性能能大幅度的晋升,因为自旋的耗费会小于线程阻塞挂起再唤醒的操作的耗费(这些操作会导致线程产生两次上下文切换)
毛病
锁竞争强烈或者持有锁的线程须要长时间占用锁执行同步块,不适宜应用自旋锁了,因为自旋锁在获取锁前始终都是占用 cpu
做无用功,同时有大量线程在竞争一个锁,会导致获取锁的工夫很长,线程自旋的耗费大于线程阻塞挂起操作的耗费,其它须要 cup 的线程又不能获取到 cpu,造成 cpu 的节约
自旋锁工夫阈值(1.6 引入了适应性自旋锁)
自旋锁的目标是为了占着 CPU 的资源不开释,等到获取到锁立刻进行解决 自旋执行工夫太长,会有大量的线程处于自旋状态占用 CPU 资源,进而会影响整体零碎的性能 JVM 对于自旋周期的抉择,jdk1.5 这个限度是肯定的写死的 在 1.6 引入了适应性自旋锁,自旋的工夫不固定,而是由前一次在同一个锁上的自旋工夫以及锁的拥有者的状态来决定,根本认为一个线程上下文切换的工夫是最佳的一个工夫
自旋锁的开启
JDK1.6 中 -XX:+UseSpinning 开;XX:PreBlockSpin=10 为自旋次数 JDK1.7 后,去掉此参数,由 jvm 管制
Synchronized 同步锁
关键字,用于解决多个线程间拜访资源同步性问题,保障其润饰的办法或代码块任意时刻只能有一个线程拜访 synchronized 它能够把任非 NULL 的对象当作锁。他属于独占式乐观锁,同时属于可重入锁。
Synchronized 作用范畴
作用实例办法时。锁住的是对象的实例(this) 作用静态方法时,锁住的是该类,该 Class 所有实例,又因为 Class
的相干数据存储在永恒带 PermGen(jdk1.8 则是 元空间),永恒带是全局共享的,因而静态方法锁相当于类的一个全局锁,会锁所有调用该办法的线程
.
线程 A 调用一个实例对象非动态 Synchronized 办法,容许线程 B 调用该实例对象所属类的动态 s 办法而不会产生互斥,前者锁的是以后实例对象,后者锁的是以后类 作用于同步代码块 锁住的以后对象,进入同步代码块前须要取得对象的锁
Synchronized 实现
Synchronized 是一个重量级操作,须要调用操作系统相干接口,性能是低效的,有可能给线程加锁耗费的工夫比有用操作耗费的工夫更多。Java1.6,synchronized 进行了很多的优化,有适应自旋、锁打消、锁粗化、轻量级锁及偏差锁等,效率有了实质上的进步。在之后推出的 Java1.7 与 1.8 中,均对该关键字的实现机理了优化。引入了偏差锁和轻量级锁,都是在对象头中有标记位,不须要通过操作系统加锁
JDK1.6 后的优化
synchronized 是依据 JVM 实现的,该关键字的优化也是在 JVM 层面实现 而未间接裸露
JDK1.6 后对锁做了大量优化如偏差锁,轻量锁,自旋锁,自适应锁等等
锁次要有四种状态:无锁状态,偏差锁状态,轻量级锁状态,重量级锁状态,他们会随着锁竞争的强烈而逐步降级且这种降级不可降,利用该策略进步取得锁和开释锁的效率
ReentrantLock
ReentantLock 继承接口 Lock 并实现了接口中定义的办法,他是一种可重入锁,除了能实现 synchronized 所能实现的所有工作外,还提供了诸如可响应中断锁、可轮询锁申请、定时锁等防止多线程死锁的办法。
Lock 接口次要办法
void lock(): 执行此办法时, 如果锁处于闲暇状态, 以后线程将获取到锁 lock()办法则是肯定要获取到锁,
如果锁不可用, 就始终期待, 在未取得锁之前, 以后线程并不持续向下执行. boolean tryLock():
如果锁可用, 则获取锁, 并立刻返回 true, 否则返回 false. tryLock()只是 "试图" 获取锁, 如果锁不可用, 不会导致以后线程阻塞挂起, 以后线程依然持续往下执行代码.
void unlock() 解锁
isLock(): 此锁是否有任意线程占用
tryLock 和 lock 和 lockInterruptibly
tryLock 能取得锁就返回 true,不能就立刻返回 false,tryLock(long timeout,TimeUnitunit),能够减少工夫限度,如果超过该时间段还没取得锁,返回 false
lock 能取得锁就返回 true,不能的话始终期待取得锁 lock 和 lockInterruptibly,如果两个线程别离执行这两个办法,但此时中断这两线程,但此时中断这两个线程,lock 不会抛出异样,而 lockInterruptibly 会抛出异样
ReentrantLock 与 synchronized
ReentrantLock 与 synchronized 两者均为可重入锁
Synchronized 依赖 JVM 而 Reentrantlock 依赖于 APi(lock(),trylock()配合 try/finally 语句块来实现)ReentrantLock 通过办法 lock()与 unlock()来进行加锁与解锁操作,synchronized 会被 JVM 主动解锁 ReentrantLock 加锁后须要手动进行解锁。为了防止程序出现异常而无奈失常解锁的状况,应用 ReentrantLock 必须在 finally 管制块中进行解锁操作
ReentrantLock 相比 synchronized 的劣势是可中断、偏心锁、可抉择告诉,多个锁,这种状况下需 ReentrantLock。
非偏心锁
JVM 随机就近准则调配锁的机制则称为不偏心锁,非偏心锁理论执行的效率要远超偏心锁,除非程序有非凡须要,否则最罕用非偏心锁的分配机制。非偏心锁性能比偏心锁高 5~10 倍,因为偏心锁须要在多核的状况下保护期待队列
Java 中的 synchronized 是非偏心锁,ReentrantLock 默认的 lock()办法采纳的是非偏心锁(结构时提供了偏心);
偏心锁
偏心锁指的是锁的分配机制是偏心的,通常先对锁提出获取申请的线程会先被调配到锁 加锁前查看是否有排队期待的线程,优先排队期待的线程,先来先得
可重入锁(递归锁)
可重入锁(递归锁),指的是同一线程 外层函数取得锁之后,内层递归函数依然有获取该锁的代码,但不受影响 在 JAVA 环境下 ReentrantLock 和 synchronized 都是 可重入锁
读写锁
为了进步性能,Java 提供了读写锁,在读的中央应用读锁,在写的中央应用写锁,灵便管制
如果没有写锁的状况下,读是无阻塞的, 在肯定水平上进步了程序的执行效率。读写锁分为读锁和写锁,多个读锁不互斥,读锁与写锁互斥由 jvm 管制的,程序员只须要上好相应的锁 要求代码只读数据,能够很多人同时读,但不能同时写,可上读锁 代码批改数据,只能有一个人在写,且不能同时读取,那就上写锁 Java 中 读 写 锁 有 个 接 口 java.util.concurrent.locks.ReadWriteLock,也 有 具 体 的 实 现 ReentrantReadWriteLock
独占锁共享锁
java 并发包提供的加锁模式分为独占锁和共享锁
独占锁
独占锁模式下,每次只能有一个线程能持有锁
独占锁是一种乐观激进的加锁策略,它防止了读 / 读抵触,如果某个只读线程获取锁,则其余读线程都只能期待,这种状况下就限度了不必要的并发性,因为读操作并不会影响数据的一致性
ReentrantLock 就是以独占形式实现的互斥锁。
共享锁
共享锁则容许多个线程同时获取锁,并发拜访 共享资源,如:ReadWriteLock
共享锁则是一种乐观锁,它放宽了加锁策略,容许多个执行读操作的线程同时访问共享资源 java 的并发包中提供了
ReadWriteLock,读 - 写锁。它容许一个资源能够被多个读操作拜访,或者被一个 写操作拜访,但两者不能同时进行
锁状态
锁的状态总共有四种: 无锁状态、偏差锁、轻量级锁和重量级锁
重量级锁 (Mutex Lock)
这种依赖于操作系统 Mutex Lock 所实现的锁咱们称之为“重量级锁”Synchronized,是通过对象外部的做监视器锁 (monitor) 实现。监视器锁是依赖于底层的操作系统的 Mutex Lock 来实现,而操作系统实现线程之间的切换这就须要从用 户态转换到外围态,这个老本十分高,状态之间的转换须要绝对比拟长的工夫,
这就是为什么 Synchronized 效率低的起因
轻量级锁
轻量级”是绝对于应用操作系统互斥量来实现的传统锁而言的。
轻量级锁并不是用来代替重量级锁的,它的本意是在没有多线程竞争的前提下,缩小传统的重量级锁应用产生的性能耗费。
轻量级锁所适应的场景是线程交替执行同步块的状况,如果存在同一时间拜访同一锁的状况,就会导致轻量级锁收缩为重量级锁。
偏差锁
引入偏差锁是为了在无多线程竞争的状况下尽量减少不必要的轻量级锁执行门路,因为轻量级锁的获取及开释依赖屡次 CAS 原子指令,
而偏差锁只须要在置换 ThreadID 的时候依赖一次 CAS 原子指令 (因为一旦呈现多线程竞争的状况就必须撤销偏差锁,所以偏差锁的撤销操作的性能损耗必须小于节省下来的 CAS 原子指令的性能耗费)。
轻量级锁是为了在线程交替执行同步块时进步性能,而偏差锁则是在只有一个线程执行同步块时进一步提高性能。
锁降级
随着锁的竞争,锁能够从偏差锁降级到轻量级锁,再降级的重量级锁(然而锁的降级是单向的,也就是说只能从低到高降级,不会呈现锁的降级)。
分段锁
分段锁也并非一种理论的锁,而是一种思维 ConcurrentHashMap 是学习分段锁的最好实际
同步锁与死锁
同步锁
当多个线程同时拜访同一个数据时,很容易呈现问题。为了防止这种状况呈现,咱们要保障线程同步互斥,就是指并发执行的多个线程。
在同一时间内只容许一个线程访问共享数据。Java 中能够应用 synchronized 关键字来获得一个对象的同步锁。
死锁
就是多个线程同时被阻塞,它们中的一个或者全副都在期待某个资源被开释。
锁优化思路
缩小锁持有工夫
只用在有线程平安要求的程序上加锁
减小锁粒度
将大对象 (这个对象可能会被很多线程拜访),拆成小对象,减少并行度,升高锁竞争,
升高了锁的竞争,偏差锁,轻量级锁成功率才会进步,最最典型的减小锁粒度的案例就 ConcurrentHashMap。
锁拆散
最常见的锁拆散就是读写锁
ReadWriteLock,依据性能进行拆散成读锁和写锁,这样读读不互斥,读写互斥,写写互斥,即保障了线程平安,又进步了性能,
读写拆散思维能够延长,只有操作互不影响,锁就能够拆散,比方 LinkedBlockingQueue 从头部取出,从尾部放数据
锁粗化
通常状况下,为了保障多线程间的无效并发,会要求每个线程持有锁的工夫尽量短(应用完公共资源后,应该立刻开释锁)。
如果对同一个锁不停的进行申请、同步和开释,其自身也会耗费零碎贵重的资源,反而不利于性能的优化所以能够锁粗化使得占有锁的工夫加长
Condition 类和 Object 类锁办法
Condition 类和 Object 类锁办法 Condition 类的 awiat 办法和 Object 类的 wait 办法等效
Condition 类的 signal 办法和 Object 类的 notify 办法等效 Condition 类的 signalAll 办法和 Object 类的 notifyAll 办法等效
ReentrantLock 类能够唤醒指定条件线程,而 object 的唤醒是随机的