java 锁种类线程锁,Java多线程系列(四)：4种常用Java线程锁的特点，性能对照、使用场景...

╰+哭是因爲堅強的太久メ 2023-01-15 15:20 1阅读 0赞

![c253a82f591b4ca56ab76b70f1ad020a.png][]

多线程的缘由

在泛起了历程之后，操作系统的性能得到了大大的提升。虽然历程的泛起解决了操作系统的并发问题，然则人们仍然不知足，人们逐渐对实时性有了要求。

使用多线程的理由之一是和历程相比，它是一种异常花销小，切换快，更”节俭”的多义务操作方式。

在Linux系统下，启动一个新的历程必须分配给它自力的地址空间，确立众多的数据表来维护它的代码段、客栈段和数据段，这是一种”昂贵”的多义务事情方式。而在历程中的同时运行多个线程，它们相互之间使用相同的地址空间，共享大部分数据，启动一个线程所破费的空间远远小于启动一个历程所破费的空间，而且，线程间相互切换所需的时间也远远小于历程间切换所需要的时间。

多线程并发面临的问题

![654e1270ab2fb6ef3ecf7359a644dd45.png][]

由于多个线程是配合占有所属历程的资源和地址空间的，那么就会存在一个问题：

若是多个线程要同时接见某个资源，怎么处置？

在Java并发编程中，经常遇到多个线程接见同一个 共享资源 ，这时刻作为开发者必须思量若何维护数据一致性，这就是Java锁机制(同步问题)的泉源。

Java提供了多种多线程锁机制的实现方式，常见的有：

synchronized

ReentrantLock

AtomicInteger等

每种机制都有优瑕玷与各自的适用场景，必须熟练掌握他们的特点才能在Java多线程应用开发时轻车熟路。

4种Java线程锁(线程同步)

![15874342dbe083727cd8db231ab73405.png][]

1.synchronized

在Java中synchronized关键字被常用于维护数据一致性。

synchronized机制是给共享资源上锁，只有拿到锁的线程才可以接见共享资源，这样就可以强制使得对共享资源的接见都是顺序的。

Java开发人员都熟悉synchronized，使用它来实现多线程的同步操作是异常简朴的，只要在需要同步的对方的方式、类或代码块中加入该关键字，它能够保证在同一个时刻最多只有一个线程执行同一个工具的同步代码，可保证修饰的代码在执行过程中不会被其他线程滋扰。使用synchronized修饰的代码具有原子性和可见性，在需要历程同步的程序中使用的频率异常高，可以知足一样平常的历程同步要求。

synchronized(obj) \{

//方式

…….

synchronized实现的机理依赖于软件层面上的JVM，因此其性能会随着Java版本的不停升级而提高。

到了Java1.6，synchronized举行了许多的优化，有顺应自旋、锁消除、锁粗化、轻量级锁及偏向锁等，效率有了本质上的提高。在之后推出的Java1.7与1.8中，均对该关键字的实现机理做了优化。

需要说明的是，当线程通过synchronized守候锁时是不能被Thread.interrupt()中止的，因此程序设计时必须检查确保合理，否则可能会造成线程死锁的尴尬田地。

最后，只管Java实现的锁机制有许多种，而且有些锁机制性能也比synchronized高，但照样强烈推荐在多线程应用程序中使用该关键字，由于实现利便，后续事情由JVM来完成，可靠性高。只有在确定锁机制是当前多线程程序的性能瓶颈时，才思量使用其他机制，如ReentrantLock等。

2.ReentrantLock

可重入锁，顾名思义，这个锁可以被线程多次重复进入举行获取操作。

ReentantLock继续接口Lock并实现了接口中界说的方式，除了能完成synchronized所能完成的所有事情外，还提供了诸如可响应中止锁、可轮询锁请求、准时锁等制止多线程死锁的方式。

Lock实现的机理依赖于特殊的CPU指定，可以以为不受JVM的约束，并可以通过其他语言平台来完成底层的实现。在并发量较小的多线程应用程序中，ReentrantLock与synchronized性能相差无几，但在高并发量的条件下，synchronized性能会迅速下降几十倍，而ReentrantLock的性能却能依然维持一个水准。

因此我们建议在高并发量情形下使用ReentrantLock。

ReentrantLock引入两个观点：公正锁与非公正锁。

公正锁指的是锁的分配机制是公正的，通常先对锁提出获取请求的线程会先被分配到锁。反之，JVM按随机、就近原则分配锁的机制则称为不公正锁。

ReentrantLock在组织函数中提供了是否公正锁的初始化方式，默以为非公正锁。这是由于，非公正锁现实执行的效率要远远超出公正锁，除非程序有特殊需要，否则最常用非公正锁的分配机制。

ReentrantLock通过方式lock()与unlock()来举行加锁与解锁操作，与synchronized会被JVM自动解锁机制差别，ReentrantLock加锁后需要手动举行解锁。为了制止程序泛起异常而无法正常解锁的情形，使用ReentrantLock必须在finally控制块中举行解锁操作。通常使用方式如下所示：

Lock lock = new ReentrantLock();

try \{

lock.lock();

//…举行义务操作5 \}

finally \{

lock.unlock();

3.Semaphore

上述两种锁机制类型都是“互斥锁”，学过操作系统的都知道，互斥是历程同步关系的一种特殊情形，相当于只存在一个临界资源，因此同时最多只能给一个线程提供服务。然则，在现实庞大的多线程应用程序中，可能存在多个临界资源，这时刻我们可以借助Semaphore信号量来完成多个临界资源的接见。

Semaphore基本能完成ReentrantLock的所有事情，使用方式也与之类似，通过acquire()与release()方式来获得和释放临界资源。

经实测，Semaphone.acquire()方式默以为可响应中止锁，与ReentrantLock.lockInterruptibly()作用效果一致，也就是说在守候临界资源的过程中可以被Thread.interrupt()方式中止。

此外，Semaphore也实现了可轮询的锁请求与准时锁的功效，除了方式名tryAcquire与tryLock差别，其使用方式与ReentrantLock险些一致。Semaphore也提供了公正与非公正锁的机制，也可在组织函数中举行设定。

Semaphore的锁释放操作也由手动举行，因此与ReentrantLock一样，为制止线程因抛出异常而无法正常释放锁的情形发生，释放锁的操作也必须在finally代码块中完成。

4.AtomicInteger

首先说明，此处AtomicInteger是一系列相同类的代表之一，常见的另有AtomicLong、AtomicLong等，他们的实现原理相同，区别在与运算工具类型的差别。

我们知道，在多线程程序中，诸如++i

或

i++等运算不具有原子性，是不安全的线程操作之一。通常我们会使用synchronized将该操作酿成一个原子操作，但JVM为此类操作特意提供了一些同步类，使得使用更利便，且使程序运行效率变得更高。通过相关资料显示，通常AtomicInteger的性能是ReentantLock的好几倍。

Java线程锁总结

1.synchronized：

在资源竞争不是很猛烈的情形下，偶然会有同步的情形下，synchronized是很合适的。缘故原由在于，编译程序通常会尽可能的举行优化synchronize，另外可读性异常好。

2.ReentrantLock:

在资源竞争不猛烈的情形下，性能稍微比synchronized差点点。然则当同步异常猛烈的时刻，synchronized的性能一下子能下降好几十倍，而ReentrantLock确还能维持常态。

高并发量情形下使用ReentrantLock。

3.Atomic:

和上面的类似，不猛烈情形下，性能比synchronized略逊，而猛烈的时刻，也能维持常态。猛烈的时刻，Atomic的性能会优于ReentrantLock一倍左右。然则其有一个瑕玷，就是只能同步一个值，一段代码中只能泛起一个Atomic的变量，多于一个同步无效。由于他不能在多个Atomic之间同步。

以是，我们写同步的时刻，优先思量synchronized，若是有特殊需要，再进一步优化。ReentrantLock和Atomic若是用的欠好，不仅不能提高性能，还可能带来灾难。

以上就是Java线程锁的详解，除了从编程的角度应对高并发，更多还需要从架构设计的层面来应对高并发场景，例如：Redis缓存、CDN、异步新闻等，详细的内容如下。

更多高并发架构设计|以及最全架构师130题|以及优知学院最全架构师技术高清图

![bd3e37c395e36bc6d2821bb4e9858c59.png][]

所有以上资料获取方式

关注优知学院微信民众号，回复关键词 【架构师】即可获取以上所有架构师资料。

你可能也喜欢:

没钱没人脉也能轻松入门，让你每年多赚10万！

![0df217930a3a2e1c5a383e415c035bfa.png][]

原文链接：https://www.cnblogs.com/liuyongzhi/p/12848490.html

本站声明:网站内容泉源于网络,若有侵权,请联系我们,我们将及时处置。

[c253a82f591b4ca56ab76b70f1ad020a.png]: /images/20221022/8fe859878c4947f08e33341186679061.png
[654e1270ab2fb6ef3ecf7359a644dd45.png]: /images/20221022/14fff30b670343099973a872d26b8580.png
[15874342dbe083727cd8db231ab73405.png]: /images/20221022/51b0de0732b14a728b82bd00fce00ace.png
[bd3e37c395e36bc6d2821bb4e9858c59.png]: /images/20221022/38fab819d7c34d6cb7e9f1f23676cab4.png
[0df217930a3a2e1c5a383e415c035bfa.png]: /images/20221022/7a0fdf5dfb6a4905af4cd5cff80e0420.png