避免活跃性危险(第十章)

避免活跃性危险

在安全性与活跃性之间通常存在着某种制衡,我们使用加锁机制来确保线程安全,但如果过度地使用加锁,则可能导致“锁顺序死锁”。同样,我们使用线程池和信号量来限制对资源的使用,但这些被限制的行为可能会导致资源死锁。

1. 死锁

  • 锁顺序死锁:两个线程试图以不同的顺序来获得相同的锁,如果按照相同的顺序来请求锁,那么就不会出现循环的加锁依赖性,因此也就不会产生死锁。
    在制定锁的顺序时,可以使用System.identityHashCode方法,该方法返回有Object.hashCode返回的值,通过比较大小等方法定义锁的顺序。在某些情况下,两个对象可能拥有相同的散列值,此时必须通过某种方法来决定锁的顺序,而这可能会重新引入死锁,为了避免这种情况,可以使用“加时赛”锁,在获得两个对象的锁之前,首先获得这个加时赛锁,从而保证每次只有一个线程以未知的顺序获得这两个锁。
  • 在协作对象之间发生的死锁
    如果在持有锁的情况下调用某个外部方法,那么就需要警惕在协作对象之间发生死锁。

        如果在持有锁时调用某个外部方法,那么将出现活跃性问题,在这个外部方法中可能会获得其他锁(这可能会产生死锁),或者阻塞时间过长,导致其他线程无法及时获得当前被持有的锁。
        
    
  • 开放调用
    如果在调用某个方法时不需要持有锁,那么这种调用被称为开放调用。

        在程序中应尽量使用开放调用。与那些在持有锁时调用外部方法的程序相比,更易于对依赖于开放调用的程序进行死锁分析。
        
  • 资源死锁
  1. 线程饥饿死锁。如果某些任务需要等待其他任务的结果,那么这些任务往往是产生线程饥饿死锁的主要来源。
  2. 有界线程池/资源池与相互依赖的任务不能一起使用

2. 死锁的避免与诊断

  1. 如果一个程序每次至多只能获得一个锁,那么就不会产生锁顺序死锁。
  2. 如果必须获取多个锁,那么在设计时必须考虑锁的顺序:尽量减少潜在的加锁交互数量,将获取锁时需要遵循的协议写入正式文档并始终遵循这些协议。
  3. 在使用细粒度锁的程序中,可以通过使用一种两阶段策略来检查代码中的死锁:首先,找出在什么地方将获取多个锁,然后对所有这些实例进行全局分析,从而确保它们在整个程序中获取锁的顺序都保持一致。
  4. 使用显示锁Lock类中的定时tryLock功能,在等待超过指定时间后tryLock会放回一个失败信息。

3. 其他活跃性危险

  1. 饥饿:当线程由于无法访问它所需要的资源而不能继续执行时,就发生了“饥饿”。

引发饥饿的最常见资源就是CPU时钟周期,如果在Java应用程序中对线程的优先级使用不当,或者在持有锁时执行一些无法结束的结构(例如无限循环,或者无限制地等待某个资源),那么也可能导致饥饿,因为其他需要这个锁的线程将无法得到它。线程优先级并不是一种直观的机制,而通过修改线程优先级所带来的效果通常也不明显。当提高某个线程的优先级时,可能不会起到任何作用,或者也可能使得某个线程的调度优先级高于其他线程,从而导致饥饿。

  1. 活锁(Livelock)

活锁是另一种形式的活跃性问题,该问题不会导致线程阻塞,但也不能继续执行。因为线程将不断重复执行相同的操作,而且总会失败
活锁通常发生在处理事务消息的应用程序中:如果不能成功处理某个消息,那么消息处理机制将回滚整个事务,并将它重新放到队列的开头。当多个相互协作的线程都对彼此进行响应从而修改各自的状态,并使得任何一个线程无法继续执行时,就发生了活锁,在并发应用程序中,通过等待随机长度的时间和回退可以有效避免活锁的发生。

点赞