锁在什么时候释放?

2014/9/4

分为两种情况:

一。在该线程的同步方法,同步代码块中。

1.该线程的同步方法、同步代码块执行完。

2.该线程同步方法、同步代码块中遇到return,break.

3.该线程同步方法、同步代码块中发生了未处理的Exception、Error

二、在其他线程中。

4.其他线程执行了同步监听器对象的wait().

5.其他线程执行了当前线程的stop.

在以下情况中,线程不会释放锁。(在当前线程的同步代码中)

1.在该线程的同步方法,同步代码块中thread.sleep(),thread.yield().

2.其他线程调用了该线程的suspend()方法。

便于记忆:

在当前线程的同步代码块中

线程停止(线程停止只有run()方法结束,而run()方法结束,包含下述述情况)。(stop方法失效)

会引起锁释放的条件:

1.同步方法、同步代码块执行完。

2.同步方法、同步代码块中遇到return,break.

3.同步方法、同步代码块中发生了未处理的Exception、Error

4.同步方法、同步代码块中,wait();

不会引起锁释放:

1.Thread.sleep();

2.Thread.yield();

时间: 2024-08-10 21:17:57

锁在什么时候释放?的相关文章

可重入锁的获取和释放需要注意的一点儿事

什么是可重入锁,不可重入锁呢?"重入"字面意思已经很明显了,就是可以重新进入.可重入锁,就是说一个线程在 获取某个锁后,还可以继续获取该锁,即允许一个线程多次获取同一个锁.比如synchronized内置锁就是可重入的 ,如果A类有2个synchornized方法method1和method2,那么method1调用method2是允许的.显然重入锁给编程带 来了极大的方便.假如内置锁不是可重入的,那么导致的问题是:1个类的synchornized方法不能调用本类其他 synchorn

可重入锁的获取和释放须要注意的一点儿事

什么是可重入锁,不可重入锁呢?"重入"字面意思已经非常明显了,就是能够又一次进入.可重入锁,就是说一个线程在 获取某个锁后,还能够继续获取该锁,即同意一个线程多次获取同一个锁.比方synchronized内置锁就是可重入的 ,假设A类有2个synchornized方法method1和method2,那么method1调用method2是同意的. 显然重入锁给编程带 来了极大的方便.假如内置锁不是可重入的,那么导致的问题是:1个类的synchornized方法不能调用本类其它 synch

追踪SQL Server执行delete操作时候锁的申请与释放过程

一直以为很了解sqlserver的加锁过程,在分析一些特殊情况下的死锁之后,尤其是并发单表操作发生的死锁,对于加解锁的过程,有了一些重新的认识,之前的知识还是有一些盲区在里面的.delete加锁与解锁步骤是怎么样的?什么时候对那些对象,加什么类型的琐,加锁与索引的关系是怎么样的,什么时候释放锁?整个过程锁是如何参与整个delete操作过程表的?这里通过一个非常简单的delete语句,来分析一条delete执行过程中加解锁的过程. 测试表创建 用一个最最简单的例子做了跟踪,对锁的申请和释放,有了更

SQLServer 事务隔离级别与锁的申请和释放

脏读:当一个事务开始更新数据,但是这个事务并没有完全提交,这个时候第二个事务开始读取数据,把第一个事务所更改的数据读了出来, 第二个事务读取的数据时临时的,因为有可能第一个事务最终有可能做回滚操作 不可重复读:在一个事务中多次读取某一行数据,可能会得到不同的结果 幻读:在一个事务中,我们读取数据,发现没有特定的行,第一个事务还没结束,这个时候第二个事务插入了该行数据, 然后在第一个事务再次读取时,该行数据突然出现了 SQLServer数据库支持一下隔离级别:未提交读.已提交读.可重复读.快照.可

事务的隔离级别与锁的申请和释放

脏读(Dirty Read)     脏读意味着一个事务读取了另一个事务未提交的数据,而这个数据是有可能回滚 不可重复读(Unrepeatable Read) 不可重复读意味着,在数据库访问中,一个事务范围内两个相同的查询却返回了不同数据.这是由于查询时系统中其他事务修改的提交而引起的. 例如:事务B中对某个查询执行两次,当第一次执行完时,事务A对其数据进行了修改.事务B中再次查询时,数据发生了改变 幻读(phantom read) 幻读,是指当事务不是独立执行时发生的一种现象,例如第一个事务对

数据库锁表查询及释放锁

锁表查询 SELECT object_name, machine, s.sid, s.serial# FROM gv$locked_object l, dba_objects o, gv$session s WHERE l.object_id = o.object_id AND l.session_id = s.sid; 释放锁 --alter system kill session 'sid, serial#'; ALTER system kill session '413, 3701';

图解源码之java锁的获取和释放(AQS)篇

以独占式不公平锁为例,通过5个线程争夺ReentrantLock的过程,图解ReentrantLock源码实现,了解显示锁的工作流程. 任何时刻拿到锁的只有一个线程,未拿到锁的线程会打包成节点(node),然后将节点通过CAS自旋的方式,从队列尾部放入同步队列中. 增加尾节点为什么要用cas,因为会存在多个线程竞争尾节点. 以上便是线程竞争锁的过程,以及竞争失败之后需要做的全部事情. 以上便是线程获取和释放锁的全过程,可用如下流程图进行归纳.   另外,以上源码均来自jdk1.8,本文章作为梳理

文件记录锁的释放

引言:apue中提到文件记录锁的释放中的两条规则:当进程终止的时候,进程在文件上建立的记录锁会全部释放:当关闭文件,执行close(fd)函数的时候,进程释放描述符可以引用的文件上的任何一把锁.对于第一条规则的理解应该没有分歧.但对于第二条规则的理解,则会出现疑惑,执行close(fd)的时候,是仅仅释放closf(fd)调用进程在文件上的记录锁,还是会释放所有进程(包括非调用进程)在文件上的记录锁.本文通过具体相关程序对此问题进行验证. 思路:需要设计验证程序对此问题进行验证,通过fork产生

Informix如何释放异常的锁资源

问题 在Informix数据库中,锁的使用和释放是自动完成的.但在某些异常情况下,当前台程序退出(正常或异常)后,相应在数据库中的会话没有终止,其占有的资源(主要是锁)没有被释放,影响了其他用户的使用. 这种情况可能出现在用户表或系统表中,一般都是由于产品的BUG或非常极端的情况引起的. 这时需要用手工的方式将有问题的会话终止,以释放其占有的资源,当然重新启动数据库自然就释放了所有的资源了,但有时业务上暂时不允许重新启动. 第一步,确定被锁住的资源 一般在遇到这种情况时,很容易确定被锁住的资源,