避免活跃性危险
在安全性与活跃性之间通常存在着某种制衡，我们使用加锁机制来确保线程安全，但如果过度地使用加锁，则可能导致“锁顺序死锁”。同样，我们使用线程池和信号量来限制对资源的使用，但这些被限制的行为可能会导致资源死锁。
1. 死锁
-
锁顺序死锁：两个线程试图以不同的顺序来获得相同的锁，如果按照相同的顺序来请求锁，那么就不会出现循环的加锁依赖性，因此也就不会产生死锁。 在制定锁的顺序时，可以使用System.identityHashCode方法，该方法返回有Object.hashCode返回的值，通过比较大小等方法定义锁的顺序。在某些情况下，两个对象可能拥有相同的散列值，此时必须通过某种方法来决定锁的顺序，而这可能会重新引入死锁，为了避免这种情况，可以使用“加时赛”锁，在获得两个对象的锁之前，首先获得这个加时赛锁，从而保证每次只有一个线程以未知的顺序获得这两个锁。
-
在协作对象之间发生的死锁 如果在持有锁的情况下调用某个外部方法，那么就需要警惕在协作对象之间发生死锁。 如果在持有锁时调用某个外部方法，那么将出现活跃性问题，在这个外部方法中可能会获得其他锁（这可能会产生死锁），或者阻塞时间过长，导致其他线程无法及时获得当前被持有的锁。
-
开放调用 如果在调用某个方法时不需要持有锁，那么这种调用被称为开放调用。 在程序中应尽量使用开放调用。与那些在持有锁时调用外部方法的程序相比，更易于对依赖于开放调用的程序进行死锁分析。
-
资源死锁
- 线程饥饿死锁。如果某些任务需要等待其他任务的结果，那么这些任务往往是产生线程饥饿死锁的主要来源。
- 有界线程池/资源池与相互依赖的任务不能一起使用
2. 死锁的避免与诊断
- 如果一个程序每次至多只能获得一个锁，那么就不会产生锁顺序死锁。
- 如果必须获取多个锁，那么在设计时必须考虑锁的顺序：尽量减少潜在的加锁交互数量，将获取锁时需要遵循的协议写入正式文档并始终遵循这些协议。
- 在使用细粒度锁的程序中，可以通过使用一种两阶段策略来检查代码中的死锁：首先，找出在什么地方将获取多个锁，然后对所有这些实例进行全局分析，从而确保它们在整个程序中获取锁的顺序都保持一致。
- 使用显示锁Lock类中的定时tryLock功能，在等待超过指定时间后tryLock会放回一个失败信息。
3. 其他活跃性危险
- 饥饿：当线程由于无法访问它所需要的资源而不能继续执行时，就发生了“饥饿”。
引发饥饿的最常见资源就是CPU时钟周期，如果在Java应用程序中对线程的优先级使用不当，或者在持有锁时执行一些无法结束的结构（例如无限循环，或者无限制地等待某个资源），那么也可能导致饥饿，因为其他需要这个锁的线程将无法得到它。线程优先级并不是一种直观的机制，而通过修改线程优先级所带来的效果通常也不明显。当提高某个线程的优先级时，可能不会起到任何作用，或者也可能使得某个线程的调度优先级高于其他线程，从而导致饥饿。
通常，我们尽量不要改变线程的优先级。只要改变了线程的优先级，程序的行为就将与平台相关，并且会导致发生饥饿问题的风险。 Thread.yield以及Thread.sleep的语义都是UB，JVM既可以将他们实现为空操作，也可以将它们视为线程调度的参考。
- 活锁（Livelock）
活锁是另一种形式的活跃性问题，该问题不会导致线程阻塞，但也不能继续执行。因为线程将不断重复执行相同的操作，而且总会失败。 活锁通常发生在处理事务消息的应用程序中：如果不能成功处理某个消息，那么消息处理机制将回滚整个事务，并将它重新放到队列的开头。当多个相互协作的线程都对彼此进行响应从而修改各自的状态，并使得任何一个线程无法继续执行时，就发生了活锁，在并发应用程序中，通过等待随机长度的时间和回退可以有效避免活锁的发生。