Java并发编程之Lock(同步锁、死锁)

这篇文章是接着我上一篇文章来的。

上一篇文章

同步锁

为什么需要同步锁？

首先，我们来看看这张图。

这是一个程序，多个对象进行抢票。

package MovieDemo;

public class ThM implements Runnable {
    private int count = 10;
    private int num = 0;
    @Override
    public void run() {
        while (true) {
                if (count <= 0) {
                    break;
                }
                num++;
                count--;
                try {
                    Thread.sleep(100);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                System.out.println(Thread.currentThread().getName() + "抢到了第" + num + "个票"+"剩余票数："+count);
        }
    }
}

线程类中代码很简单，就是当对象抢到票，count就会记录，每被抢一张就少一张。

当我们只有一个对象时，我们这个程序时正常的，但是当我们多个对象一起抢票时。因为线程是同时的，就像挤公交，多个人一起挤进去。

所以这里会出现多个人抢了同一张票的问题。

所以，当我们多个对象存在时，代码是这样运行的：

1. 首先，多个线程的对象并发，也就是同时去抢票。
2. 抢票的时候，多个对象都同时都抢到了票。
3. 系统将会认为，这些对象都抢到了票，但是票只有一张，此时系统就出现错误了。
4. 此时的关系就是几个人共享一张票。

那再现实生活中，肯定不能这样，我们需要排队，肯定只能一个人对应一张票。

package MovieDemo;

public class Test {
    public static void main(String[] args) {
        ThM m = new ThM();
        Thread t = new Thread(m);
        Thread t1 = new Thread(m);
        Thread t2 = new Thread(m);
        t1.start();
        t2.start();
        t.start();
    }
}

这里有三个线程对象！

我们运行程序看看结果。

Thread-0抢到了第3个票剩余票数：7
Thread-1抢到了第3个票剩余票数：7
Thread-2抢到了第3个票剩余票数：7

Thread-0抢到了第6个票剩余票数：4
Thread-2抢到了第6个票剩余票数：4
Thread-1抢到了第6个票剩余票数：4

Thread-1抢到了第9个票剩余票数：1
Thread-0抢到了第9个票剩余票数：1
Thread-2抢到了第9个票剩余票数：1

Thread-1抢到了第10个票剩余票数：0

很明显看出来，这个程序就不对劲，0、1、2这三个人都抢到了同一张票。

那我们如何解决这种问题呢？

同步锁的使用

我们举个例子，一个公共厕所，一张门，你和一堆人都想进去上厕所，你此时进去了，但是其他人也要进来，你该怎么办？

此时，你明智的将厕所的门拉上（锁上），等你上完厕所，再开锁，下一位继续如此。

**synchronize(Object)**就是我们所说的这把锁。

Object是对象。

我们先看看这个“锁”的作用：

1.每个对象都有一个与它相关的内部锁（intrinsic lock）或者叫监视器锁（monitor lock） 2.第一个执行到同步语句的线程可以获得 obj 的内部锁，在执行完同步语句中的代码后释放此锁 3.只要一个线程持有了内部锁，那么其它线程在同一时刻将无法再获得此锁，当它们试图获取此锁时，将会进入BLOCKED状态 4.多个线程访问同一个 synchronized(Object)语句时，Object必须是同一个对象，才能起到同步的作用。

锁方法

同步锁用法很多，锁方法我们可以这样：

实例方法：synchronized (this) 静态方法：synchronized (Class对象)

注意的是，synchronized不能修饰构造方法！！！

锁语句

但是我们一般不喜欢直接锁住方法，就像，你有一个宝箱，你只需要锁住箱子，没必要将箱子所在的房子锁上。

同步语句比同步方法更灵活一点 同步语句可以精确控制需要加锁的代码范围，减少处于BLOCKED状态的线程,充分利用劳动力

实际操作

还是上面那个方法，我给它运行的部分加上锁！

package MovieDemo;

public class ThM implements Runnable {
    private int count = 10;
    private int num = 0;
    @Override
    public void run() {
        while (true) {
            synchronized (this) {
                if (count <= 0) {
                    break;
                }
                num++;
                count--;
                try {
                    Thread.sleep(100);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                System.out.println(Thread.currentThread().getName() + "抢到了第" + num + "个票"+"剩余票数："+count);
            }
        }
    }
}

实际上我锁住的是这一部分。

synchronized (this) {
    if (count <= 0) {
        break;
    }
    num++;
    count--;
    try {
        Thread.sleep(100);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    System.out.println(Thread.currentThread().getName() + "抢到了第" + num + "个票"+"剩余票数："+count);
}

this关键词指代当前线程的对象！

我们运行一下，看看还会不会出现之前的状况。

可能第二个对象运气好哈，就第一张票不是对象2抢到的。

但是，现在就是完全不会出现两个人抢到同一张票的故障了。

特别注意

运行类代码现在我改一下。

package MovieDemo;

public class Test {
    public static void main(String[] args) {
        ThM t = new ThM();
        ThM t1 = new ThM();
        ThM t2 = new ThM();
        t.start();
        t2.start();
        t1.start();
    }
}

此时我运行一下，会发生先去的故障。

因为此时，你的锁，锁的不是同一个对象。

而之前。

ThM m = new ThM();
Thread t = new Thread(m);
Thread t1 = new Thread(m);
Thread t2 = new Thread(m);

虽然是三个线程对象，但是他们new的对象都是m，也就是ThM类的对象，是同一个！

线程同步的优缺

使用了线程同步技术后：

1. 虽然解决了线程安全问题，但是降低了程序的执行效率。
2. 因为加了锁就会有处于等待的线程，多了加锁解锁的操作。
3. 所以在真正有必要的时候，才使用线程同步技术。

死锁

什么是死锁：

两个或者多个线程永远阻塞，相互等待对方的锁

是并发下一组互相竞争资源的线程因互相等待导致永久阻塞的现象

CSDN上面一个大佬的举例就很好理解：

线程a占用对象锁1，线程b占用对象锁2

线程a需要继续占用对象锁2才能往下执行，所以线程a需要等待线程b释放对象锁2

线程b需要继续占用对象锁1才能往下执行，同样也需要线程a释放对象锁1

由于这2个线程都不释放自己已经占用的锁，所以这2个线程会处于无限等待状态

我说得比较通俗，就是，挤公交车，两个人互挤，但是谁也上不去！

这是那位博主的举例，很有意思哈。

为何会产生死锁？

1. 互斥
2. 占有且等待
3. 不可抢占
4. 循环等待

怎么说呢？

• 互斥——>共享资源只能被一个线程占用，比如一个座位，只能容纳一个人，两个人都想做，谁也不让谁，那就都坐不了！

• 占有且等待——>假设你此时有一个玩具，别的小朋友哪儿也有一个玩具，你想要两个玩具，你就拿着自己玩具不放手，然后等另一个小朋友不玩了，你就获得了两个玩具。

• 不可抢占——>资源只能由持有它的线程自愿释放，其它线程不可强行占有该资源-无法释放对方资源。说白了，你不能抢别人的东西，(除非别人让你抢)。

• 循环等待——>这个就拿上面的玩具解释，假设你此时有一个玩具，别的小朋友哪儿也有一个玩具，你想要两个玩具，你就拿着自己玩具不放手，然后等另一个不玩了再去拿，但是另一个小朋友也是一样，等你不玩了再去拿。此时就僵持了。

如何解决锁死的情况

首先！不能强制！不能直接去去掉死锁，这样不能保证线程安全。 那怎么办？找原因！解铃还须系铃人。也就是说，我们要打破上面4种原因中的任意一种。

大佬博客说的很好，我就直接搬过来了！

大佬博客在这

线程8锁

• 一个对象里面如果有多个synchronized方法，某一个时刻内，只要一个线程去调用其中的一个synchronized方法了，其它的线程都只能等待，换句话说，某一个时刻内，只能有唯一一个线程去访问这些synchronized方法

• 锁的是当前对象this，被锁定后，其它的线程都不能进入到当前对象的其它的synchronized方法

• 加个普通方法后发现和同步锁无关

• 换成两个对象后，不是同一把锁了，情况立刻变化。

• 都换成静态同步方法后，情况又变化

• 所有的非静态同步方法用的都是同一把锁——实例对象本身，也就是说如果一个实例对象的非静态同步方法获取锁后，该实例对象的其他非静态同步方法必须等待获取锁的方法释放锁后才能获取锁，可是别的实例对象的非静态同步方法因为跟该实例对象的非静态同步方法用的是不同的锁，所以毋须等待该实例对象已获取锁的非静态同步方法释放锁就可以获取他们自己的锁。

• 所有的静态同步方法用的也是同一把锁——类对象本身，这两把锁是两个不同的对象，所以静态同步方法与非静态同步方法之间是不会有竞态条件的。但是一旦一个静态同步方法获取锁后，其他的静态同步方法都必须等待该方法释放锁后才能获取锁，而不管是同一个实例对象的静态同步方法之间，还是不同的实例对象的静态同步方法之间，只要它们同一个类的实例对象，都得这样！！！

线程8锁可以说是个概念！

我们记住以下两点：

① 非静态方法的默认锁是this ，静态方法的默认锁是class

②某一时刻内，只能有一个线程有锁，无论几个方法