最好网站建设公司制作平台,dede网站底部,网站建设与管理2018,平面设计师网站乐观锁与悲观锁
悲观锁指对数据被外界修改持保守态度#xff0c;认为数据很容易就会被其他线程修改#xff0c;所以在数据被处理前先对数据进行加锁#xff0c;并在整个数据处理过程中#xff0c;使数据处于锁定状态。
悲观锁的实现往往依靠数据库提供的锁机制#xff0…乐观锁与悲观锁
悲观锁指对数据被外界修改持保守态度认为数据很容易就会被其他线程修改所以在数据被处理前先对数据进行加锁并在整个数据处理过程中使数据处于锁定状态。
悲观锁的实现往往依靠数据库提供的锁机制即在数据库中在对数据记录操作前给记录加排它锁。
如果获取锁失败则说明数据正在被其他线程修改当前线程则等待或者抛出异常。
如果获取锁成功则对记录进行操作然后提交事务后释放排它锁。 假设updateEntry、query、update方法都使用了事务切面的方法并且事务传播性被设置为required。
执行updateEntry方法时如果上层调用方法里面没有开启事务则会即时开启一个事务然后执行代码(1)。
代码(1)调用了query方法其根据指定id从数据库里面查询出一个记录。
由于事务传播性为requried,所以执行query时没有开启新的事务而是加入了updateEntry开启的事务也就是在updateEntry方法执行完毕提交事务时query方法才会被提交就是说记录的锁定会持续到updateEntry执行结束。
代码(2)则对获取的记录进行修改代码(3)把修改的内容写回数据库同样代码(3)的update方法也没有开启新的事务而是加入了updateEntry的事务。
也就是updateEntry、query、update方法共用同一个事务。
当多个线程同时调用updateEntry方法并且传递的是同一个id时只有一个线程执行代码(1)会成功其他线程则会被阻塞这是因为在同一时间只有一个线程可以获取对应记录的锁在获取锁的线程释放锁前(updateEntry执行完毕提交事务前),其他线程必须等待也就是在同一时间只有一个线程可以对该记录进行修改。
乐观锁是相对悲观锁来说的它认为数据在一般情况下不会造成冲突所以在访问记录前不会加排它锁而是在进行数据提交更新时才会正式对数据冲突与否进行检测。
具体来说根据update返回的行数让用户决定如何去做。将上面的例子改为使用乐观锁的代码如下。 当多个线程调用updateEntry方法并且传递相同的id时多个线程可以同时执行代码(1)获取id对应的记录并把记录放入线程本地栈里面然后可以同时执行代码(2)对自己栈上的记录进行修改多个线程修改后各自的entry里面的属性应该都不一样了。
然后多个线程可以同时执行代码(3),代码(3)中的update语句的where条件里面加入了version#{version}条件并且set语句中多了version${version}1表达式该表达式的意思是如果数据库里面id#{id} and version#{version}的记录存在则更新version的值为原来的值加1,这有点CAS操作的意思。
假设多个线程同时执行updateEntry并传递相同的id,那么它们执行代码(1)时获取的Entry是同一个获取的Entry里面的version值都是相同的(这里假设version0)。
当多个线程执行代码(3)时由于update语句本身是原子性的假如线程A执行update成功了那么这时候id对应的记录的version值由原始version值变为了1。其他线程执行代码(3)更新时发现数据库里面已经没有了version0的语句所以会返回影响行号0。
在业务上根据返回值为0就可以知道当前更新没有成功那么接下来有两个做法如果业务发现更新失败了下面可以什么都不做也可以选择重试如果选择重试则updateEntry的代码可以修改为如下。 如上代码使用retryNum设置更新失败后的重试次数如果代码(3.1)执行后返回0,则说明代码(1.1)获取的记录已经被修改了则循环一次重新通过代码(1.1)获取最新的数据然后再次执行代码(3.1)尝试更新。
这类似CAS的自旋操作只是这里没有使用死循环而是指定了尝试次数。
乐观锁并不会使用数据库提供的锁机制一般在表中添加version字段或者使用业务状态来实现。乐观锁直到提交时才锁定所以不会产生任何死锁。
公平锁与非公平锁
根据线程获取锁的抢占机制锁可以分为公平锁和非公平锁公平锁表示线程获取锁的顺序是按照线程请求锁的时间早晚来决定的也就是最早请求锁的线程将最早获取到锁。而非公平锁则在运行时闯入也就是先来不一定先得。 ReentrantLock提供了公平和非公平锁的实现。
公平锁ReentrantLock pairLock new ReentrantLock(true)。非公平锁ReentrantLock pairLock new ReentrantLock(false)。如果构造函数不传递参数则默认是非公平锁。
例如假设线程A已经持有了锁这时候线程B请求该锁其将会被挂起。当线程A释放锁后假如当前有线程C也需要获取该锁如果采用非公平锁方式则根据线程调度策略线程B和线程C两者之一可能获取锁这时候不需要任何其他干涉而如果使用公平锁则需要把C挂起让B获取当前锁。 在没有公平性需求的前提下尽量使用非公平锁因为公平锁会带来性能开销。
独占锁与共享锁
根据锁只能被单个线程持有还是能被多个线程共同持有锁可以分为独占锁和共享锁。
独占锁保证任何时候都只有一个线程能得到锁ReentrantLock就是以独占方式实现的。
共享锁则可以同时由多个线程持有例如ReadWriteLock读写锁它允许一个资源可以被多线程同时进行读操作。
独占锁是一种悲观锁由于每次访问资源都先加上互斥锁这限制了并发性因为读操作并不会影响数据的一致性而独占锁只允许在同一时间由一个线程读取数据其他线程必须等待当前线程释放锁才能进行读取。
共享锁则是一种乐观锁它放宽了加锁的条件允许多个线程同时进行读操作。
什么是可重入锁
当一个线程要获取一个被其他线程持有的独占锁时该线程会被阻塞那么当一个线程再次获取它自己已经获取的锁时是否会被阻塞呢?如果不被阻塞那么我们说该锁是可重入的也就是只要该线程获取了该锁那么可以无限次数地进入被该锁锁住的代码。 调用helloB方法前会先获取内置锁然后打印输出。
之后调用helloA方法在调用前会先去获取内置锁如果内置锁不是可重入的那么调用线程将会一直被阻塞。
实际上synchronized内部锁是可重入锁。可重入锁的原理是在锁内部维护一个线程标示用来标示该锁目前被哪个线程占用然后关联一个计数器。
一开始计数器值为0,说明该锁没有被任何线程占用。当一个线程获取了该锁时计数器的值会变成1,这时其他线程再来获取该锁时会发现锁的所有者不是自己而被阻塞挂起。
但是当获取了该锁的线程再次获取锁时发现锁拥有者是自己就会把计数器值加1,当释放锁后计数器值-1。
当计数器值为0时锁里面的线程标示被重置为null,这时候被阻塞的线程会被唤醒来竞争获取该锁。
自旋锁
由于Java中的线程是与操作系统中的线程一一对应的所以当一个线程在获取锁(比如独占锁)失败后会被切换到内核状态而被挂起。
当该线程获取到锁时又需要将其切换到内核状态而唤醒该线程。
而从用户状态切换到内核状态的开销是比较大的在一定程度上会影响并发性能。
自旋锁则是当前线程在获取锁时如果发现锁已经被其他线程占有它不马上阻塞自己在不放弃CPU使用权的情况下多次尝试获取(默认次数是10,可以使用-XX:PreBlockSpinsh参数设置该值),很有可能在后面几次尝试中其他线程已经释放了锁。
如果尝试指定的次数后仍没有获取到锁则当前线程才会被阻塞挂起。
由此看来自旋锁是使用CPU时间换取线程阻塞与调度的开销但是很有可能这些CPU时间白白浪费了。
