jvm线程死锁怎么解决
什么时候需要分布式锁？
什么时候需要分布式锁？
分布式锁也是锁在单体应用的时候，如果多个线程要访问共享资源的时候，我们通常线程间加锁的机制，在某一个时刻，只有一个线程可以对这个资源进行操作，其他线程需要等待锁的释放，Java中也有一些处理锁的机制，比如synchronized。
而到了分布式的环境中，当某个资源可以被多个系统访问使用到的时候，为了保证大家访问这个数据是一致性的，那么就要求再同一个时刻，只能被一个系统使用，这时候线程之间的锁机制就无法起到作用了，因为分布式环境中，系统是会部署到不同的机器上面的，那么就需要【分布式锁】了。
什么时候需要使用分布式锁总结来看，当有多个客户端需要访问并操作同一个资源，还需要保持这个资源一致性的时候，就需要使用【分布式锁】，让多客户端互斥的对共享资源进行访问。
举个例子来说明一下：
有多个批处理任务，两台机器同时处理，如果不加任何控制的话，很有可能同一个批处理被两台机器分别处理一遍；如果使用分布式锁，在领取任务的时候，一个任务只会被一台机器领到，这样就不会造成任务的重复执行；
再多思考一些，如果A/B两台机器，任务1被A机器领取到进行处理，在处理到一半的时候，A机器挂掉了，那么这个批处理任务也就无法顺利执行了，除非A机器可以恢复。
这时候就可以知道分布式锁需要做哪些工作了排他性：在同一时间只会有一个客户端能获取到锁，其它客户端无法同时获取；避免死锁：锁在一段时间内有效，超过这个时间后会被释放（正常释放或异常释放）；高可用：获取或释放锁的机制必须高可用且性能佳。我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
lock锁实际使用场景？
场景1：如果发现该操作已经在执行中则不再执行（有状态执行）
a、用在定时任务时，如果任务执行时间可能超过下次计划执行时间，确保该有状态任务只有一个正在执行，忽略重复触发。
b、用在界面交互时点击执行较长时间请求操作时，防止多次点击导致后台重复执行（忽略重复触发）。
以上两种情况多用于进行非重要任务防止重复执行，（如：清除无用临时文件，检查某些资源的可用性，数据备份操作等）
场景2：如果发现该操作已经在执行，等待一个一个执行（同步执行，类似synchronized）
这种比较常见大家也都在用，主要是防止资源使用冲突，保证同一时间内只有一个操作可以使用该资源。
但与synchronized的明显区别是性能优势（伴随jvm的优化这个差距在减小）。同时Lock有更灵活的锁定方式，公平锁与不公平锁，而synchronized永远是公平的。
这种情况主要用于对资源的争抢（如：文件操作，同步消息发送，有状态的操作等）
ReentrantLock默认情况下为不公平锁
场景3：如果发现该操作已经在执行，则尝试等待一段时间，等待超时则不执行（尝试等待执行）
这种其实属于场景2的改进，等待获得锁的操作有一个时间的限制，如果超时则放弃执行。
用来防止由于资源处理不当长时间占用导致死锁情况（大家都在等待资源，导致线程队列溢出）。
场景4：如果发现该操作已经在执行，等待执行。这时可中断正在进行的操作立刻释放锁继续下一操作。
synchronized与Lock在默认情况下是不会响应中断(interrupt)操作，会继续执行完。lockInterruptibly()提供了可中断锁来解决此问题。（场景2的另一种改进，没有超时，只能等待中断或执行完毕）
这种情况主要用于取消某些操作对资源的占用。如：（取消正在同步运行的操作，来防止不正常操作长时间占用造成的阻塞）