并发编程实战学习笔记（七）——避免活跃性问题

╰半橙微兮° 2022-10-01 04:45 172阅读 0赞

## **锁顺序死锁** ##

### **定义** ###

试图以不同的顺序去获得相同的锁，就可能会产生死锁

### **解决办法** ###

如果所有线程以固定的顺序来获得锁，那么在程序中就不会出现锁顺序死锁问题

## **动态的锁顺序死锁** ##

### **原因** ###

锁顺序本身是动态的，无法通过相同的顺序来避免死锁问题

### **解决办法** ###

通过一致哈希算法或者其它方式来统一锁顺序，使未知顺序变为已知顺序。对于极少数的哈希冲突，可以使用“加时赛”锁来解决

private static final Object tieLock = new Object();
    
    public void transferMoney(final Account fromAcct,
                                                final Account toAcct,
                                                final DollarAmount amount)
                               throws InsufficientFundsException{
        class Helper{
            public void transfer throws InsufficientFundsException{
                  if(fromAcct.getBalance().compareTo(amount) < 0){
                      throw new InsufficientFundsException();
                  }else{
                      fromAcct.debit(amount);
                      toAcct.credit(amount);
                  }
              }
        }
    
        int fromHash = System.identifyHashCode(fromAcct);
        int toHash = System.identityHashCode(toAcct);
    
        if(fromHash < toHash){
            synchronized(fromAcct){
                synchronized(toAcct){
                    new Helper.transfer();
                }
            }
        }else if (fromHash > toHash) {
            synchronized(toAcct){
                synchronized(fromAcct){
                    new Helper().transfer();
                }
            }
        } else {
            synchronized(tieLock){
       //加时赛锁来解决问题
                synchronized(fromAcct){
                    synchronized(toAcct){
                        new Helper().transfer();
                    }
                }
            }
        }
    }

## **在协作对象之间发生的死锁** ##

如果在持有锁时调用某个外部方法，那么将出现活跃性问题。在这个外部方法中可能会获取其它锁（这可能会产生死锁），或者阻塞时间过长，导致其它线程无法及时获得当前被持有的锁。  
**锁顺序死锁**可能以这种方式隐式出现

## **开放调用** ##

如果在调用某个方法时不需要持有锁，那么这种调用被称为**开放调用**

### **简化并发程序分析难度的可行思路** ###

*  虽然在没有封装的情况下也能确保线程安全的程序，但对一个使用了封装的程序进行线程安全分析，要比分析没有使用封装的程序容易得多。
 *  分析一个完全依赖开放调用的程序的活跃性，要比分析那些不依赖开放调用的程序的活跃性简单。

### **开放调用的改造思路** ###

*  锁消除；去掉本来要持有的锁
 *  细粒度锁；只锁一小块，调用其它方法时就不需要锁了。

## **资源死锁的类型** ##

独占类型的访问都可以和加锁操作类比，看起来就像需要获得锁才能访问。

*  如果一个任务需要连接两个数据库，并且在请求这两个资源时不会始终遵循相同的顺序，那么线程A可能持有与数据库D1的连接，并等待与数据库D2的连接，而线程B持有D2的连接并等待与D1的连接。资源池越大，就越不容易出现这种类型的死锁。
 *  线程饥饿死锁。如果某些任务需要等待其它任务的结果，那么这些任务往往是产生线程饥饿死锁的主要来源，有界线程池/资源池与相互依赖的任务不能一起使用。

## **死锁的避免思路** ##

*  尽量依赖开放调用。如果一个程序每次至多只能获得一个锁，那么就不会产生锁顺序死锁。
 *  如果必须获取多个锁，那么在设计时必须考虑锁的顺序：尽量减少潜在的加锁交互数量，将获取锁时需要遵循的协议写入正式文档并始终遵循这些协议。
 *  显示使用Lock类中的定时tryLock功能来代替内置锁机制。

## **定时锁的优点** ##

*  当定时锁失败时，你并不需要知道失败的原因。至少你能记录所发生的失败，以及关于这次操作的其它有用信息，并通过一种更平缓的方式来重新启动计算，而不是关闭整个进程。
 *  如果在获取锁时超时，那么可以释放这个锁，然后后退并在一段时间后并再次尝试，从而消除了死锁发生的条件，使程序恢复过来。（这项技术只有在同时获取两个锁时才有效，如果在嵌套的方法调用中请求多个锁，那么即使你知道已经持有了外层的锁，也无法释放它。）

## **饥饿** ##

当线程由于无法访问它所需要的资源而不能继续执行时，就发生了“饥饿”，引发饥饿的最常见资源就是CPU时钟周期。

### **问题** ###

我们尽量不要改变线程的优先级。只要改变了线程的优先级，程序的行为就将与平台相关

### **解释** ###

在Thread API中定义了10个优先级，JVM根据需要将它们映射到操作系统的调度优先级。这种映射与特定平台相关的，因此在某个操作系统中两个不同的Java优先级可能被映射到同一个优于级，而在另一个操作系统中则可能被映射到另一个不同的优先级。在某些操作系统中，如果优先级的数量少于10个，那么有多个java优先级会被映射到同一个优先级。

## **活锁** ##

活锁是另一种形式的活跃性问题，该问题尽管不会阻塞线程，但也不能继续执行，因为线程将不断重复执行相同的操作，而且总会失败。

### **过度错误恢复代码** ###

程序捕捉到错误消息时，会重新把错误消息放入队列或者直接重复操作，这种过度的错误恢复机制，直接导致程序一直在“**处理-错误-发现-重新处理**”的循环中无法跳出  
解决办法就是识别出这种消息，并且跳过处理

### **不恰当地礼让** ###

当多个相互协作的线程都对彼此进行响应从而修改各自的状态，并使得任何一个线程都无法继续执行时，就发生了活锁。这就像两个过于礼貌的人在半路上面对面地相遇，他们彼此都让出对方的路，然而又在另一条路上相遇。因此他们就这样反复地避让下去。  
要解决这种活锁问题，需要在重试机制中引入随机性。在并发应用程序中，通过等待随机长度的时间和回退可以有效避免活锁的发生。