我们知道一个对象可以有synchronized方法或其他形式的加锁机制来防止别的线程在互斥还没释放的时候就访问这个对象。而且我们知道线程是会变成阻塞状态的(挂起),所以有时候就会发生死锁的情况:某个任务在等待另一个任务,而后者又在等待其它任务,这样一直下去,知道这个链条下的任务又在等待第一个任务释放锁,这样就形成了一个任务之间相互等待的连续循环,没有任务可以继续的情况。死锁的最大问题在于它发生的几率非常小,并不是我们一运行程序它就死锁了,而是会不知道那个时候程序就死锁并且我们很难重现当时出现死锁的情况。在这篇博客里我们只是从哲学家就餐问题的程序中感受下死锁现象,随便结合分析下出现死锁的几个条件,并不会讨论如何避免/解决死锁问题。
哲学家就餐问题是一个经典的关于死锁的问题,其大概的描述是:有五个哲学家,他们会花部分时间思考,花部分时间就餐。当他们思考的时候,他们不需要共享任何资源互不影响。而当他们就餐时,因为这里只有五只筷子,在他们每人都需要两只筷子的情况下,就会形成对筷子的竞争。这个问题并不是说百分百的会死锁,仅仅是存在这种可能而已。下面的代码就演示了这个问题,在注释里有对更多的细节的解释:
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
在上面的程序中我们可以设定了哲学家的思考时间和就餐时间都为一个随机时间,并且我们可以通过pauseFactor来对其进行调节,多次设定这个值然后运行程序就会发现当pauseFactor的值较小的时候发生死锁的概率就比较大,当pauseFactor为0即哲学家不花时间进行思考而总是去抢筷子的时候,几乎每次都会发生死锁。这就说明对资源的竞争越激烈就越容易发生死锁。
学过操作系统的都知道要发生死锁有四个条件需要满足,下面我们就结合上面的问题来分析下这四个条件:
1).互斥。线程使用的资源中至少有一个是不能共享的。这里,一根Chopstick一次就只能被一个Philosopher使用
2).至少有一个任务它必须持有一个资源且正在等待获取一个当前被别的任务持有的资源。也就是说,要发生死锁,Philosopher必须持有一个Chopstick并正在等待另一根。
3).资源不能被任务抢占,任务必须把释放资源当成普通事件。在上面中Philosopher不会去抢其它Philosopher手中的Chopstick。
4).必须有循环等待,这时候一个任务等待其它任务所持有的资源,后者又在等待另一个任务持有的资源,这样一直下去,直到一个任务在等待第一个任务所持有的资源。在上面的代码中每个Philosopher都会试图得到左边的Chopstick然后得到右边的Chopstick,这样就产生了循环等待。
死锁出现必须要满足上面四个条件,所以避免死锁的方法就是破坏四个条件中的一个。上面有一段注释掉的代码通过调整最后一位哲学家获取Chopstick的顺序(与其它哲学家相反)而达到了破坏第四个循环等待条件的效果,从而防止了死锁的产生。其它的防止死锁的方法就不在这里讨论了。Java中并没有从语言层面上有防止死锁的措施,所以要防止死锁的产生,只有靠我们自己的小心谨慎了。