上一篇
Java中避免死锁可通过统一锁获取顺序、使用定时锁尝试机制、采用JUC工具类替代显式锁、降低锁粒度等方式实现
Java并发编程中，死锁是一个复杂且棘手的问题，它会导致程序停滞不前，严重影响系统性能和稳定性,以下是一些有效的策略来避免死锁：
破坏死锁产生的四个必要条件
- 互斥条件：资源一次只能被一个线程占用，这是无法改变的，因为很多资源本身就具有排他性,如文件写入等操作必须独占资源才能保证数据的一致性。
- 占有并等待：线程持有已获得的锁的同时请求新的锁，可以通过一次性获取所有需要的锁的方式打破这一条件，也就是说，在开始执行临界区代码之前，线程应尽可能多地申请所需的全部资源，要么全部成功获得，要么都不获取，这样就不会出现先占有一部分资源再等待其他资源的情况，如果一个线程需要锁A和锁B才能完成任务，那么它应该同时尝试获取这两个锁,而不是先获取了锁A后再去等待锁B。
- 不可抢占：已分配给线程的资源不能被其他线程强行夺取，只能由该线程自己释放，这个条件通常也难以直接破坏，但我们可以通过设置锁的超时机制来进行间接干预，当一个线程尝试获取某个锁超过一定时间仍未成功时，它可以主动放弃已经持有的相关锁,并回退到初始状态重新尝试获取所需的锁序列。
- 循环等待：存在一种进程资源的循环链，每个进程都在等待下一个进程所持有的资源，为了避免这种情况的发生，可以采用资源排序法（Resource Ordering），即对所有涉及的资源进行全局排序，确保所有线程都按照相同的顺序去获取这些锁，规定总是先获取编号较小的锁，再获取编号较大的锁,这样就可以有效防止因不同的获取顺序而形成的环形等待关系。
具体的编码实践与工具运用
| 方法 | 描述 | 示例/实现方式 | 优点 | 缺点 |
|---|---|---|---|---|
使用tryLock()代替lock() |
为ReentrantLock等锁对象的尝试获取方法设定超时时间；若指定时间内未能获得锁则放弃本次请求 | java<br>ReentrantLock lock = new ReentrantLock();<br>if (lock.tryLock(timeout, unit)) { try { // 执行业务逻辑 } finally { lock.unlock(); } } else { // 处理未拿到锁的情况 } |
避免无限期阻塞导致的死锁风险；提高系统的响应性和灵活性 | 可能导致频繁重试，影响性能；需要合理设置超时时间和重试策略 |
| 遵循固定的加锁顺序 | 多个锁之间确定一个统一的获取顺序，所有线程均按此顺序申请锁 | 假设有锁A、B、C，约定所有线程都按照A→B→C的顺序加锁 | 简单易行，能有效消除循环等待的可能性 | 增加了程序员的记忆负担；对于动态变化的依赖关系不够灵活 |
| 使用非阻塞算法或无锁数据结构 | 采用CAS（Compare And Swap）、原子变量类等底层支持来实现无需传统互斥锁的操作 | 利用AtomicInteger实现计数器的自增操作而无需同步块 | 减少竞争带来的延迟，提升吞吐量 | 代码复杂度较高；适用范围有限，并非所有场景都适用 |
其他辅助措施
- 减少并发量：在某些情况下，适当降低同时访问共享资源的线程数量可以减少锁冲突的概率，这可能会以牺牲一定的并发性能为代价,可以通过限制线程池的大小或者调整任务队列的长度等方式来实现。
- 死锁检测与恢复机制：部分Java库和框架提供了死锁检测功能，如Java SE 5中的java.util.concurrent.locks.ReentrantLock类的lockInterruptibly()方法，当检测到死锁发生时，可以采取相应的恢复措施，如中断某些线程使其释放持有的锁，从而打破死锁局面，这种方法会增加系统的开销,并且实现起来较为复杂。
FAQs
- 问：为什么使用了固定加锁顺序就能有效避免死锁？
答：因为固定加锁顺序确保了所有线程都以相同的次序请求锁，从而消除了循环等待的可能性，只要每个线程都严格按照既定的顺序去获取锁，就不会出现一个线程等着另一个线程释放自己正在等待的下一个锁的情况,进而避免了死锁的发生。 - 问：tryLock()方法在实际开发中应该如何合理设置超时时间和重试次数？
答：这取决于具体的应用场景和性能需求，超时时间应该足够短以避免长时间的无效等待，但又不宜过短导致过多的重试失败，重试次数也需要根据系统的负载情况进行调整，通常建议通过实验测试来确定最佳的参数组合,以达到既能够有效避免死锁又不会过度影响系统性能的目的。
避免Java中的死锁需要从多个方面入手，包括破坏死锁产生的必要条件、采用合理的编码实践以及运用适当的工具和技术，通过综合运用这些策略，可以显著降低死锁发生的概率，提高系统的稳定性
