android死锁线程

前面提到了多线程死锁的一些条件，因此要解决死锁，必须先从条件开始. 通常，可以通过以下两种方法解决该问题.

1. 减少或避免资源共享

一个资源由多个线程共享. 如果采用同步机制，则极有可能发生死锁. 尤其是在大型项目的情况下，很难消除死锁. 最好的解决方案是减少资源共享.

例如，具有B / S结构的办公系统可以完全忽略资源共享，因为这种类型的系统具有三种类型的特征: 第一，并发访问不会太高；第二，读取操作多于写入操作，第三，数据质量要求相对较低，因此，即使数据资源不同步，也不大可能产生太大影响，并且可以完全消除同步技术. 但是，如果是付款和清算系统，则必须仔细考虑资源同步问题. 因此，此类系统对数据质量的要求很高（如果数据不同步，则是主要的生产事故），但是并发量很大且没有设置. 数据同步将导致大量的操作逻辑失败，从而导致事务失败，大量“脏”数据，并大大降低系统可靠性.

2. 使用自旋锁

例如，线程A正在等待线程B释放资源，线程B正在等待线程A释放资源，并且僵局无法停止. 然后，如果线程B设置了超时，它可以解决死锁问题吗？例如，线程B等待2秒后仍然无法获取资源多线程避免死锁，然后自行终止任务，代码如下:

上面的代码使用tryLock实现自旋锁（Spin Lock），它与互斥锁相同. 如果执行单元要访问受自旋锁保护的共享资源，则必须首先获取该锁. 共享资源后，还必须释放该锁. 如果在获取自旋锁时没有执行单元持有该锁，则将立即获得该锁；如果锁获取操作将在那里“旋转”，直到按住旋转锁以释放该锁. 在上面的代码中，如果继续尝试在2s内获取锁多线程避免死锁，如果无法在2s内获取锁资源，则自旋锁所在的线程将停止运行，而另一个线程将获取资源以继续运行并释放了死锁.

描述僵局的最经典案例是哲学家的饭菜（五位哲学家坐在圆餐桌旁，每个人用筷子做两件事: 进食和思考. 思考时停止思考，停止进食）有很多方法可以解决此问题，例如引入服务员（资源调度），资源分级和其他方法可以解决这种类型的死锁问题.

在我们的Java多线程并发编程中，死锁很难避免，而且很难避免. 解决该问题的最佳方法是测试: 提高测试覆盖率，建立有效的边界测试并加强资源监控. 这些方法也可以避免死锁，即使发生死锁现象，也可以迅速找到原因，并提高了系统的可靠性.

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-245644-1.html