Java 多线程之锁优化与 JUC 常用类
🍀1.synchronized 的优化手段
🍂1.1 锁膨胀/升级
前面我们说过 synchronized 关键字加的锁既是轻量级锁也是重量级锁,它是根据实际情况自适应加锁的,这种自适应是基于锁膨胀或者说是锁升级这样的优化手段来实现的。
🌸锁升级过程:
当没有线程加锁的时候,此时为无锁状态。
当首个线程进行加锁的时候,此时进入偏向锁的状态,偏向锁不是真的加锁,而是在对象头做个标记而已,
当有其他线程进行加锁,导致产生了锁竞争时,此时进入轻量级锁状态。
如果竞争进一步加剧,进入重量级锁状态。
像上面根据锁竞争的程度来逐步升级锁的情况,就是锁的膨胀或者称为锁的升级。
🍂1.2 锁粗化
所谓锁粗化就是将synchronized
的加锁代码块范围增大,加锁的代码块中的内容越多,锁就越粗,否则锁就越细。一般我们认为,锁越细,多线程间的并发性越高,锁越粗,加锁解锁的开销就会更小。编译器会对你加的锁做一个优化,如果编译器判定加的锁过细,就会自动粗化,从而提高程序运行效率。
🍂1.3 锁消除
有些代码,编译器认为没有加锁的必要,就会自动把你加的锁自动去除,像类似这样的优化,就是锁消除。
🍀2.java 中的 JUC
java 中的 JUC 就是来自java.util.concurrent
包下的一些标准类或者接口,都是有关并发或者有关多线程的一些类和接口。
🍂2.1Callable 接口
前面我们创建线程的时候,有两种方式,一是继承Thred
类并重写run
方法来创建线程,二是通过Runnable
接口来创建线程,除上述两种方式,我们还可以通过Callable
接口配合FutureTask
类来创建线程,使用该方法创建线程能够支持带返回值的任务,而最开始的那两种方法是不支持带回返回值的。
其中通过实现Callable
接口的call
方法来描述带有返回值的任务,FutureTask
就是对于具体的Runnable
或者Callable
任务的执行结果进行取消、查询是否完成、获取返回值。必要时可以通过get
方法获取执行结果(返回值),如果任务还没有执行完毕,该方法会阻塞直到任务返回结果。
在创建线程的时候,传入的引用不能是Callable
类型,而应该是FutrueTask
类型,根据Thread
的构造方法,传入的任务类型需是Runnable
类,Callable
与Runnable
没有关系,而FutrueTask
类实现了Runnable
类,所以在此之前我们需要把实现Callable
接口的对象引用传给FutrueTask
类的实例对象。
综上,Callable
用来描述任务,FutureTask
类用来管理Callable
任务的执行结果。
比如,现在我们需要使用线程来计算一个值,并通过返回值的方式获取执行结果。
🌸参考代码:
🌸运行结果:
🍂2.2ReentrantLock 类(可重入锁)
ReentrantLock
其实就是可重入锁,使用方式是通过lock
方法加锁,unlock
方法解锁,注意加锁和解锁两个过程是分开的,而synchronized
关键字加锁解锁是一步到位的。
由于加锁解锁两个操作是分开的,相比于加锁解锁一体化这就很容易造成死锁问题,这是因为一方面加锁后容易忘记去解锁,造成死锁,另一方面加锁后解锁前中间的代码万一出了问题,可能会导致解锁无法正常执行导致解锁失败,造成死锁。所以使用ReentrantLock
类时,一般要搭配finally
使用。
🌸ReentrantLock
类与synchronized
关键字区别:
ReentrantLock
是一个 java 标准类,是使用 java 代码实现的,synchronized
是一个关键字,是基于 JVM 内部实现的,是 C/C++代码。ReentrantLock
需要手动解锁,需谨防忘记解锁,而synchronized
加锁解锁一体化,不需要手动解锁。如果出现锁竞争,
ReentrantLock
竞争失败时可以阻塞等待,也可以通过 trylock 方法直接返回退出,而synchronized
竞争失败时只能阻塞等待。ReentrantLock
构造实例对象时,可以指定 fair 参数来决定该锁对象是公平锁还非公平锁,synchronized
加的锁是非公平锁,不能指定为公平锁。ReentrantLock
类衍生出的等待机制是Condition
类,synchronized
关键字衍生的等待机制是wait/notify
等待机制。
🍂2.3Semaphore 类(信号量)
这个概念比较抽象,我们来打个比方,有个停车场,停车场门口有一个灯牌,会显示停车位还剩余多少个,每进去一辆车,显示的停车位数量就减一,每出去一辆出,显示的停车位数量就加一。
上面显示停车位数量的灯牌其实就是信号量,信号量是一更加广义的锁,描述了可用资源的个数。每次申请一个可用资源,信号量中的计数器就减一(P 操作)。每次释放一个可用资源,信号量中的计数器就加一(V 操作)。当可用资源数量为 0 时,再次进行 P 操作,会陷入阻塞等待状态。
锁我们可以理解为“二元信号量”,因为计数器的取值不是 0 就是 1,它的可用资源就一个。
🌸Semaphore 类的常用方法:
🌸代码演示:
🌸执行结果:
🍂2.4CountDownLatch 同步工具类
CountDownLatch 是一个同步工具类,它允许一个或多个线程一直等待,直到其他线程执行完后再执行。打个比方,假设有一场跑步比赛,一个有 5 个远动员参赛,只有当最后一个远动员冲过终点线时,裁判才能宣布比赛结束。
这里的运动员就相当于线程,裁判就相当于CountDownLatch
类。
🌸CountDownLatch 同步工具类常用方法:
🌸使用方式:
创建
CountDownLatch
对象,并初始化计数器的值。在每个线程执行的最后使用
countDown
方法,表示当前线程执行完毕,计数器的值减 1。在主线程中使用
await
方法,等待CountDownLatch
对象的计数器清零,表示所管理的线程全部执行完毕,起到线程同步的作用。
🌸参考代码:
这样的场景在实际开发当中,也是很常见的,比如要下载一个较大的文件的时候,常常将文件拆分,使用多线程并发下载。
而在这样一个场景中,需要等待最后一个线程也下载完毕,才能说整个文件下载完毕,也就是使用 CountDownLatch 对象进行计数,等计数器清零了await
方法就会返回,表示文件下载完成。
🍂2.5 有关数据结构的线程安全类
🍁2.5.1 多线程使用顺序表
ArrayList 在多线程中是线程不安全的,多线程环境中使用基于写实拷贝实现的 CopyOnWriteArrayList。
所谓写实拷贝,就是写的时候会创建一个副本,再副本上进行修改,同时如果存在读操作会在原文件数进行查询,等修改完毕后就会将副本“转正”。
🍁2.5.2 多线程使用队列
🌸多线程情况下常常使用阻塞队列:
ArrayBlockingQueue 基于数组实现的阻塞队列
LinkedBlockingQueue 基于链表实现的阻塞队列
PriorityBlockingQueue 基于堆实现的带优先级的阻塞队列
TransferQueue 最多只包含一个元素的阻塞队列
🍁2.5.3 多线程使用哈希表
HashMap 本身是线程不安全的,将 HashMap 中的重要方法使用synchornized
加锁后,就得到了 HashTable 类,虽然 HashTable 类是线程安全的,但是由于是对方法进行无脑加锁,本质加锁的对象是 HashTable 类的实例对象,这样就会导致锁竞争概率加大,就相当于公司里所有的员工需要请假时都需要找老板签字批准,这样会导致老板非常地忙,这个老板就相当于加锁的哈希表对象,最终会造成哈希表的效率下降。
为了解决这个问题,java 提供了 ConcurrentHashMap 类,该类是基于哈希表中的每一个链表对象进行加锁,线程需要对哪个链表对象进行操作,就在哪里加锁,由于哈希表中链表数量很多,链表对象的元素个数较少,可以有效地降低锁竞争的概率,相当于公司中的老板将权力下放给各个部门,员工请假时只需向所在的部门领导请假即可。
到这里,Java 多线程有关内容基本上都介绍完毕了,不知道小伙伴们学会了多少呢?
下期预告:Java 文件 IO
版权声明: 本文为 InfoQ 作者【未见花闻】的原创文章。
原文链接:【http://xie.infoq.cn/article/d1287712d74f8f3fae27340b3】。文章转载请联系作者。
评论