29.5 死锁

既然 Rust 中提供了“锁”机制，那么 Rust 中是否有可能出现“死锁”的现象呢？我们用经典的“哲学家就餐问题”来演示一下。

问题：假设有 5 个哲学家，共享一张放有 5 把椅子的桌子，每人分得一把椅子，但是，桌子上共有 5 支筷子，在每人两边各放一支，哲学家们在肚子饥饿时才试图分两次从两边拿起筷子就餐。

条件：

拿到两支筷子时哲学家才开始吃饭；
如果筷子已在他人手上，则该哲学家必须等他人吃完之后才能拿到筷子；
任一哲学家在自己未拿到两只筷子前却不放下自己手中的筷子。

代码如下：

rust

use std::thread;
use std::sync::{Mutex, Arc};
use std::time::Duration;

struct Philosopher {
    name: String,
    left: usize,
    right: usize,
}


impl Philosopher {
    fn new(name: &str, left: usize, right: usize) -> Philosopher {
        Philosopher {
            name: name.to_string(),
            left: left,
            right: right,
        }
    }


    fn eat(&self, table: &Table) {
        let _left = table.forks[self.left].lock().unwrap();
        println!("{} take left fork.", self.name);
        thread::sleep(Duration::from_secs(2));
        let _right = table.forks[self.right].lock().unwrap();
        println!("{} take right fork.", self.name);
        thread::sleep(Duration::from_secs(1));
        println!("{} is done eating.", self.name);
    }
}

struct Table {
    forks: Vec<Mutex<()>>,
}

fn main() {
    let table = Arc::new(Table { forks: vec![
        Mutex::new(()),
        Mutex::new(()),
        Mutex::new(()),
        Mutex::new(()),
        Mutex::new(()),
    ]});

    let philosophers = vec![
        Philosopher::new("Judith Butler", 0, 1),
        Philosopher::new("Gilles Deleuze", 1, 2),
        Philosopher::new("Karl Marx", 2, 3),
        Philosopher::new("Emma Goldman", 3, 4),
        Philosopher::new("Michel Foucault", 4, 0),
    ];

    let handles: Vec<_> = philosophers.into_iter().map(|p| {
        let table = table.clone();

        thread::spawn(move || {
            p.eat(&table);
        })
    }).collect();
    for h in handles {
        h.join().unwrap();
    }
}

编译执行，我们可以发现，5 个哲学家都拿到了他左边的那支筷子，而都在等待他右边的那支筷子。在没等到右边筷子的时候，每个人都不会释放自己已经拿到的那支筷子。于是，大家都进入了无限的等待之中，程序无法继续执行了。这就是“死锁”。

在 Rust 中，“死锁”问题是没有办法在编译阶段由静态检查来解决的。就像前面提到的“循环引用制造内存泄漏”一样，编译器无法通过静态检查来完全避免这个问题，需要程序员自己注意。

29.5 死锁 ​

29.5 死锁