Java应用中MySQL RELEASE_LOCK无法释放锁问题求助

我之前在处理多线程分布式锁的场景时也碰到过类似的问题，结合MySQL的GET_LOCK/RELEASE_LOCK机制，下面是几个最可能导致锁无法释放（返回0）的原因及排查方向：

1. 释放锁的连接并非持有锁的连接 #

GET_LOCK的锁是和MySQL会话（即连接）绑定的，不是和Java线程绑定。也就是说，只有当初调用GET_LOCK的那个连接，才能成功调用RELEASE_LOCK释放锁。如果你的Java应用用了连接池，很容易出现以下问题：

• 线程A借到连接C1，调用GET_LOCK('lock1')成功获取锁；
• 线程A在释放锁前，把连接C1归还到连接池；
• 线程A后续又借到连接C2，调用RELEASE_LOCK('lock1')，此时返回0，因为C2从未持有过这个锁。

排查建议：

• 确保在获取锁到释放锁的整个过程中，线程持有同一个MySQL连接，不要中途归还到连接池；
• 可以在代码中打印连接的标识（比如连接的hashCode），确认获取和释放锁用的是同一个连接。

2. 锁已经被自动释放 #

MySQL会在几种场景下自动释放GET_LOCK获取的锁，此时再调用RELEASE_LOCK自然返回0：

• 持有锁的MySQL会话断开（比如连接被连接池关闭、网络中断）；
• 会话执行了UNLOCK TABLES命令（这个命令会释放所有当前会话持有的命名锁）；
• 同一个会话调用了另一个GET_LOCK（一个会话同一时间只能持有一个命名锁，新的GET_LOCK会自动释放旧锁）。

排查建议：

• 检查代码中在获取锁后，是否有触发连接关闭的逻辑（比如超时回收、异常导致连接归还）；
• 排查是否有其他代码在同一个连接上执行了UNLOCK TABLES或者其他GET_LOCK操作。

3. 锁被其他会话强制释放 #

虽然这种情况比较少见，但如果有其他会话执行了RELEASE_LOCK('your_lock_name')，或者执行了FLUSH TABLES WITH READ LOCK这类全局锁操作，可能会导致目标锁被释放。不过RELEASE_LOCK在非持有锁的会话调用时也会返回0，所以如果是这种情况，你这边的RELEASE_LOCK同样会返回0。

排查建议：

• 检查是否有其他应用、脚本或DBA操作在操作同一个锁名称；
• 开启MySQL的通用日志（general log），追踪所有涉及目标锁名称的SQL操作。

4. MySQL版本或已知bug #

某些旧版本的MySQL存在GET_LOCK/RELEASE_LOCK的一致性问题，比如在高并发场景下，锁的状态可能出现异常。例如MySQL 5.6早期版本、某些Percona Server的衍生版本曾有相关bug报告。

排查建议：

• 查看你的MySQL版本，对比官方文档或bug列表，确认是否存在相关已知问题；
• 如果是旧版本，尝试升级到稳定版本（比如MySQL 5.7+或8.0+）验证问题是否消失。

内容的提问来源于stack exchange，提问作者Nithin Krishna