在最近的开发调试当中，一个多线程的项目出现了线程死锁的问题。按照正常的解决思路，上监控工具yourkit或者自己打印出线程信息，最终的显示信息均为lock对象先拿到了自己的锁，然后去拿对方的锁，现状是这样的。但与一些正常的项目相比，按照正常的执行情况，是不可能出现死锁的。
项目使用了程序锁来保证并发情况下，一些操作只能由单个来执行，如一些不允许多次运行的场景。所谓程序锁，即通过由锁池获取相应的lock对象，然后进行lock操作，在相应的方法体内进行相应的控制。
项目中使用基于guava的striped来获取不同的锁，本来原来的代码是自己封装实现，但考虑到guava已经提供，因此直接使用了，相应的伪代码如下所示：
Striped<Lock> lockStriped = Striped.lazyWeakLock(1024);
Lock lock = lockStriped.get("动态生成的临界资源标识符");
lock.lock();
try{
//执行业务操作
} finally {
lock.unlock();
}
以上的代码因为足够的通用，因此被封装为一个LockAdvice，以实现通用的锁方法操作，只需要在需要加锁的方法上加上Lockable注解，就可以达到所要的效果。出现死锁的2个线程表现如下：
//线程1 加锁获取资源类型1 加锁获取资源类型2 //线程2 加锁获取资源类型1 加锁获取类型类型2
从上面的线程操作来看，加锁的顺序是一样的，释放锁的顺序也一致,因此理论上不会出现死锁。为保证锁切面的简单实现，上面的锁资源类型1 被表现为一个字符串，即通过不同的字符串来进行描述。也就是说，在上面的现象中，会有4个字符串进行锁的key进行操作。
问题场景被发现了，并且这个问题肯定会产生，多线程运行一段时间之后就会发生。查找问题产生的原因却很漫长。不知道为什么，使用jstack却没有打印出每个线程在哪一个环节持有哪个锁(是不是本身就没有)，通过jstack的信息表示，相应的线程肯定持有对方的锁，而对方也在等级已方的锁，并且相应的锁的发生点也确定是在相应的锁切面准备执行的时候。剩下的问题就是看是否是相应的锁生成器striped本身就返回了相同的锁，如果由锁生成器本身就返回相同的锁，那么就肯定有问题了。