多线程、线程锁的一些我们会忽略的特性（二）

最新推荐文章于 2022-10-10 16:58:33 发布

小鹏头

最新推荐文章于 2022-10-10 16:58:33 发布

阅读量141

点赞数

分类专栏：常用类文章标签：同步锁 reentrantLock synchronized 多线程

本文链接：https://blog.csdn.net/q876651731/article/details/88788889

版权

常用类专栏收录该内容

3 篇文章 0 订阅

订阅专栏

上篇博客介绍了多线程编程会出现的的一些问题，和解决的思路，这篇文章我们继续来探讨。

文章目录

解决多卖出一张票的问题
同步代码块实现线程同步
- 同步代码块的原理
同步方法实现线程同步
同步锁实现线程同步
应该用哪一种同步方式比较好呢？
应该用什么对象作为锁对象呢？

解决多卖出一张票的问题

上篇博客中的多卖出一张票的原因，就是线程不同步，各干各的。要解决的办法就是一个线程访问共享资源的时候，不允许其他线程来访问，这也就是线程同步思想，java有3个工具可以实现线程同步：

同步代码块
同步方法
同步锁

我们一个一个来。

同步代码块实现线程同步

格式：synchronized(要共享的资源){ 需要线程同步的代码块; }
格式很简单，我们来看看代码：

public class SellingTicket implements Runnable {
    private int count = 5;

    @Override
    public void run() {
        String name = Thread.currentThread().getName();
        while (true) {
            synchronized (this) {
                /* 需要线程同步的代码块开始.... */
                if (count > 0) {
                    try {
                        Thread.sleep(((int) (Math.random() * 10 + 10)));  //睡10~20毫秒模拟售票耗时
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                    count--;
                    System.out.println(name + "卖出了一张票，" +
                            "目前还有票" + count + "张");
                } else {
                    System.out.println(name + "发现票卖完了！下班！");
                    break;
                }
                /* 同步代码块结束.... */
            }
        }
    }
}

运行结果：
售票员B卖出了一张票，目前还有票4张
售票员B卖出了一张票，目前还有票3张
售票员B卖出了一张票，目前还有票2张
售票员B卖出了一张票，目前还有票1张
售票员B卖出了一张票，目前还有票0张
售票员B发现票卖完了！下班！
售票员A发现票卖完了！下班！

可以看到，再也不会出现负数的总票数了。

同步代码块的原理

当线程执行到 synchronized(this)这行代码，线程就会拿起this这个对象，这个动作叫获取锁，而被小括号括住的对象，就被称为锁对象，只有持有锁对象的线程，才有资格进入synchronized(锁对象){}大括号中，去执行代码。

而同一个锁对象只能被获取一次，所以当一个线程拿起了this这个锁对象以后，后面到的线程就莫得锁对象拿了，进不去大括号，只好在大括号外面等着。这个状态叫做阻塞。

只有前一个获取了锁的线程走完synchronized(){}大括号中的代码，他才会放开锁对象，这个动作被称为释放锁。被释放的锁会马上回到synchronized(){}中，这样在大括号外面等着的线程才又有机会去抢这个锁，只有成功获取锁（也就是抢到锁）的线程才能进入大括号去。

于是，被共享的资源：count（剩余票的数量）就一次只能被一个售票员（线程）来访问和改变了。就像发生了以下情景：

售票员A进入了放票箱的房间，还把门把手拿走了（获取锁）。
售票员A看到票箱里只剩1张电影票，卖！票数-1。
售票员B也想进去卖票，但是售票员A把门把手拿走了（锁被占有了），门进不去，只好一直在外面等着（阻塞）。
等售票员A卖完票，售票员A才出门（执行完同步代码块），并把门把手释放回去（释放锁），因为while(true)的存在，又马上回去跟售票员B抢门把手了。
目前所有售票员抢到把手的几率的一样的，售票员B幸运地拿到门把手(获取锁)，进门。发现票已经是0了。于是执行break;，下班，离开房间（执行完同步代码块）之前归还了门把所(释放锁)。
售票员A在售票员B下班以后，也拿到门把手（获取锁），进门，看到票数为0。执行break;，离开房间（执行完同步代码块）前把门把手放回去。

有的同学会把if(count > 0){}这个判断条件放在同步代码块之前，认为检查这个动作跟卖票这个动作不必同步。这就造成售票员A卖票的时候，售票员B已经进来看到票箱里还有一张票了。只是售票员卖票的座位不让售票员B靠近而已。最后还是会造成-1张票的问题。

我们如果不能确定某个动作是否需要同步的时候，只要把线程想象成工作的人，把共享变量想象成他们需要操作的资源，在脑海里把不同步的情景模拟一下，看看会出现什么问题。一般就能得出正确答案。

同步方法实现线程同步

格式：方法修饰符 synchronized 方法返回类型方法名(参数列表){}
如：public synchronized void sellTicket(){}
这个方法跟同步代码块方法不同之处就在于：

这个方法把同步代码块都装到一个方法里了
如果是实例方法，那么synchronized()的参数就是对象的引用，也就是:synchronized(this)
如果是静态方法，那么synchronized()的参数就是类的类型信息，也就是synchronized(SellingTicket.class)

关于这不同参数会造成什么不同，我们后面探讨，现在我们只需要知道上述3点。上代码：

public class SellingTicket_2 implements Runnable {
    private int count = 5;

    @Override
    public void run() {
        while (count > 0) { //只有票数大于0才要卖票
            sellTicket();   //没抢到锁的线程，都只能在这里阻塞。
        }
    }

    private synchronized void sellTicket() {
        if (count > 0) {    //进来以后的线程，还得再判断一次。
            try {
                Thread.sleep(200);
                count--;
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println(Thread.currentThread().getName() + "卖出了一张票，目前还剩" + count + "张");
        }
    }
}

运行结果：
售票员B卖出了一张票，目前还剩4张
售票员B卖出了一张票，目前还剩3张
售票员B卖出了一张票，目前还剩2张
售票员B卖出了一张票，目前还剩1张
售票员A卖出了一张票，目前还剩0张

其中有一个比较关键的点，就是同步方法里面还需要再判断一次票数>0，这是因为有可能线程A在卖最后一张票，但还没卖完之前，线程B就走到了while(count>0)的判断语句，这里是没有阻塞的，线程B会进来while()语句，如果不在同步方法中再判断一次，线程B就会在阻塞结束以后，直接卖票，又会出现总票数为-1的问题了。

同步锁实现线程同步

同步锁有好几种，我们比较常用的一般是ReentrantLock，叫可重入锁，可重入的意思就是一个线程可以多次获得同一把锁，每次有线程获得这把锁，reentrantLock对象的lock值就+1，每次拿到锁的对象调用unlock，lock数就-1，当lock数=0，才能让其他线程进入。
上代码：

public class SellingTicket_3 implements Runnable{
    private int count=5;
    private Lock lock = new ReentrantLock();
    @Override
    public void run() {
        while (true) {
            lock.lock();
            try {
                if (count > 0) {
                    Thread.sleep(1000);
                    count--;
                    System.out.println(Thread.currentThread().getName()+"卖出了1张票，现在还有票"+count+"张");
                }else {
                    System.out.println(Thread.currentThread().getName() + "发现票卖光啦，下班！");
                    break;      
                }
            } catch (InterruptedException e) {
                e.printStackTrace();
            } finally {
                lock.unlock();
            }
        }
    }
}

运行结果：
售票员A卖出了1张票，现在还有票4张
售票员A卖出了1张票，现在还有票3张
售票员A卖出了1张票，现在还有票2张
售票员A卖出了1张票，现在还有票1张
售票员A卖出了1张票，现在还有票0张
售票员A发现票卖光啦，下班！
售票员B发现票卖光啦，下班！

运行结果正常，但是为什么lock.unlock()要放到finally{}中执行呢？

这是因为如果票数为0，线程就会执行else{}中的语句，也就是break;跳出循环，在break后面的lock.unlock()就没办法执行了，lock对象的最后一个锁就解不开了。所以我们应该lock.unlock()放在finally{}中，即使执行的是break;，也会执行lock.unlock()。

应该用哪一种同步方式比较好呢？

synchronized(){}同步代码块和同步方法并没有本质上的区别，只是写代码的方式有点不一样而已。

reentrantLock与synchronized的区别如下：

reentrantLock要考虑抛出异常或者break会导致没有unlock()所以要把unlock()放到finally{}中。而synchronized无论什么原因退出代码块，系统都会自动释放锁。因此在代码上，reentrantLock会没那么美观。
synchronized在资源竞争不激烈的情况下，也就是CPU占用率并不高的情况下，表现会很好，效率比reentrantLock高很多。但是如果资源竞争激烈，synchronized的效率就会几十倍的下降。而reentrantLock的效率会维持比较稳定的水平。这时reentrantLock效率就比synchronized好