android死锁线程

前面提到了多线程死锁的一些条件，因此要解决死锁，必须先从条件开始。通常，可以通过以下两种方法解决该问题。1。减少或避免资源共享一个资源由多个线程共享。如果采用同步机制，则极有可能发生死锁。尤其是在大型项目的情况下，很难消除死锁。最好的解决方案是减少资源共享。

例如，具有B/S结构的办公系统可以完全忽略资源共享，因为这种类型的系统具有三种类型的特征:第一，并发访问不会太高；第二，读取操作多于写入操作，第三，数据质量要求相对较低，因此，即使数据资源不同步，也不大可能产生太大影响，并且可以完全消除同步技术。

但是，如果是付款和清算系统，则必须仔细考虑资源同步问题。因此，此类系统对数据质量的要求很高（如果数据不同步，则是主要的生产事故），但是并发量很大且没有设置。数据同步将导致大量的操作逻辑失败，从而导致事务失败，大量“脏”数据，并大大降低系统可靠性。

2。使用自旋锁例如，线程A正在等待线程B释放资源，线程B正在等待线程A释放资源，并且僵局无法停止。然后，如果线程B设置了超时，它可以解决死锁问题吗？例如，线程B等待2秒后仍然无法获取资源多线程避免死锁，然后自行终止任务，代码如下:上面的代码使用tryLock实现自旋锁（SpinLock），它与互斥锁相同。

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

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

解决该问题的最佳方法是测试:提高测试覆盖率，建立有效的边界测试并加强资源监控。这些方法也可以避免死锁，即使发生死锁现象，也可以迅速找到原因，并提高了系统的可靠性。