Fork me on GitHub

Java并发(3)-线程安全

此处输入图片的描述
volatile, synchronized, Lock? 详解Java的线程安全与锁!

一、内存模型

高速缓存

因为CPU执行速度和内存数据读写速度差距很大,因此CPU往往包含高速缓存结构。
此处输入图片的描述
当程序在运行过程中,会将运算需要的数据从主存复制一份到CPU的高速缓存当中,那么CPU进行计算时就可以直接从它的高速缓存读取数据和向其中写入数据,当运算结束之后,再将高速缓存中的数据刷新到主存当中。

缓存不一致问题

执行下面的代码:

1
2
int i = 0;
i = i + 1;

当线程执行这个语句时,会先从主存当中读取i的值i = 0,然后复制一份到高速缓存当中,然后CPU执行指令对i进行加1操作,然后将数据写入高速缓存,最后将高速缓存中i最新的值刷新到主存当中。

可能存在情况:初始时,两个线程分别读取i的值存入各自所在的CPU的高速缓存当中,然后线程1进行加1操作,然后把i的最新值1写入到内存。此时线程2的高速缓存当中i的值还是0,进行加1操作之后,i的值为1,然后线程2把i的值写入内存。

也就是说,如果一个变量在多个CPU中都存在缓存(多线程情况),那么就可能存在缓存不一致的问题。

缓存不一致的解决

一般有两种解决办法:

  • 总线加锁

    因为CPU和其他部件进行通信都是通过总线来进行的,如果对总线加锁的话,也就是说阻塞了其他CPU对其他部件访问(如内存),从而使得只能有一个CPU能使用这个变量的内存。

  • 缓存一致性协议

    由于在锁住总线期间,其他CPU无法访问内存,导致效率低下。所以就出现了缓存一致性协议。最出名的就是Intel的MESI协议MESI协议保证了每个缓存中使用的共享变量的副本是一致的。
    MESI协议核心思想是:当CPU写数据时,如果发现操作的变量是共享变量,即在其他CPU中也存在该变量的副本,会发出信号通知其他CPU将该变量的缓存行置为无效状态,因此当其他CPU需要读取这个变量时,发现自己缓存中缓存该变量的缓存行是无效的,那么它就会从内存重新读取。

二、线程安全问题

产生原因

从前面的分析,在并发编程(多线程编程)中,可能出现线程安全的问题:

  • 多个线程在操作共享的数据。

  • 操作共享数据的线程代码有多条。

  • 当一个线程在执行操作共享数据的多条代码过程中,其他线程参与了运算。

并发的核心概念

三个核心概念:原子性、可见性、顺序性。

  • 原子性:跟数据库事务的原子性概念差不多,即一个操作(有可能包含有多个子操作)要么全部执行(生效),要么全部都不执行(都不生效)。

    锁和同步(同步方法和同步代码块)、CAS(CPU级别的CAS指令cmpxchg)。

  • 可见性:当多个线程并发访问共享变量时,一个线程对共享变量的修改,其它线程能够立即看到。

    volatile关键字来保证可见性。

JVM使用happens-before的概念来阐述多线程之间的内存可见性:

  • 程序次序规则:一个线程内,按照代码顺序,书写在前面的操作先行发生于书写在后面的操作;
  • 锁定规则:一个unLock操作先行发生于后面对同一个锁的lock操作;
  • volatile变量规则:对一个变量的写操作先行发生于后面对这个变量的读操作;
  • 传递规则:如果操作A先行发生于操作B,而操作B又先行发生于操作C,则可以得出操作A先行发生于操作C;
  • 线程启动规则:Thread对象的start()方法先行发生于此线程的每个一个动作;
  • 线程中断规则:对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生;
  • 线程终结规则:线程中所有的操作都先行发生于线程的终止检测,我们可以通过Thread.join()方法结束、Thread.isAlive()的返回值手段检测到线程已经终止执行;
  • 对象终结规则:一个对象的初始化完成先行发生于他的finalize()方法的开始;
  • 顺序性:程序执行的顺序按照代码的先后顺序执行。因为处理器为了提高程序运行效率,可能会对输入代码进行优化,它不保证程序中各个语句的执行先后顺序同代码中的顺序一致,但是它会保证程序最终执行结果和代码顺序执行的结果是一致的-即指令重排序

    volatile在一定程序上保证顺序性,另外还可以通过synchronized来保证顺序性。

三、Java对象头的结构

Java对象可以作为并发编程中的锁。而锁实际上存在于Java对象头里。如果对象是数组类型,则虚拟机用 3 个 Word(字宽)存储对象头,如果对象是非数组类型,则用 2 字宽存储对象头。在 64 位虚拟机中,一字宽等于八字节,即 64bit

Java 对象头里的 Mark Word 里默认存储对象的 HashCode,分代年龄和锁标记位。32 位 JVM 的 Mark Word 的默认存储结构如下:

- 25 bit 4bit 偏向锁标志位(1bit) 锁标志位(2bit)
无锁状态 对象的hashCode 对象分代年龄 01

64 位JVM的存储结构如下:

锁状态

25bit

31bit

1bit

4bit

1bit

2bit

cms_free

分代年龄

偏向锁

锁标志位

无锁

unused

hashCode

01

偏向锁

ThreadID(54bit) Epoch(2bit)

1

01

在运行期间 Mark Word 里存储的数据会随着锁标志位的变化而变化。


在了解了相关概念后,接下来介绍Java是如何保证并发编程中的安全的。

四、synchronized

用法

  • 修饰同步代码块

    将多条操作共享数据的线程代码封装起来,当有线程在执行这些代码的时候,其他线程时不可以参与运算的。必须要当前线程把这些代码都执行完毕后,其他线程才可以参与运算。

    1
    2
    3
    4
     synchronized(对象)
    {
    需要被同步的代码 ;
    }
  • 修饰同步函数(方法)

    1
    2
     修饰符 synchronized 返回值 方法名(){
    }
  • 修饰一个静态的方法,其作用的范围是整个静态方法,作用的对象是这个类的所有对象;

  • 修饰一个类,其作用的范围是synchronized后面括号括起来的部分,作用主的对象是这个类的所有对象。

synchronized的作用主要有三个:
(1)确保线程互斥的访问同步代码
(2)保证共享变量的修改能够及时可见
(3)有效解决重排序问题。

锁对象

  • 对于同步方法,锁是当前实例对象
  • 对于静态同步方法,锁是当前对象的 Class 对象
  • 对于同步方法块,锁是 synchonized 括号里配置的对象。

实现原理

在编译的字节码中加入了两条指令来进行代码的同步。

(1)monitorenter :

每个对象有一个监视器锁(monitor)。当monitor被占用时就会处于锁定状态,线程执行monitorenter指令时尝试获取monitor的所有权,过程如下:

  • 如果monitor的进入数为0,则该线程进入monitor,然后将进入数设置为1,该线程即为monitor的所有者。
  • 如果线程已经占有该monitor,只是重新进入,则进入monitor的进入数加1.
  • 如果其他线程已经占用了monitor,则该线程进入阻塞状态,直到monitor的进入数为0,再重新尝试获取monitor的所有权。

(2)monitorexit:

执行monitorexit的线程必须是objectref所对应的monitor的所有者。
指令执行时,monitor的进入数减1,如果减1后进入数为0,那线程退出monitor,不再是这个monitor的所有者。其他被这个monitor阻塞的线程可以尝试去获取这个 monitor的所有权。

synchronized的语义底层是通过一个monitor的对象来完成,其实wait/notify等方法也依赖于monitor对象,这就是为什么只有在同步的块或者方法中才能调用wait/notify等方法,否则会抛出java.lang.IllegalMonitorStateException的异常的原因。

好处和弊端

好处:解决了线程的安全问题。

弊端:相对降低了效率,因为同步外的线程的都会判断同步锁。获得锁和释放锁带来性能消耗。

编译器对synchronized优化

Java6 为了减少获得锁和释放锁所带来的性能消耗,引入了“偏向锁”和“轻量级锁”,所以在Java6 里锁一共有四种状态:无锁状态,偏向锁状态,轻量级锁状态和重量级锁状态,它会随着竞争情况逐渐升级。锁可以升级但不能降级。

  • 偏向锁:大多数情况下锁不仅不存在多线程竞争,而且总是由同一线程多次获得。偏向锁的目的是在某个线程获得锁之后(线程的id会记录在对象的Mark Wod中),消除这个线程锁重入(CAS)的开销,看起来让这个线程得到了偏护。

  • 轻量级锁(CAS):轻量级锁是由偏向锁升级来的,偏向锁运行在一个线程进入同步块的情况下,当第二个线程加入锁争用的时候,偏向锁就会升级为轻量级锁;轻量级锁的意图是在没有多线程竞争的情况下,通过CAS操作尝试将MarkWord更新为指向LockRecord的指针,减少了使用重量级锁的系统互斥量产生的性能消耗。

  • 重量级锁:虚拟机使用CAS操作尝试将MarkWord更新为指向LockRecord的指针,如果更新成功表示线程就拥有该对象的锁;如果失败,会检查MarkWord是否指向当前线程的栈帧,如果是,表示当前线程已经拥有这个锁;如果不是,说明这个锁被其他线程抢占,此时膨胀为重量级锁。

锁状态对应的Mark Word

以32位JVM为例:

锁状态

25 bit

4bit

1bit

2bit

23bit

2bit

是否是偏向锁

锁标志位

轻量级锁

指向栈中锁记录的指针

00

重量级锁

指向互斥量(重量级锁)的指针

10

GC标记

11

偏向锁

线程ID

Epoch

对象分代年龄

1

01

五、volatile

volatile是Java中的一个关键字,用来修饰共享变量(类的成员变量、类的静态成员变量)。

被修饰的变量包含两层语义:

  • 保证可见性

    线程写入变量时不会把变量写入缓存,而是直接把值刷新回主存。同时,其他线程在读取该共享变量的时候,会从主内存重新获取值,而不是使用当前缓存中的值。(因此会带来一部分性能损失)。注意:往主内存中写入的操作不能保证原子性。

  • 禁止指令重排

    禁止指令重排序有两层意思:
     1)当程序执行到volatile变量的读操作或者写操作时,在其前面的操作的更改肯定全部已经进行,且结果已经对后面的操作可见;在其后面的操作肯定还没有进行;
     2)在进行指令优化时,不能将在对volatile变量访问的语句放在其后面执行,也不能把volatile变量后面的语句放到其前面执行。

底层实现:观察加入volatile关键字和没有加入volatile关键字时所生成的汇编代码发现,加入volatile关键字时,会多出一个lock前缀指令

六、Lock

应用场景

如果一个代码块被synchronized修饰了,当一个线程获取了对应的锁,并执行该代码块时,其他线程便只能一直等待,等待获取锁的线程释放锁,而这里获取锁的线程释放锁只会有两种情况

  • 获取锁的线程执行完了该代码块,然后线程释放对锁的占有;
  • 线程执行发生异常,此时JVM会让线程自动释放锁。

如果这个获取锁的线程由于要等待IO或者其他原因(比如调用sleep方法)被阻塞了,但是又没有释放锁,会让程序效率很差。

因此就需要有一种机制可以不让等待的线程一直无期限地等待下去(比如只等待一定的时间或者能够响应中断),通过Lock就可以办到。

源码分析

与Lock相关的接口和类位于J.U.Cjava.util.concurrent.locks包下。
此处输入图片的描述

(1)Lock接口

1
2
3
4
5
6
7
8
public interface Lock {
void lock();
void lockInterruptibly() throws InterruptedException;
boolean tryLock();
boolean tryLock(long time, TimeUnit unit) throws InterruptedException;
void unlock();
Condition newCondition();
}
  • 获取锁
    lock():获取锁,如果锁被暂用则一直等待。
    tryLock(): 有返回值的获取锁。注意返回类型是boolean,如果获取锁的时候锁被占用就返回false,否则返回true
    tryLock(long time, TimeUnit unit):比起tryLock()就是给了一个时间期限,保证等待参数时间。
    lockInterruptibly():当通过这个方法去获取锁时,如果线程正在等待获取锁,则这个线程能够响应中断,即中断线程的等待状态。也就使说,当两个线程同时通过lock.lockInterruptibly()想获取某个锁时,假若此时线程A获取到了锁,而线程B只有在等待,那么对线程B调用threadB.interrupt()方法能够中断线程B的等待过程。

    注意:当一个线程获取了锁之后,是不会被interrupt()方法中断的。因为本身在前面的文章中讲过单独调用interrupt()方法不能中断正在运行过程中的线程,只能中断阻塞过程中的线程。因此当通过lockInterruptibly()方法获取某个锁时,如果不能获取到,只有进行等待的情况下,是可以响应中断的。用synchronized修饰的话,当一个线程处于等待某个锁的状态,是无法被中断的,只有一直等待下去。

  • 释放锁
    unlock():释放锁。

(2)ReentrantLock类

ReentrantLock,意思是“可重入锁”。ReentrantLock是唯一实现了Lock接口的类,并且ReentrantLock提供了更多的方法,基于AQS(AbstractQueuedSynchronizer)来实现的。

并且,ConcurrentHashMap并没有采用synchronized进行控制,而是使用了ReentrantLock

  • 构造方法
    ReentrantLock 分为公平锁非公平锁,可以通过构造方法来指定具体类型:
    1
    2
    3
    4
    5
    6
    public ReentrantLock() {
    sync = new NonfairSync();
    }
    public ReentrantLock(boolean fair) {
    sync = fair ? new FairSync() : new NonfairSync();
    }

以非公平锁为例:

  • 获取锁
    1
    2
    3
    public void lock() {
    sync.lock();
    }

sync是一个abstract内部类:

1
2
3
4
abstract static class Sync extends AbstractQueuedSynchronizer {
private static final long serialVersionUID = -5179523762034025860L;
abstract void lock();
}

lock()方法用的是构造得到的FairSync对象,即sync的实现类。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public ReentrantLock() {
sync = new NonfairSync();
}
//删去了一些方法
static final class NonfairSync extends Sync {
final void lock() {
if (compareAndSetState(0, 1))
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1);
}
protected final boolean tryAcquire(int acquires) {
return nonfairTryAcquire(acquires);
}
}

compareAndSetStateAQS的一个方法,也就是基于CAS操作。

1
2
3
4
5
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}

尝试进一步获取锁(调用继承自父类syncfinal方法):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
final boolean nonfairTryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
else if (current == getExclusiveOwnerThread()) {
int nextc = c + acquires;
if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
return false;
}

首先会判断 AQS 中的 state 是否等于 0,0表示目前没有其他线程获得锁,当前线程就可以尝试获取锁。如果 state 大于 0 时,说明锁已经被获取了,则需要判断获取锁的线程是否为当前线程(ReentrantLock 支持重入),是则需要将 state + 1,并将值更新。

如果 tryAcquire(arg) 获取锁失败,则需要用addWaiter(Node.EXCLUSIVE) 将当前线程写入队列中。写入之前需要将当前线程包装为一个 Node对象(addWaiter(Node.EXCLUSIVE))

即回到:

1
2
3
4
5
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}

  • 释放锁
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
公平锁和非公平锁的释放流程都是一样的:
public void unlock() {
sync.release(1);
}

public final boolean release(int arg) {
if (tryRelease(arg)) {
Node h = head;
if (h != null && h.waitStatus != 0)
//唤醒被挂起的线程
unparkSuccessor(h);
return true;
}
return false;
}

//尝试释放锁
protected final boolean tryRelease(int releases) {
int c = getState() - releases;
if (Thread.currentThread() != getExclusiveOwnerThread())
throw new IllegalMonitorStateException();
boolean free = false;
if (c == 0) {
free = true;
setExclusiveOwnerThread(null);
}
setState(c);
return free;
}

(3)ReadWriteLock接口ReentrantReadWriteLock类

  • 定义
    1
    2
    3
    4
    public interface ReadWriteLock {
    Lock readLock();
    Lock writeLock();
    }

ReentrantLock中,线程之间的同步都是互斥的,不管是读操作还是写操作,但是在一些场景中读操作是可以并行进行的,只有写操作才是互斥的,这种情况虽然也可以使用ReentrantLock来解决,但是在性能上也会损失,ReadWriteLock就是用来解决这个问题的。

  • 实现-ReentrantReadWriteLock类

ReentrantReadWriteLock中分别定义了读锁和写锁,与ReentrantLock类似,读锁和写锁的功能也是通过Sync实现的,Sync存在公平和非公平两种实现方式,不同的是表示锁状态的state的定义,在ReentrantReadWriteLock中具体定义如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
static final int SHARED_SHIFT     = 16;
static final int SHARED_UNIT = (1 << SHARED_SHIFT);
static final int MAX_COUNT = (1 << SHARED_SHIFT) - 1;
static final int EXCLUSIVE_MASK = (1 << SHARED_SHIFT) - 1;

//获取读锁的占有次数
static int sharedCount(int c) { return c >>> SHARED_SHIFT; }
//获取写锁的占有次数
static int exclusiveCount(int c) { return c & EXCLUSIVE_MASK; }

//线程的id和对应线程获取的读锁的数量
static final class HoldCounter {
int count = 0;
// Use id, not reference, to avoid garbage retention
final long tid = Thread.currentThread().getId();
}

//线程变量保存线程和线程中获取的读写的数量
static final class ThreadLocalHoldCounter extends ThreadLocal<HoldCounter> {
public HoldCounter initialValue() {
return new HoldCounter();
}
}

private transient ThreadLocalHoldCounter readHolds;
//缓存最后一个获取读锁的线程
private transient HoldCounter cachedHoldCounter;
//保存第一个获取读锁的线程
private transient Thread firstReader = null;
private transient int firstReaderHoldCount;

其中,包含两个静态内部类:ReadLock()WriteLock(),都实现了Lock接口

获取读锁

  • 如果不存在线程持有写锁,则获取读锁成功。
  • 如果其他线程持有写锁,则获取读锁失败。
  • 如本线程持有写锁,并且不存在等待写锁的其他线程,则获取读锁成功。
  • 如本线程持有写锁,并且存在等待写锁的其他线程,则如果本线程已经持有读锁,则获取读锁成功,如果不能存在读锁,则此次获取读锁失败。

获取写锁

  • 判断是否有线程持有锁,包括读锁和写锁,如果有,则执行步骤2,否则步骤3;
  • 如果写锁为空(此时由于1步骤判断存在锁,则存在持有读锁的线程),或者持有写锁的不是本线程,直接返回失败,如果写锁数量大于MAX_COUNT,返回失败,否则更新state,并且返回true;
  • 如果需要写锁堵塞判断,或者CAS失败直接返回false,否则设置持有写锁的线程为本线程,并且返回true;
  • 通过writerShouldBlock写锁堵塞判断.
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    final boolean writerShouldBlock() {
    return hasQueuedPredecessors();
    }
    //判断是否堵塞
    public final boolean hasQueuedPredecessors() {
    Node t = tail;
    Node h = head;
    Node s;
    return h != t &&
    ((s = h.next) == null || s.thread != Thread.currentThread());
    }

七、比较

Lock和synchronized

synchronized是基于JVM层面实现的,而Lock是基于JDK层面实现的。Lock需要lockrelease,比synchronized复杂,但Lock可以做更细粒度的锁,支持获取超时、获取中断,这是synchronized所不具备的。Lock的实现主要有ReentrantLockReadLockWriteLock,读读共享,写写互斥,读写互斥。

  • Lock是一个接口,而synchronized是Java中的关键字,是内置的语言实现;

  • synchronized在发生异常时,会自动释放线程占有的锁,因此不会导致死锁现象发生;而Lock在发生异常时,如果没有主动通过unLock()去释放锁,则很可能造成死锁现象,因此使用Lock时需要在finally块中释放锁;

  • Lock可以让等待锁的线程响应中断,而synchronized却不行,使用synchronized时,等待的线程会一直等待下去,不能够响应中断;

  • 通过Lock可以知道有没有成功获取锁,而synchronized却无法办到。

  • Lock可以提高多个线程进行读操作的效率。   

  • Lock实现和synchronized不一样,后者是一种悲观锁,它胆子很小,它很怕有人和它抢吃的,所以它每次吃东西前都把自己关起来。而Lock底层其实是CAS 乐观锁的体现,它无所谓,别人抢了它吃的,它重新去拿吃的就好啦,所以它很乐观。底层主要靠volatileCAS操作实现的。

synchronized和volatile

  • volatile本质是在告诉jvm当前变量在寄存器(工作内存)中的值是不确定的,需要从主存中读取;

  • synchronized则是锁定当前变量,只有当前线程可以访问该变量,其他线程被阻塞住;

  • volatile仅能使用在变量级别;synchronized则可以使用在变量、方法、和类级别的;

  • volatile仅能实现变量的修改可见性,不能保证原子性;而synchronized则可以保证变量的修改可见性和原子性;

  • volatile不会造成线程的阻塞;synchronized可能会造成线程的阻塞;

  • volatile标记的变量不会被编译器优化;synchronized标记的变量可以被编译器优化。

八、死锁问题

死锁有四个必要条件,打破一个即可去除死锁。

四个必要条件:

  • 互斥条件

    一个资源每次只能被一个进程使用。

  • 请求与保持条件

    一个线程因请求资源而阻塞时,对已获得的资源保持不放。

  • 不剥夺条件

    线程已获得的资源,在末使用完之前,不能强行剥夺。

  • 循环等待条件

    若干线程之间形成一种头尾相接的循环等待资源关系。

死锁的例子

同步嵌套时,两个线程互相锁住,都不释放,造成死锁。
举例:
创建两个字符串a和b,再创建两个线程A和B,让每个线程都用synchronized锁住字符串(A先锁a,再去锁b;B先锁b,再锁a),如果A锁住a,B锁住b,A就没办法锁住b,B也没办法锁住a,这时就陷入了死锁。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
public class DeadLock {
public static String obj1 = "obj1";
public static String obj2 = "obj2";
public static void main(String[] args){
Thread a = new Thread(new Lock1());
Thread b = new Thread(new Lock2());
a.start();
b.start();
}
}
class Lock1 implements Runnable{
@Override
public void run(){
try{
System.out.println("Lock1 running");
while(true){
synchronized(DeadLock.obj1){
System.out.println("Lock1 lock obj1");
Thread.sleep(3000);//获取obj1后先等一会儿,让Lock2有足够的时间锁住obj2
synchronized(DeadLock.obj2){
System.out.println("Lock1 lock obj2");
}
}
}
}catch(Exception e){
e.printStackTrace();
}
}
}
class Lock2 implements Runnable{
@Override
public void run(){
try{
System.out.println("Lock2 running");
while(true){
synchronized(DeadLock.obj2){
System.out.println("Lock2 lock obj2");
Thread.sleep(3000);
synchronized(DeadLock.obj1){
System.out.println("Lock2 lock obj1");
}
}
}
}catch(Exception e){
e.printStackTrace();
}
}
}

九、相关锁的概念

在 java 中锁的实现主要有两类:内部锁 synchronized(对象内置的monitor锁)和显示锁java.util.concurrent.locks.Lock

  • 可重入锁

    指的是同一线程外层函数获得锁之后 ,内层递归函数仍然有获取该锁的代码,但不受影响,执行对象中所有同步方法不用再次获得锁。synchronizedLock都具备可重入性。

  • 可中断锁

    synchronized就不是可中断锁,而Lock是可中断锁。

  • 公平锁

    按等待获取锁的线程的等待时间进行获取,等待时间长的具有优先获取锁权利。synchronized就是非公平锁;对于ReentrantLockReentrantReadWriteLock,它默认情况下是非公平锁,但是可以设置为公平锁。

  • 读写锁

    对资源读取和写入的时候拆分为2部分处理,读的时候可以多线程一起读,写的时候必须同步地写。ReadWriteLock就是读写锁,它是一个接口,ReentrantReadWriteLock实现了这个接口。

  • 自旋锁

    让线程去执行一个无意义的循环,循环结束后再去重新竞争锁,如果竞争不到继续循环,循环过程中线程会一直处于running状态,但是基于JVM的线程调度,会让出时间片,所以其他线程依旧有申请锁和释放锁的机会。自旋锁省去了阻塞锁的时间空间(队列的维护等)开销,但是长时间自旋就变成了“忙式等待”,忙式等待显然还不如阻塞锁。所以自旋的次数一般控制在一个范围内,例如10,100等,在超出这个范围后,自旋锁会升级为阻塞锁。

  • 独占锁

    是一种悲观锁synchronized就是一种独占锁,会导致其它所有需要锁的线程挂起,等待持有锁的线程释放锁。

  • 乐观锁

    每次不加锁,假设没有冲突去完成某项操作,如果因为冲突失败就重试,直到成功为止。

  • 悲观锁

    导致其它所有需要锁的线程挂起,等待持有锁的线程释放锁。

关于JUC

包含了两个子包:atomic以及lock,另外在concurrent下的阻塞队列以及executors,以后再深入学习源码吧,下面这个图很是经典:
此处输入图片的描述


参考链接

-------------本文结束感谢阅读-------------