Amazon DynamoDBLockClient调试时心跳不更新致锁异常咨询

核心逻辑梳理 #

AmazonDynamoDBLockClient的锁续约依赖独立后台线程定期向DynamoDB更新锁的过期时间。当断点调试或线程暂停时，若心跳线程被间接阻塞，锁的过期时间无法及时续期，超过配置的leaseDuration后会被判定为失效，此时重试获取锁就会抛出LockCurrentlyUnavailableException；断点释放后心跳线程恢复执行，锁续约正常，异常随之消失。

具体排查方向 #

• 检查心跳线程池是否与业务线程共享
  默认情况下，锁客户端会创建专属线程池处理心跳，但如果你的代码通过AmazonDynamoDBLockClientOptions.builder().withExecutorService(...)手动指定了线程池，且该线程池同时承载业务逻辑，当业务线程被断点阻塞占满线程池时，心跳线程无法获得执行机会，直接导致心跳停止。
  排查动作：查看锁客户端初始化代码，确认是否复用了业务线程池，若有则改为单独的心跳线程池。

• 排查业务代码中的全局同步阻塞点
  如果业务代码在持有锁的临界区内，使用了全局同步锁（比如synchronized块、ReentrantLock），而心跳线程在更新锁时也需要访问同一锁资源，就会被断点暂停的业务线程阻塞。
  排查动作：搜索代码中所有同步块/锁对象，重点关注锁持有期间执行的逻辑；断点暂停时用jstack工具查看心跳线程状态（是否处于BLOCKED），顺着栈信息定位阻塞源。

• 检查DynamoDB客户端的连接与请求阻塞
  若使用单例AmazonDynamoDB客户端，业务线程断点时可能占用了客户端连接池，或阻塞了请求队列，导致心跳续约请求无法发送到DynamoDB。
  排查动作：查看ClientConfiguration中的连接池大小、超时时间配置，确认资源是否充足；断点暂停时查看客户端日志或抓包，验证心跳请求是否被卡住。

• 验证leaseDuration与心跳间隔的配置合理性
  心跳间隔默认是leaseDuration的1/3，若leaseDuration设置过短，即使心跳线程短暂阻塞，也容易触发锁过期。可以临时调大leaseDuration（比如从10秒改为30秒），观察问题是否缓解，以此验证是否为心跳延迟导致的过期。

快速验证手段 #

断点暂停时，用jstack打印线程栈，找到名称包含AmazonDynamoDBLockClient的心跳线程，查看其状态：

• 若为BLOCKED：说明被其他线程持有的锁阻塞，顺着栈信息定位锁对象即可找到问题根源。
• 若为WAITING：大概率是线程池资源不足，或等待业务逻辑的信号触发。
• 若为RUNNABLE但无请求发出：可能是DynamoDB客户端的请求链路被阻塞。

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