java中怎么查看数据库是否锁表

首先synchronized不可能做到对某条数据库的数据加锁。它能做到的只是对象锁。

比如数据表table_a中coloum_b的数据是临界数据，也就是你说的要保持一致的数据。你可以定义一个类，该类中定义两个方法read()和write()(注意，所有有关该临界资源的

通过查询结果中的object_id，可以查询到具体被锁的对象再给你看看我查到的一些关于锁的资料：锁有以下几种模式: 0：none 1：null 空 2：Row-S 行共享(RS)：共享表锁 3：Row-X 行专用(RX)：用于行的修改 4：Share 共享锁(S)：阻止其他DML *** 作 5：S/Row-X 共享行专用(SRX)：阻止其他事务 *** 作 6：exclusive 专用(X)：独立访问使用数字越大锁级别越高, 影响的 *** 作越多。一般的查询语句如select from ;是小于2的锁, 有时会在v$locked_object出现。 select from for update; 是2的锁。当对话使用for update子串打开一个游标时，所有返回集中的数据行都将处于行级(Row-X)独占式锁定，其他对象只能查询这些数据行，不能进行update、delete或selectfor update *** 作。 insert / update / delete ; 是3的锁。没有commit之前插入同样的一条记录会没有反应, 因为后一个3的锁会一直等待上一个3的锁, 我们必须释放掉上一个才能继续工作。创建索引的时候也会产生3,4级别的锁。 locked_mode为2,3,4不影响DML(insert,delete,update,select) *** 作, 但DDL(alter,drop等) *** 作会提示ora-00054错误。有主外键约束时 update / delete ; 可能会产生4,5的锁。 DDL语句时是6的锁。以DBA角色, 查看当前数据库里锁的情况可以用如下SQL语句： select object_id,session_id,locked_mode from v$locked_object; select t2username,t2sid,t2serial#,t2logon_time from v$locked_object t1,v$session t2 where t1session_id=t2sid order by t2logon_time; 如果有长期出现的一列，可能是没有释放的锁。我们可以用下面SQL语句杀掉长期没有释放非正常的锁： alter system kill session 'sid,serial#'; 如果出现了锁的问题, 某个DML *** 作可能等待很久没有反应。当你采用的是直接连接数据库的方式，也不要用OS系统命令 $kill process_num 或者 $kill -9 process_num来终止用户连接，因为一个用户进程可能产生一个以上的锁, 杀OS进程并不能彻底清除锁的问题。

兄弟，锁的作用，就是把权限归为私有，其它人用不了。

你自已把表锁了，自已当然还能用。你起另外一个客户端试试。

而且写锁和读锁，是有区别的。

lock table abc read;

lock table abc write;

12 事务的ACID原则13 锁是关系数据库很重要的一部分, 数据库必须有锁的机制来确保数据的完整和一致性 131 SQL Server中可以锁定的资源:132 锁的粒度:133 锁的升级: 锁的升级门限以及锁升级是由系统自动来确定的，不需要用户设置 134 锁的类型: (1) 共享锁: 共享锁用于所有的只读数据 *** 作 (2) 修改锁: 修改锁在修改 *** 作的初始化阶段用来锁定可能要被修改的资源，这样可以避免使用共享锁造成的死锁现象 (3) 独占锁: 独占锁是为修改数据而保留的。它所锁定的资源，其他事务不能读取也不能修改。独占锁不能和其他锁兼容。 (4) 架构锁 结构锁分为结构修改锁(Sch-M)和结构稳定锁(Sch-S)。执行表定义语言 *** 作时，SQL Server采用Sch-M锁，编译查询时，SQL Server采用Sch-S锁。 (5) 意向锁 意向锁说明SQL Server有在资源的低层获得共享锁或独占锁的意向。 (6) 批量修改锁 批量复制数据时使用批量修改锁 134 SQL Server锁类型 (1) HOLDLOCK: 在该表上保持共享锁，直到整个事务结束，而不是在语句执行完立即释放所添加的锁。 (2) NOLOCK：不添加共享锁和排它锁，当这个选项生效后，可能读到未提交读的数据或“脏数据”，这个选项仅仅应用于SELECT语句。 (3) PAGLOCK：指定添加页锁(否则通常可能添加表锁)。 (4) READCOMMITTED用与运行在提交读隔离级别的事务相同的锁语义执行扫描。默认情况下，SQL Server 2000 在此隔离级别上 *** 作。 (5) READPAST: 跳过已经加锁的数据行，这个选项将使事务读取数据时跳过那些已经被其他事务锁定的数据行，而不是阻塞直到其他事务释放锁， READPAST仅仅应用于READ COMMITTED隔离性级别下事务 *** 作中的SELECT语句 *** 作。 (6) READUNCOMMITTED：等同于NOLOCK。 (7) REPEATABLEREAD：设置事务为可重复读隔离性级别。 (8) ROWLOCK：使用行级锁，而不使用粒度更粗的页级锁和表级锁。

1 从数据库系统的角度来看：分为独占锁（即排它锁），共享锁和更新锁

MS-SQL Server 使用以下资源锁模式。

锁模式 描述

共享 (S) 用于不更改或不更新数据的 *** 作（只读 *** 作），如 SELECT 语句。

更新 (U) 用于可更新的资源中。防止当多个会话在读取、锁定以及随后可能进行的资源更新时发生常见形式的死锁。

排它 (X) 用于数据修改 *** 作，例如 INSERT、UPDATE 或 DELETE。确保不会同时同一资源进行多重更新。

意向锁 用于建立锁的层次结构。意向锁的类型为：意向共享 (IS)、意向排它 (IX) 以及与意向排它共享 (SIX)。

架构锁 在执行依赖于表架构的 *** 作时使用。架构锁的类型为：架构修改 (Sch-M) 和架构稳定性 (Sch-S)。

大容量更新 (BU) 向表中大容量复制数据并指定了 TABLOCK 提示时使用。

◆共享锁

共享 (S) 锁允许并发事务读取 (SELECT) 一个资源。资源上存在共享 (S) 锁时，任何其它事务都不能修改数据。一旦已经读取数据，便立即释放资源上的共享 (S) 锁，除非将事务隔离级别设置为可重复读或更高级别，或者在事务生存周期内用锁定提示保留共享 (S) 锁。

◆更新锁

更新 (U) 锁可以防止通常形式的死锁。一般更新模式由一个事务组成，此事务读取记录，获取资源（页或行）的共享 (S) 锁，然后修改行，此 *** 作要求锁转换为排它 (X) 锁。如果两个事务获得了资源上的共享模式锁，然后试图同时更新数据，则一个事务尝试将锁转换为排它 (X) 锁。共享模式到排它锁的转换必须等待一段时间，因为一个事务的排它锁与其它事务的共享模式锁不兼容；发生锁等待。第二个事务试图获取排它 (X) 锁以进行更新。由于两个事务都要转换为排它 (X) 锁，并且每个事务都等待另一个事务释放共享模式锁，因此发生死锁。

若要避免这种潜在的死锁问题，请使用更新 (U) 锁。一次只有一个事务可以获得资源的更新 (U) 锁。如果事务修改资源，则更新 (U) 锁转换为排它 (X) 锁。否则，锁转换为共享锁。

◆排它锁

排它 (X) 锁可以防止并发事务对资源进行访问。其它事务不能读取或修改排它 (X) 锁锁定的数据。

锁的作用，就是把权限归为私有，其它人用不了。你自已把表锁了，自已当然还能用。

1、表级别的锁定是MySQL各存储引擎中最大颗粒度的锁定机制。该锁定机制最大的特点是实现逻辑非常简单，带来的系统负面影响最小。所以获取锁和释放锁的速度很快。由于表级锁一次会将整个表锁定，所以可以很好的避免困扰我们的死锁问题。

2、数据库锁定机制简单来说就是数据库为了保证数据的一致性而使各种共享资源在被并发访问访问变得有序所设计的一种规则。

3、对于任何一种数据库来说都需要有相应的锁定机制，所以MySQL自然也不能例外。

4、MySQL数据库由于其自身架构的特点，存在多种数据存储引擎，每种存储引擎所针对的应用场景特点都不太一样，为了满足各自特定应用场景的需求，每种存储引擎的锁定机制都是为各自所面对的特定场景而优化设计，所以各存储引擎的锁定机制也有较大区别。

5、总的来说，MySQL各存储引擎使用了三种类型（级别）的锁定机制：行级锁定，页级锁定和表级锁定。下面我们先分析一下MySQL这三种锁定的特点和各自的优劣所在。

当你开始执行一个 ALTER ，而你遇到了可怕的“元数据锁定等待”，我敢肯定你一定遇见过。我最近遇到了一个案例，其中被更改的表要执行一个很小范围的更新（<100行）。ALTER 在负载测试期间一直等待了几个小时。在停止负载测试后，ALTER 按预期在不到一秒的时间内就完成了。那么这里发生了什么？

检查外键

每当有奇数次锁定时，我的第一直觉就是检查外键。当然这张表有一些外键引用了一个更繁忙的表。但是这种行为似乎仍然很奇怪。对表运行 ALTER 时，会针对子表请求一个 SHARED_UPGRADEABLE 元数据锁。还有针对父级的 SHARED_READ_ONLY 元数据锁。

我们来看看如何根据文档获取元数据锁定[1]：

如果给定锁定有多个服务器，则首先满足最高优先级锁定请求，并且与 max_write_lock_count系统变量有关。写锁定请求的优先级高于读取锁定请求。

[1]：>

请务必注意锁定顺序是序列化的：语句逐个获取元数据锁，而不是同时获取，并在此过程中执行死锁检测。

通常在考虑队列时考虑先进先出。如果我发出以下三个语句（按此顺序），它们将按以下顺序完成：

1 INSERT INTO parent2 ALTER TABLE child3 INSERT INTO parent

但是当子 ALTER 语句请求对父进行读取锁定时，尽管排序，但两个插入将在 ALTER 之前完成。以下是可以演示此示例的示例场景：

数据初始化：

CREATE TABLE `parent` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`val` varchar(10) DEFAULT NULL,

PRIMARY KEY (`id`)

) ENGINE=InnoDB;

CREATE TABLE `child` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`parent_id` int(11) DEFAULT NULL,

`val` varchar(10) DEFAULT NULL,

PRIMARY KEY (`id`),

KEY `idx_parent` (`parent_id`),

CONSTRAINT `fk_parent` FOREIGN KEY (`parent_id`) REFERENCES `parent` (`id`) ON DELETE CASCADE ON UPDATE NO ACTION

) ENGINE=InnoDB;

INSERT INTO `parent` VALUES (1, "one"), (2, "two"), (3, "three"), (4, "four");

Session 1:

start transaction;update parent set val = "four-new" where id = 4;

Session 2:

alter table child add index `idx_new` (val);

Session 3:

start transaction;update parent set val = "three-new" where id = 3;

此时，会话 1 具有打开的事务，并且处于休眠状态，并在父级上授予写入元数据锁定。 会话 2 具有在子级上授予的可升级（写入）锁定，并且正在等待父级的读取锁定。最后会话 3 具有针对父级的授权写入锁定：

mysql> select from performance_schemametadata_locks;+-------------+-------------+-------------------+---------------+-------------+| OBJECT_TYPE | OBJECT_NAME | LOCK_TYPE         | LOCK_DURATION | LOCK_STATUS |+-------------+-------------+-------------------+---------------+-------------+| TABLE       | child       | SHARED_UPGRADABLE | TRANSACTION   | GRANTED     | <- ALTER (S2)| TABLE       | parent      | SHARED_WRITE      | TRANSACTION   | GRANTED     | <- UPDATE (S1)| TABLE       | parent      | SHARED_WRITE      | TRANSACTION   | GRANTED     | <- UPDATE (S3)| TABLE       | parent      | SHARED_READ_ONLY  | STATEMENT     | PENDING     | <- ALTER (S2)+-------------+-------------+-------------------+---------------+-------------+

请注意，具有挂起锁定状态的唯一会话是会话 2（ALTER）。会话 1 和会话 3 （分别在 ALTER 之前和之后发布）都被授予了写锁。排序失败的地方是在会话 1 上发生提交的时候。在考虑有序队列时，人们会期望会话 2 获得锁定，事情就会继续进行。但是，由于元数据锁定系统的优先级性质，会话 3 具有锁定，会话 2 仍然等待。

如果另一个写入会话进入并启动新事务并获取针对父表的写锁定，则即使会话 3 完成，ALTER 仍将被阻止。

只要我保持一个对父表打开元数据锁定的活动事务，子表上的 ALTER 将永远不会完成。更糟糕的是，由于子表上的写锁定成功（但是完整语句正在等待获取父读锁定），所以针对子表的所有传入读取请求都将被阻止！

另外，请考虑一下您通常如何对无法完成的语句进行故障排除。您查看已经打开较长时间的事务（在进程列表和 InnoDB 状态中）。但由于阻塞线程现在比 ALTER 线程更年轻，因此您将看到的最旧的事务/线程是 ALTER 。

这正是这种情况下发生的情况。在准备发布时，我们的客户端正在运行 ALTER 语句并结合负载测试（一种非常好的做法！）以确保顺利发布。问题是负载测试保持对父表打开一个活动的写事务。这并不是说它只是一直在写，而是有多个线程，一个总是活跃的。 这阻止了 ALTER 完成并阻止对相对静态的子表的随后的读请求。

幸运的是，这个问题有一个解决方案（除了从设计模式中驱逐外键）。变量 max_write_lock_count[2] 可用于允许在写入锁定之后在读取锁定之前授予读取锁定连续写锁。默认情况下，此变量设置为 18446744073709551615，如果你对该表发出 10,000 次写入/秒，那么你的读将被锁定 5800 万年……

以上就是关于java中怎么查看数据库是否锁表全部的内容，包括:java中怎么查看数据库是否锁表、怎么知道数据库表已经锁表了、mysql锁定了数据库表只能写，为什么还可以读为什么不起作用等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！